How It Works, End to End — Hosted Agents: Concepts

A hosted agent is not magic. It is a repeatable path from code to container image, from image to registry, from registry to immutable version, and from version to a running service with its own identity and endpoint. Once you can trace that path, deployment stops feeling like a collection of platform words and starts looking like a safety system.

The whole journey in five moves

The easiest way to understand a hosted agent is to follow one end to end. You start with a folder of source code. You package it into a container image. You upload that image to a container registry. You create a version that points to the image. The platform then provisions compute, gives the agent an identity and an endpoint, and makes the agent callable.

Those five moves are the basic lifecycle: build, push, create a version, provision, invoke. Some tools collapse several of the moves into one command, but the underlying sequence remains the same. Knowing the sequence matters because it tells you where your code is, what exactly is running, and how to move forward or backward safely.

A hosted agent moves through five steps: build, push, version, provision, invoke.

Build and push: code becomes a retrievable image

Building means turning your source folder into a container image. A container image is a sealed package that carries your application code and the runtime environment it expects. The point is consistency: the same image should behave the same way whether it is started during a test, during deployment, or later in production.

You may build the image on your own machine, or the platform may build it remotely from your source code. In both cases, the result is the same kind of artifact: a named image that the platform can run.

After the image exists, it must be pushed to a container registry. A registry is a private, access-controlled store for images. It is the place the platform can pull from when it needs to start your agent. This is not a cosmetic detail. The registry is where the packaged form of your agent, including its code and often its prompts or tool wiring, physically resides.

📌

Same artifact. Whether the image is built locally or remotely, the platform ultimately deploys a container image from a registry.

Create a version: the platform takes over

Creating a version is the handoff from artifact to hosted service. You tell the platform which image in the registry should become a running agent, along with the operational settings that belong to it.

A version is more than an image pointer. It is a frozen deployment snapshot that can include the image, the amount of central processing unit and memory each session receives, configuration values, and the communication protocols the agent supports. Once the version is created, the platform begins provisioning the infrastructure needed to run it.

During this stage the version normally moves through a provisioning state before it becomes active. Active means the platform has finished enough work for the agent to serve requests. You do not edit the version into shape after that. You wait until the version is active, then call it.

A version is a frozen snapshot of the image plus its operational settings.

Identity and endpoint appear with the running service

Two important things are created as part of deployment: an identity and an endpoint. The identity is the agent’s own secure account. The running code uses it to prove who it is when it calls a model, a tool, a database, or another service. This avoids treating every agent as the same anonymous process or forcing long-lived secrets into the image.

The endpoint is the agent’s address on the network. It is where other programs send requests. Once the version is active, the endpoint is available for programmatic calls; there is no separate publish step required just to start invoking it.

Together, identity and endpoint turn the image into something operational. The endpoint makes the agent reachable. The identity makes its actions attributable. For agents that can call tools or take actions, both properties matter.

Identity makes an agent's actions attributable; the endpoint makes it reachable.

Invoke: one request, a lot of controlled work

Invoking the agent means sending a request to its endpoint and receiving a response. The request might contain a question, a task, a user message, a file reference, or a structured payload. From the caller’s point of view, this looks like calling any other web service through an application programming interface.

Behind that simple call, the platform routes the request to an isolated slice of compute, starts or uses the running container, passes the request into your code, allows the agent to call approved models and tools with its identity, and returns or streams the result back to the caller.

This separation is useful. The caller does not need to know how the agent was packaged or which machine handled the work. The operator still has a precise trail from the request to the active version that served it.

Immutable versions are the safety mechanism

The most important operating rule is that a version is immutable. Once a version exists, you do not change its image, resource settings, configuration, or protocols in place. To make a change, you build or select a new image and create a new version.

At first, this can feel strict. In practice, it is what keeps production understandable. If a version cannot drift, then the thing running today is the same thing you reviewed and shipped. If it misbehaves, you do not repair it by editing a live service and hoping you know what changed. You route traffic to a different version.

Rollback becomes a controlled move rather than an emergency improvisation. A previous version is already a complete snapshot. If it was known to work yesterday and has not changed, pointing traffic back to it is a much safer act than rebuilding from memory.

✅

Rollback becomes simple. With immutable versions, rollback is pointing traffic at an older known-good snapshot, not editing a broken service in place.

If a version misbehaves, route traffic to a known-good prior version instead of editing it.

What this changes for real decisions

For artificial intelligence agents, this lifecycle is not just deployment hygiene. Agents may call tools, retrieve private data, write records, open tickets, or trigger workflows. That means leaders and practitioners need a reliable way to answer three questions: what code and prompts ran, under which identity, and through which versioned endpoint?

The versioned lifecycle gives those answers a concrete place to live. Each release ties a specific image to specific settings, a specific identity, and a specific endpoint. If behavior changes, you can inspect the version that produced it instead of searching through a vague mixture of source commits, environment edits, and manual fixes.

This affects everyday choices about release approvals, incident response, access control, and audit. A team that can name the exact version serving production can make faster and safer decisions than a team that only knows that the agent was updated recently.

Before release, confirm the image tag, configuration, resource settings, and protocols that will be frozen into the version.
Before granting access, confirm the agent has its own identity rather than reusing a broad shared one.
Before an incident, confirm traffic can move back to a known-good older version without rebuilding.
After unexpected behavior, investigate the active version first, because that is the unit that actually ran.

A simple test for this week

Pick one hosted agent and trace it from source code to a real call. The goal is not to create paperwork. The goal is to see whether your team still has a clean chain from what was built to what is behaving in production.

If any answer is uncertain, you have found a gap in the lifecycle. The fix is usually not a larger meeting. It is making the version, image, identity, endpoint, and rollback path visible enough that an operator can name them under pressure.

Name the registry and exact image tag used by the active version.
Name the identity the running agent uses to call its model and tools.
Find the endpoint callers use, and confirm it belongs to the active version.
Identify yesterday’s known-good version and the action required to route traffic back to it.
Verify that changing behavior requires creating a new version, not editing the active one in place.

⚠️

Fuzzy is risky. If you cannot connect a running behavior to an exact immutable version, you have lost the audit trail that makes hosted agents operable.

Key takeaways

The hosted-agent lifecycle is build, push, create a version, provision, and invoke.
A container image packages the code and environment; a registry stores that image where the platform can pull it.
Creating a version triggers provisioning and produces a running service with its own identity and endpoint.
The endpoint is callable once the version is active; a separate publish step is not required for programmatic invocation.
Versions are immutable, so changes require a new version and rollback can target an older known-good snapshot.
For agents that take actions, version traceability is a practical control, not administrative overhead.

Glossary

Hosted agent: An agent packaged and run by a platform so other programs can call it through a managed endpoint.
Container image: A sealed package containing application code and the runtime environment needed to run it consistently.
Container registry: A private, access-controlled store where container images are uploaded and later fetched for deployment.
Push and pull: Push means upload an image to a registry, and pull means fetch that image from the registry.
Version: An immutable deployment snapshot that ties an image to resources, configuration, and supported communication protocols.
Provision: To prepare the compute and supporting infrastructure required to run a version.
Identity: A secure account assigned to the running agent so its calls to models, tools, and services can be authenticated and attributed.
Endpoint: The network address where callers send requests to the active agent.
Immutable: Unchangeable after creation, so any update requires creating a new version rather than editing the existing one.