The point of a hosted agent is not to make operations exciting. It is to make the ordinary work of deployment, rollback, sizing, cost control, and access management predictable enough that the team can focus on the agent’s behavior rather than the machinery around it. The hard question is not only how to run one. It is whether the job truly calls for a hosted agent at all.

Deployment should feel like controlled plumbing

A hosted agent deployment can be close to a single command because the platform is doing a familiar chain of work on your behalf. It builds the agent package or container image, often in a remote build environment. It publishes that image to a registry. It creates an immutable version of the agent. It wires the agent to a dedicated identity and grants the permissions needed to call models, tools, data sources, and observability services.

The first deployment usually does more than later ones. It may create the project, the model deployment, the registry, logging and metrics, and the identity used by the agent. After that foundation exists, a normal code change should be smaller: build a new artifact, create a new version, and route traffic to it when you are ready.

This is not magic. It is automation of work teams used to do by hand: packaging, publishing, configuration, permissions, and release registration. The gain is fewer places for humans to make small, production-breaking mistakes.

📌
What one command really means. The command is simple because the platform has made the build, release, identity, and permission steps explicit behind it.
The platform builds the image, publishes it, freezes a version, and wires an identity. Deploy Chain Build image Publish Version Wire identity
The platform builds the image, publishes it, freezes a version, and wires an identity.

Immutable versions make rollback boring

A reliable hosted agent treats each release as an immutable version: a frozen snapshot of code, declared configuration, runtime size, and other versioned settings. You do not patch the running version in place. You ship a new one.

That design changes the emotional texture of operations. If the new version misbehaves, rollback is not a rushed repair session. You point the endpoint back to a previous version that is already known to work. The old version did not drift while you were away, because it was never modified.

This matters especially for agents because they can take actions, call tools, and change state outside themselves. A quick return to a known-good version is not just a convenience. It is part of the safety system.

  • Treat every deploy as a new version, not a mutation of the old one.
  • Keep enough previous versions to cover your realistic rollback window.
  • Record which version is serving traffic and which model, tools, and permissions it uses.
  • Practice rollback before you need it during an incident.

Right-size the sandbox from evidence, not optimism

Each active session of a hosted agent runs inside its own sandbox: an isolated execution environment with a declared amount of central processing unit, or CPU, and memory. The important detail is that the size applies to one session, not to the whole agent service.

If one session is oversized, every concurrent session inherits that waste. If it is undersized, the agent may become slow, fail under load, or run out of memory during longer tasks. Right-sizing means choosing the smallest sandbox that safely handles real work, with headroom for normal variation.

The practical method is simple. Run representative tasks. Look at measured CPU and memory use in the platform’s observability data. Adjust the size. Then ship a new immutable version and retest, because changing the sandbox changes the thing you are operating.

The bill follows active work

Hosted agents are commonly billed on consumption: the compute and memory used while sessions are active. This cost model fits the architecture. When no sessions are running, a scale-to-zero platform can stop spending compute on an idle agent instead of keeping an always-on server warm.

The two cost multipliers are session size and concurrency. Session size is the CPU and memory assigned to each sandbox. Concurrency is the number of sessions running at the same time. A quiet agent with few sessions costs little. A busy agent with many large sandboxes costs more because it is doing more work.

This does not remove the need for cost discipline. It changes where that discipline belongs. You watch whether sessions are staying active longer than needed, whether the sandbox is too large, and whether background behavior is keeping work alive when the user-visible task is finished.

  • Use real utilization data before choosing a larger size.
  • Set session timeouts that match the task instead of leaving work open indefinitely.
  • Watch peak concurrency, not just average daily usage.
  • Separate model and tool costs from sandbox compute costs when analyzing the total bill.
✅
Cost rule. For a hosted agent, the bill is driven mainly by sandbox size multiplied by active concurrent sessions.
Cost is driven by how large each sandbox is and how many sessions run at once. Cost Multipliers Session sizeper sandbox Concurrencysessions at once CPU plus memory How many run Bigger costs more More costs more
Cost is driven by how large each sandbox is and how many sessions run at once.

Know the groundwork before the first release

One-command deployment still assumes that a few basics exist. You need an account, a project or workspace, supported agent code, access to the model or models the agent will use, a registry or artifact store, and observability for logs, metrics, and traces. You also need a runtime region that meets your latency, data residency, and availability requirements.

Permissions are part of the deployment, not an afterthought. The operator needs enough access to create and update hosted agents, publish versions, assign identities, and grant tool permissions. The agent itself should use a dedicated identity with only the permissions required for its job. This is the least privilege principle: grant what is needed, and no more.

For teams, the most useful preflight check is not technical cleverness. It is a written inventory of what the agent may call, what data it may touch, where it runs, who may deploy it, and how failures are observed.

  • Project or workspace created
  • Supported language and framework selected
  • Model deployment or model access available
  • Registry or artifact storage ready
  • Logs, metrics, and traces enabled
  • Operator role and agent identity defined
  • Runtime region chosen for users, data, and policy

The real decision: prompt-based or hosted

The most important operating decision may happen before operations begin. A prompt-based agent is usually the right starting point when the job can be solved with instructions, model choice, and a bounded set of tools. It is faster to build, simpler to secure, and often cheaper to run because there is less custom runtime to manage.

A hosted agent earns its complexity when the simpler form blocks something real. You may need your own code and framework. You may need custom inputs, webhooks, background processing, or state that lives across a long task. You may need control over the compute environment, dependencies, networking, or tool execution. Those are valid reasons, but they come with operational responsibility.

This is the leadership question as much as the engineering question: are we buying needed capability, or are we buying responsibility we do not need? The disciplined answer is to start with the simplest design that can do the job and move to hosted only when a concrete requirement forces the step up.

⚠️
Do not skip the simpler option. Power that does not serve a requirement becomes extra cost, extra access, and extra failure surface.
Start prompt-based; move to a hosted agent only when the simpler form blocks something real. Prompt or Hosted Simple form blocks? No Yes Prompt-basedstart here Hostedmore control
Start prompt-based; move to a hosted agent only when the simpler form blocks something real.

A one-week operating test

You can learn a great deal about your readiness in a week without building a large production program. Deploy a small but representative agent. Give it the same identity pattern, observability, versioning, and sandbox sizing method you would use in production. Then deliberately change it and roll it back.

The aim is not to prove that the agent is impressive. The aim is to prove that the operating loop is calm: deploy, observe, adjust, redeploy, and recover. If the team cannot answer basic questions during this small test, the system is not yet ready for a larger rollout.

End the test with a decision record. State whether the use case should remain prompt-based or move to hosted, what requirement justifies that choice, what sandbox size the evidence supports, and who owns deployment, permissions, and incident response.

  1. Deploy one representative hosted agent into a non-production environment.
  2. Run realistic sessions and capture CPU, memory, latency, tool calls, and errors.
  3. Ship a harmless change as a new immutable version.
  4. Roll back to the previous version and confirm behavior returns to normal.
  5. Resize the sandbox based on measured usage and retest.
  6. Write down whether hosted is justified or whether a prompt-based agent would be enough.

Key takeaways

  • A mature hosted-agent deployment automates build, publish, versioning, identity, permissions, and traffic routing.
  • Immutable versions make rollback a safe switch to a known-good release rather than an emergency repair.
  • Sandbox size is per session, so oversizing becomes expensive when concurrency rises.
  • Consumption billing rewards agents that scale to zero and stop spending compute when no sessions are active.
  • Choose a prompt-based agent when prompts and tools are enough; choose hosted only when custom runtime needs are real.
  • The operating habits around an agent are part of its safety model, not just its maintenance plan.
A calm operating loop cycles through deploy, observe, adjust, and redeploy. Operating Loop Deploy Observe Adjust Redeploy repeat
A calm operating loop cycles through deploy, observe, adjust, and redeploy.

Glossary

Hosted agent
An agent that runs in a managed execution environment where the platform handles deployment, versioning, isolation, scaling, and runtime operations.
Prompt-based agent
An agent built mainly from instructions, model selection, and configured tools rather than from a custom hosted runtime.
Sandbox
An isolated execution environment that gives one agent session its own compute, memory, and runtime boundary.
Immutable version
A frozen release of the agent and its versioned settings that is not changed in place after deployment.
Rollback
The act of sending traffic back to a previous known-good version after a newer version causes problems.
Right-sizing
The practice of matching CPU and memory to measured workload needs so the agent has enough resources without waste.
Consumption billing
A pricing model where cost is based on resources used while work is active rather than on permanently reserved capacity.
Concurrency
The number of sessions running at the same time, which multiplies compute and memory use in a per-session sandbox model.
Least privilege
The security practice of giving a user, service, or agent only the permissions required to perform its intended job.