What a Hosted Agent Is — Hosted Agents: Concepts

A hosted agent is not a fancier prompt. It is a different build pattern. Instead of defining an artificial intelligence agent only through instructions and tool choices in a portal, you write the agent as software, package it with its runtime environment, and let a managed platform run it. The short version is simple: hosted means your code, their operations.

Start with the simpler option: a prompt-based agent

Most teams first meet agents through a prompt-based agent. You open a web portal, write instructions such as what the agent should do and how it should behave, then select tools from a menu. The platform turns that description into something callable.

That is a useful model because it is fast. If the job is narrow, the inputs are simple, and the built-in tools are enough, a prompt-based agent may be the right answer. Its boundary is also clear: the agent is defined by the prompt and the tool list. You cannot easily insert your own program logic between a model decision and a tool call, require an unusual input format, or run a custom step that the portal does not support.

A hosted agent begins where that boundary becomes a problem. Instead of expressing the whole agent through configuration, you build it as code.

A hosted agent is code the platform runs for you

A hosted agent is an agent you write as a program, package as a container image, and deploy to a managed service. The agent may use any agent framework your platform supports through containers, and it may call the model or models your code is designed to call.

The important shift is ownership of behavior. In a prompt-based agent, behavior mostly lives in instructions and platform configuration. In a hosted agent, behavior lives in your code: the routing, validation, retries, tool selection, memory handling, custom payload parsing, and special-case logic.

The platform is still important, but for a different reason. It does not decide how your agent thinks. It runs the software reliably, exposes it to callers, gives it identity, captures operational data, and helps it scale.

📌

The dividing line. A hosted agent lets you own the agent’s behavior while the platform owns much of the operational plumbing.

The container image is the package

To run your agent consistently, you package it as a container image. A container image is a sealed software package that contains your code plus the things that code needs to run: the language runtime, libraries, dependencies, and exact versions.

The image matters because it reduces the gap between development and production. If the agent ran with a specific set of packages on your laptop, the same set travels with it to the platform. You are not merely shipping source code; you are shipping the environment around the source code.

A running instance of that image is called a container. The image is the template; the container is the live process created from that template. Many teams describe the image with a Dockerfile, which is a small recipe that says what base to start from, what to install, what code to copy in, and what command to run.

A Dockerfile recipe builds a sealed image, which the platform runs as a live container.

Hosted means managed operations, not managed thinking

If you build an agent with an open-source framework and run it yourself, you inherit the ordinary work of production software. You need a web server or application endpoint. You need authentication and secure identity. You need storage for files or state. You need scaling when traffic rises, logs and traces when something fails, and a way to deploy new versions or roll back bad ones.

A hosted agent platform takes on much of that operational work. You provide the container image. The platform runs it on managed infrastructure, gives callers a stable way to reach it, provides session isolation where the service supports it, persists files or progress across pauses when persistence is part of the platform, and records telemetry for observability.

This is the practical meaning of hosted. The platform is not there to make your agent clever. It is there to make your agent runnable, reachable, monitorable, and safer to operate at scale.

A hosted platform provides the managed operations a running agent needs.

What you control and what the platform handles

A clear responsibility split prevents confusion. You control the agent framework, the orchestration logic, the tools your code calls, the request and response formats your agent accepts, the contents of the container image, and usually the model choices your code makes.

The platform handles the managed runtime around that code. Depending on the service, that can include isolated compute for sessions, secure identity, persistent storage, stable endpoints, logs, traces, metrics, deployment versions, and rollbacks.

The distinction is worth keeping sharp. If a model produces a poor answer because your code routed the task badly, that is your design issue. If a container needs to be restarted, scaled, addressed, observed, or rolled back through the managed service, that is the platform’s job.

You own: framework choice, model calls, orchestration, tool behavior, validation, and dependency choices.
The platform owns: hosting, scaling, identity, persistence, observability, endpoints, and version management.
Both matter: hosted agents give more freedom than prompt-only agents, but freedom moves some engineering responsibility back to the team.

You own the agent logic; the platform owns the managed runtime around it.

Why framework and model choice matter

A common concern with managed platforms is lock-in, which means being forced to build in one vendor’s framework or use one vendor’s model because the platform makes other choices hard. Hosted agents are meant to reduce that pressure. Because the agent is a containerized program, the platform can run the package without dictating every library inside it.

That matters in artificial intelligence systems because agent frameworks and models change quickly. A team may start with one orchestration library, later move to another, or use different models for planning, retrieval, classification, and generation. A hosted-agent design keeps those choices closer to the codebase, where they can be reviewed, tested, and changed.

This does not mean every hosted platform supports every possible combination automatically. It means the pattern is multi-framework and multi-model in spirit: the runtime runs your package, and your package carries the choices that make the agent work.

The real decision: when to use one

For leaders and practitioners, the decision is not whether hosted agents are more advanced. The decision is whether the extra control is worth the extra engineering discipline. If a prompt-based agent solves the problem cleanly, it is usually the cheaper and faster path.

Reach for a hosted agent when the simple path blocks a real requirement: custom logic between model steps, a webhook or payload shape the portal cannot understand, long-running work that needs files and progress to persist, specific compute needs, deeper observability, or a desire to keep framework and model choices open.

There is also a security and intellectual-property dimension. With a hosted agent, prompts, routing rules, proprietary methods, and special business logic can live inside your own code package rather than only in a portal configuration. That can be useful, but it also means the agent must be secured like production software.

Do you need custom logic between the model and a tool call?
Must the agent accept an input shape a portal would not support?
Does the task need durable files, memory, or progress across many steps?
Do you need to keep framework and model choices open over time?

⚠️

Production code. A hosted agent can hold secrets and credentials, so dependency hygiene, input validation, and secret handling are part of the job.

Key takeaways

A prompt-based agent is defined by instructions and tools in a portal; a hosted agent is your own code running on managed infrastructure.
A container image packages the agent code with its runtime, libraries, and versions so it can run consistently.
Hosted means the platform handles operations such as scaling, identity, persistence, observability, endpoints, and rollbacks.
You control the framework, orchestration logic, tool behavior, payload handling, and model calls.
Hosted agents are best when a prompt and tool list are no longer enough.
Because a hosted agent is real production code, it must be secured and maintained like any other service.

Use a prompt-based agent when the simple path works; reach for hosted when it blocks a need.

Glossary

Hosted agent: An agent written as code, packaged as a container image, and run for you on managed infrastructure.
Prompt-based agent: An agent defined through prompts and selected tools in a portal, without custom application code.
Container image: A packaged software template that contains code plus the runtime, libraries, dependencies, and versions needed to run it.
Container: A running instance created from a container image.
Dockerfile: A text recipe that describes how to build a container image.
Agent framework: A software library or toolkit that helps developers build an agent’s reasoning flow, tool use, memory, and orchestration.
Model: The artificial intelligence system the agent calls to interpret input, generate output, classify information, or plan next steps.
Observability: The ability to understand what software is doing in production through logs, metrics, traces, and related operational signals.
Lock-in: A situation where a team is forced to keep using one vendor’s tools or services because switching has become too difficult or costly.