Running an Agent: Runtime, Harness, and Session Isolation

A request-response web service has a shape every platform is built for: milliseconds to seconds, stateless between requests, no untrusted code execution, scale by adding identical replicas.

An agent violates all four assumptions at once:

• Duration. A research or coding agent runs for minutes to hours, not milliseconds, so anything with a short request timeout is the wrong host.
• State. The loop accumulates conversation, intermediate files and tool results, and it matters that they persist for the session and vanish after it.
• Untrusted execution. If the agent writes and runs code or drives a browser, the platform is executing something a model just produced.
• Bursty, uneven load. Sessions are long and idle much of the time, so per-replica sizing is wasteful, and per-request autoscaling does not map onto a stateful conversation.

Key idea: the hard part of agent infrastructure is not running the loop, which is a while-loop around a model call. It is running many concurrent loops that hold state and execute untrusted code, without any of them being able to observe or affect another.

AgentCore Runtime is AWS's managed answer to exactly that shape, and the guarantee it sells is isolation.

AWS describes AgentCore Runtime as a secure, serverless runtime purpose-built for deploying and scaling dynamic AI agents and tools. The properties that matter, and why each one is on the list:

The framework claim is the one to check against your stack. AWS documents Runtime as working with custom frameworks and open-source ones including CrewAI, LangGraph, LlamaIndex, Google ADK, OpenAI Agents SDK and Strands Agents, and with any foundation model inside or outside Bedrock, naming OpenAI, Gemini, Claude, Amazon Nova, Meta Llama and Mistral.

In practice: that combination is the strategic point. You are not asked to rewrite your agent into an AWS-specific framework, so adoption is a deployment change rather than a rewrite, and the same code can in principle run elsewhere.

Isolation sounds like boilerplate until you work out what a shared process would mean for agents specifically.

AWS's answer is per-session isolation, with the Harness documentation describing each session as running in an isolated microVM with its own filesystem and shell access. A microVM is the same class of primitive that underpins AWS's serverless compute: a hardware-virtualised boundary rather than a shared kernel, which is a stronger guarantee than container namespaces against exactly the escape paths above.

Key idea: the isolation boundary is per session, not per tenant or per deployment. That is what allows one deployment to serve many users' agents safely, and it is why "just run it in a container" is not the same product.

Following an invocation makes the division of labour concrete, and shows which parts you still own.

A caller invokes the agent endpoint with a session identifier. Identity authenticates the caller. Runtime routes the request to the isolated environment for that session, starting one if this is the first turn. Your agent code, in whatever framework you brought, runs its loop: it calls a model, decides on tool calls, and those tools may be Gateway-exposed APIs, the Code Interpreter, or the Browser. State that must outlive the session goes to Memory, and every step emits telemetry to Observability.

What AWS is running: the isolation boundary, the lifecycle, the scaling, the identity check and the telemetry pipeline. What you still own entirely: the loop's logic, the prompts, which tools exist and when to call them, and the decision of what is worth remembering.

That split is the honest summary of the platform. It removes the infrastructure, and leaves every hard design decision exactly where it was.

Runtime hosts a loop you wrote. AgentCore Harness offers the opposite trade: AWS documents it as a managed agent loop that lets you define and invoke an agent with a single API call, specifying a model, system prompt and tools inline, with the service handling orchestration, tool execution, memory management and response generation.

The two are answers to different questions:

Harness works with Bedrock models and also with OpenAI, Google Gemini and any OpenAI-compatible provider, supports remote MCP servers and inline functions, and allows a custom container image when the environment needs extra dependencies.

In practice: the decision is whether your agent's control flow is a differentiator. A retrieval-and-answer or research agent is a standard shape, and hand-writing the loop buys little. An agent with domain-specific routing, custom retry semantics, or a multi-stage pipeline you have tuned is exactly where you want the loop in your own code, and Runtime is the right host.

Runtime supports two protocols, and they answer different questions about what an agent connects to.

MCP, the Model Context Protocol, standardises how an agent discovers and calls tools. Its value is the same as any interface standard: a tool server written once is usable by any MCP-speaking agent, which is what makes the Gateway service in the next lesson possible at all.

A2A, agent-to-agent, standardises how agents communicate with each other, so a multi-agent system can be assembled from independently deployed agents rather than from functions inside one process.

The architectural consequence is worth pausing on. When agents are separately deployed and speak a protocol, a multi-agent system becomes a distributed system, and inherits the whole discipline: partial failure when one agent is down, latency that compounds across hops, versioning of the message contract, and the observability problem of tracing one user request across several agents.

Gotcha: distributing agents because the diagram looks tidy is the same mistake as premature microservices. Separate deployments earn their cost when teams own agents independently, when scaling profiles genuinely differ, or when isolation is required. Inside one team, functions in one loop are simpler and usually better, and the catalogue's orchestration lessons cover when the split actually pays.

Agent workloads have a cost shape that surprises teams whose intuitions come from web services, and it is worth predicting before the invoice does it for you.

The drivers, roughly in order of how often they dominate:

• Tokens, many times per task. An agent turn is not one model call. A task with fifteen tool-using steps is fifteen or more calls, each carrying a context that grows as the transcript does, so cost per task scales super-linearly with steps unless context is managed.
• Wall-clock time. Serverless agent hosting bills for the session's duration, and an agent waiting on a slow API is still a running session.
• Sandbox usage. Code Interpreter and Browser sessions are separately metered compute.
• Memory and retrieval. Storage plus the embedding and query costs of recall.

In practice: the highest-leverage cost control is almost always trimming the context sent on each step, because it multiplies across every step of every task. Summarising older turns, dropping tool output that has served its purpose, and keeping tool descriptions terse routinely cut cost by more than any infrastructure tuning.

AWS prices AgentCore on consumption with no upfront commitment, which is the right shape for spiky agent traffic and also the shape that makes a runaway loop expensive quietly. A per-session step cap and a spend alarm are cheap insurance, and the loop-engineering lessons in the catalogue cover why unbounded loops happen at all.