Getting an agent onto the platform — and when not to
Lesson 1 of 5 in AWS Agents in Practice: Deploy, Authorize, Guard, Observe, Pay.
The previous module was a catalogue: what each AgentCore service is. This one is day two. You have an agent that works on your laptop, and now somebody wants it running for real users, with an on-call rotation and a bill somebody has to justify.
Five questions decide whether that goes well, and they are the five lessons here: where does it run, whose authority does it act with, what stops it doing the wrong thing, how do you find out what it did, and what does each session cost. None of them is about the loop. All of them are about the platform around the loop.
Start with packaging, because it is the first thing that surprises people: there is more than one shape of "deploy an agent" on AgentCore, and they differ in what you hand over.
The managed harness is the declarative path — you call CreateHarness with a model, tools and instructions and run it with InvokeHarness. AWS is explicit that this means no orchestration code and no container to build, which tells you something about the other path: a code-defined agent on Runtime is your build artifact, and everything a build artifact implies — a base image, dependency pinning, a CI job, a rollback story. The harness reached public preview in April 2026 and general availability in July 2026 across all AgentCore regions; GA added built-in memory by default, more model providers, versioning and endpoints, and an export-to-Strands-code escape hatch.
That escape hatch is the honest way to read the harness: it is a fast start you are not locked into. AgentCore remains framework- and model-agnostic — CrewAI, LangGraph, LlamaIndex, Strands, the OpenAI Agents SDK, the Claude Agent SDK, or your own code, against models on Bedrock or elsewhere.
| Substrate | What you hand over | Session model | Pick it when |
|---|---|---|---|
AgentCore harness | A declaration: model, tools, instructions. No container, no orchestration code. | Managed, with memory on by default. | The loop is unremarkable and you want to be in production this week. Export to Strands code later if it stops fitting. |
AgentCore Runtime — microVM sessions | Your agent as a deployable artifact, plus a health-check contract. Check the developer guide for the current packaging details. | One dedicated microVM per | You need real session isolation and long-running work, and your own framework or orchestration code. |
AgentCore Runtime Instances | The same artifact, plus a capacity-provider choice of EC2 family (GPU, memory- or compute-optimized). | Isolated EC2 instance per session, up to 14 days, with persistent volumes that survive a stop and re-attach on resume under the same | The work spans days, or needs a GPU, or needs a working tree and caches to survive an overnight pause. |
Plain Lambda / ECS / EKS | Whatever you already deploy today. | Whatever your platform gives you — no per-session microVM boundary unless you build one. | Short, stateless, request-response agent calls inside an app you already operate. AWS supports this: Evaluations and Observability both work for agents on Lambda, EKS or non-AWS environments. |
Read that spec box as three operational commitments, not three trivia items.
One: isolation is a property of the substrate, not of your code. Two users hitting the same agent at the same second get two microVMs, so nothing the first wrote to disk can be read by the second — because there is no shared disk to read. You do not have to trust your own tenant-scoping code for filesystem leakage. You still have to trust it everywhere else.
Two: ephemeral means ephemeral. Anything you want after the session ends goes to AgentCore Memory, S3, or a database during the session. Teams learn this by losing a scratch file they assumed would still be there.
Three: the 15-minute inactivity timeout is a default you can defeat. A background task that keeps answering health checks with HealthyBusy keeps the session Active — useful when the agent is genuinely working on something long, and expensive when it is not. Lesson five prices that mistake.
Where should this agent run?
Interactive decision tree — outcomes:
- Plain Lambda / ECS / EKS is fine
A short, stateless, request-response agent inside an app you already operate does not need a new substrate. You can still adopt AgentCore piecemeal: Observability accepts telemetry from agents hosted anywhere via the ADOT SDK, and Evaluations works against agents on Lambda, EKS or non-AWS environments. Adopt a service to solve a problem, not to relocate.
- Managed harness
Declare model, tools and instructions; skip the container and the orchestration code. GA since July 2026 in all AgentCore regions, with memory on by default and versioning and endpoints for release management. If it stops fitting, export to Strands code and move to Runtime — that path is documented, which is the main reason the harness is a safe starting point.
- Runtime — microVM sessions
Your artifact, one dedicated microVM per session, up to 8 hours, filesystem destroyed and memory sanitized on termination. Budget engineering time for the build pipeline you just took on, and put anything durable in Memory or S3 before the session ends.
- Runtime Instances
Sessions on isolated EC2 instances from a capacity provider, up to 14 days, with persistent volumes that re-attach on resume under the same runtimeSessionId. GA August 2026. Two consequences to plan for: deleting a session deprovisions its volume, and you pay managed-compute charges in addition to EC2 costs.
Key terms: agent loop, session isolation, sandboxing, memory, blast radius
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.