AgentCore: what AWS handles, and what an FDE still has to check

AWS announced a preview of Amazon Bedrock AgentCore on 16 July 2025. The product reached general availability on 13 October 2025. The product page sums it up in a short slogan: any framework, any model, security at scale.

For an FDE, the slogan matters less than the questions you will hear in the third meeting with the customer. By then the prompts are stable and the demo works. The people across the table are now the security team, and they ask three things: where does the agent run, who is allowed to call it, and where do we look at the logs when something goes wrong.

AgentCore answers those three questions with three components: Runtime, Identity and Observability. If you know exactly what each one does and does not yet do, you will move from pilot to production on the customer’s AWS much faster.

What it does, and what it does not promise

AWS’s documentation describes AgentCore as a modular platform for building, deploying and running agents. It works with any framework and any foundation model, and you do not have to manage the infrastructure yourself.

Mission Cloud, a partner that sells AgentCore implementation services, says the platform consists of seven managed services. The partner has a commercial interest in saying so, so treat the figure of seven as its own way of counting.

This article picks the three services tied to the security team’s three questions rather than covering the whole product. Two other capabilities, Gateway and Agent Registry, come up only in the audit section below.

Runtime does not make you throw away existing code. You can write the agent in any framework, and it can talk to tools or other agents over MCP (Model Context Protocol) or A2A (Agent to Agent). So if the customer already has an agent, the first job is to move where it runs, not to rewrite it.

An example: choosing the right compute

Imagine you are working for a logistics company and need to take two agents to production. The first is an assistant for warehouse staff, where each question-and-answer session lasts only a few minutes. The second reconciles invoices overnight, and each run takes about 10 hours.

Runtime offers two compute types. With microVM, each user session runs in its own microVM with separate CPU, memory and filesystem. When the session ends, the microVM is destroyed and sanitised. Two warehouse workers therefore never share an environment, which makes this type a good fit for the first agent.

The second agent is different. A microVM session lasts at most 8 hours, so a 10-hour job would be cut off in the eighth hour. Instances allow sessions of up to 14 days and run on AWS-managed EC2 infrastructure inside the customer’s own account. That is usually exactly what compliance wants to hear.

So measure real session lengths before choosing compute; do not guess. One wrong number at the discovery stage can force you to redo the whole architecture.

Identity: no need for the customer to change IdP

Authentication built into Runtime is handled by AgentCore Identity. Each agent is given its own identity, and the system integrates with the identity provider the business already uses, such as Okta, Microsoft Entra ID or Amazon Cognito. According to AWS, customers do not have to migrate users to a new system or rebuild their sign-in flows.

This is the point to lead with when presenting to the customer. In the logistics example, warehouse staff sign in with the Okta accounts they use every day, while the reconciliation agent has its own identity, separate from human identities.

Observability comes built in, but audit falls short

AgentCore exports telemetry in an OpenTelemetry-compatible format, so the data can flow into whatever monitoring stack the customer already runs. Metrics, spans and logs are stored in Amazon CloudWatch in the customer’s account. Ready-made dashboards show session counts, latency, token usage and errors.

Audit is where to be careful. AWS’s documentation states plainly that CloudTrail currently covers only some capabilities, specifically Gateway and Agent Registry. A bank or a hospital may require every API call to leave a trail. In that case, raise the gap in the meeting itself; do not let the customer discover it after go-live.

Before the security review, build a table: one column for the customer’s audit requirements, the other for what CloudTrail currently records. Bringing that table into the room will earn far more trust than a promise that “AWS takes care of everything”.

Three common mistakes when moving agents to AgentCore

The first mistake is guessing session length. A job you think runs for 6 hours but actually stretches to 9 will exceed the microVM’s 8-hour limit, and the failure usually surfaces only once the customer’s real data starts flowing in.

The second is promising full audit just because CloudWatch is in place. Telemetry helps you debug; CloudTrail is what compliance asks about, and it does not yet cover every capability.

The third is rewriting the customer’s agent to “fit” the platform. Runtime accepts any framework and model, so the effort belongs in where the agent runs, its identity and its logs, not in agent logic the customer has already validated.

What to learn first, and how to put it on your CV

If you are just starting, learn Runtime first: the two compute types, the session limits and how to deploy an agent written in a framework you know. Then Identity with a real IdP, then reading traces in CloudWatch. Learn MCP and A2A alongside, since these protocols are not tied to AWS.

On a CV, a line saying “used AgentCore” says almost nothing. Describe three decisions. You chose compute based on measured session length. You connected the agent to the customer’s IdP and separated the agent’s identity from its users’ identities.

And you flagged the audit gap before go-live. If you do not yet have a real customer, rebuild the two-agent example above in a test account and write a README explaining each choice.

Tools will change, but the three questions keep their value: where does the agent run, who may call it, and is everything recorded. An FDE who can answer all three fluently is the one invited back for the next project.