How do cloud agents run in production?

Cloud agents are easy to demo because the first version looks like a script: read a goal, call a model, invoke a tool, repeat. Production changes the unit of work. The thing you deploy is an operating loop with credentials, state, budgets, logs and a person who can stop it.

Manual deployment still matters. Before CI, autoscaling and multi-agent routing, you need one release path that a human can inspect end to end. That path should make the agent boring enough to restart and constrained enough to trust.

What makes a cloud agent different from a chatbot?

A chatbot waits for a user turn and replies. A cloud agent keeps working after the first prompt. It decomposes a goal, calls a model, chooses tools, records state, evaluates the result and decides whether to continue. That loop means the agent owns time, credentials and side effects in a way a chat box usually does not.

The boundary is clearest around tools. A hosted chat application may call a search API and display the answer. A cloud agent may create tickets, deploy configuration, update records or send messages while the user is away. Tool routing through protocols such as MCP helps standardise discovery, but the cloud runtime still decides identity, network access, retries and cancellation.

So the production question is operational: what can this loop reach, how do you replay a failed step, and who can stop it before the next tool call runs?

Which runtime shape should you deploy first?

Start with a worker, a queue and external state. The worker reads one task, claims a lease, runs the agent loop for a bounded number of steps, writes a trace and either completes, retries or asks for review. That shape maps cleanly to containers on ECS, a Kubernetes Job, a Cloud Run worker, or a scheduled Workers workflow. The brand matters less than the contract.

A request-response service is tempting because it feels simple. It becomes fragile when a model call stalls, a tool needs approval, or a retry arrives after the client has disconnected. Queues make time explicit. A lease says who is allowed to work, a dead-letter queue preserves failures, and an idempotency key keeps a second attempt from repeating a write.

Keep the first release deliberately small: one worker image, one queue, one state store, one trace sink and one control command that cancels a run.

How do you deploy one manually?

Manual deployment means you can describe each change before automation hides it. Build the agent as a container image or serverless bundle, pin the version, then create the runtime resources by hand: queue, database, object store, secret set, service account and logs. Put every identifier in a short release note, including the image digest or bundle hash.

Deploy with one replica. On ECS that may be an update-service call with desired count one. On a smaller host it may be Docker Compose pulling the pinned image and restarting the worker. On Cloudflare Workers it may be a wrangler deploy after secrets have been set in the platform. The platform differs, but the order should stay constant: package, provision state, set secrets, dry-run, promote, watch, record rollback.

Do the first dry run with write tools disabled or held for approval. The trace is the release artifact that matters.

What controls keep the agent bounded?

Bound the agent in four places. First, limit identity. The service account should have separate read and write permissions, with write access granted only to the APIs this release needs. Second, limit the network. Tool adapters should reach named hosts rather than the whole internet where the platform allows it. Third, limit spend and duration. A maximum number of model calls, tokens, retries and minutes per task turns a bad loop into a stopped run.

Fourth, classify every tool by consequence. Read tools can usually run inside the loop. Write tools need approval, idempotency keys and audit logs, especially on public endpoints. The failure mode resembles the gap between read controls and write controls in agent traffic policy: a rule that governs fetching says little about an action that changes state.

The kill switch should live outside the agent process. A stuck planner should never be responsible for cancelling itself.

When should you move past manual deployment?

Move past manual deployment after the boring path has produced boring evidence. You should be able to answer four questions from logs alone: which version ran, which model and tool calls it made, which credentials it used, and why it stopped. If any answer requires memory from the release engineer, automate later.

The next step is CI that builds the image, runs unit and dry-run checks, pushes the digest, applies infrastructure changes and opens a human approval gate before promotion. Autoscaling comes after that. More workers are useful only when each work item is replayable and each write is idempotent.

A mature cloud agent platform eventually adds policy engines, sandboxed tool execution, per-customer isolation and evaluation suites. Those are valuable once the single-agent loop is stable. Until then, manual deployment is a design tool: it exposes every assumption the future pipeline must preserve.