AWS removes the agent underlay, the hook remains

6 min. read

AWS has shipped two products that are constantly lumped together: the Agent Toolkit, which puts 300 services and 15.000 API actions at the fingertips of an AI coding agent, and Bedrock AgentCore, the operational platform featuring a serverless runtime for production agents. Both eliminate weeks to months of plumbing work. The cost doesn’t show up on the invoice; it’s baked into the architecture.

Key Takeaways

• Two products, one misconception: The Agent Toolkit wires your developer agent directly to AWS, while AgentCore runs those agents serverlessly afterward. Confuse the two, and you’ll be evaluating the wrong tool.
• The foundation is the real offering: Session isolation, memory, identity, and observability are usually built by every team from scratch. AgentCore bundles these into modular building blocks, taking care of the most tedious part.
• Open at the top, locked at the bottom: Frameworks like LangGraph or CrewAI remain portable. The operational layer beneath them is AWS. That’s exactly where the vendor lock-in forms, and where you’ll feel it later.

Related:Cursor Cloud Agents: Coding, even when the laptop is closed  /  Reserved Instances: The coverage metric that proves nothing

Two tools that are constantly confused

Most of the confusion in early architecture planning stems from two releases sharing the same first name. One is called Agent Toolkit for AWS, the other Amazon Bedrock AgentCore. They solve different problems and belong to different phases.

What is the Agent Toolkit for AWS? A bundle comprising an MCP server, curated skills, and plugins that gives AI coding agents like Claude Code, Cursor, or Codex secure, auditable access to AWS. The MCP server covers over 300 services and more than 15.000 API actions, plus sandboxed script execution and real-time access to up-to-date documentation.

So, the toolkit helps with building. It gives the agent writing your code hands-on access to CloudWatch logs, CloudFormation statuses, and troubleshooting procedures. There’s no extra charge; you only pay for the AWS resources the agent actually touches.

AgentCore picks up where the toolkit leaves off: the runtime for operations. Once the agent is built and ready to handle user sessions, it runs here-serverless, with isolated sessions and persistent memory. Together, the two products form a chain from the first prompt to production traffic. Evaluated separately, they make perfect sense. Mixed together, they lead to a requirements list that never quite fits.

What the Underlying Infrastructure Takes Away from the Developer

The most honest part of the offering is the invisible one. Every team that has deployed an agent knows the list of things no one wants to build but everyone must. AgentCore breaks down exactly this list into modular building blocks. The seven that most strongly shape daily work:

• Runtime: serverless environment with low latency and session isolation, open for any framework.
• Memory: short-term context per session and long-term insights about semantic extraction.
• Identity: secure access of the agent to AWS and third-party services like GitHub, Salesforce, or Slack.
• Gateway: transforms existing APIs and Lambda functions into tools the agent can use via MCP.
• Observability: step-by-step visibility into execution with OpenTelemetry integration.
• Browser: managed browser instances for large-scale web automation.
• Code Interpreter: isolated environment for code generated by the agent itself.

Anyone who has ever set this up manually can immediately see the value. Session management, identity brokering, and a memory layer that doesn’t break with every deployment can quickly consume weeks or even months of a small team’s time. This time rarely flows into the product-it almost always goes into plumbing. We’ve written this plumbing playbook far too often ourselves.

An example makes the difference tangible. The Gateway takes an existing Lambda function or internal REST API and turns it into a tool the agent can call via the Model Context Protocol. Previously, this meant building an adapter, a schema description, and an authentication layer manually for each function. Now it’s just a registration. It sounds like a small thing, but across a dozen tools, it adds up to exactly the kind of work no one wants to see in the sprint planning. Similarly, Identity handles access: instead of storing GitHub or Salesforce keys in environment variables, the component brokers access at runtime. That means less code and less attack surface.

Where the Bill Lies: Binding Instead of Fees

The second perspective is worth considering. AWS sells openness, and that’s true. AgentCore supports CrewAI, LangGraph, LlamaIndex, Strands and its own frameworks. Your agent code is therefore not locked in. What you could potentially port is the logic.

What you do not port is the operational layer. Runtime, Gateway, Identity and Memory are AWS-specific. As soon as your agent is running productively on it, the way it is deployed, authenticated and monitored depends on this stack. The binding sits one level deeper than the framework, exactly in the part you just had removed.

This is not an argument against AWS. It is the usual business of every managed platform. The question is only whether you consciously buy the binding or collect it as a side effect of a quick prototype. The difference between the two is about the width of an audit.

When the Leap is Worthwhile

For most teams planning their first productive agent today, the trade-off is fair. Those who haven’t yet run their own Memory and Identity layers gain more time than they lose in optionalities. The lead counts as long as the Use-Case hasn’t been proven yet.

Things look different when Multi-Cloud is already the norm or when data residency and sovereignty are strictly regulated. Then the operational layer becomes a strategic decision that you don’t make on the side. In this case, it makes sense to compare with self-hosting using the framework before the first production agent is set up on AgentCore.

Practically speaking, this means: prototype on the managed stack, architecture decision before the production rollout. Those who use the toolkit for building and only decide on runtime after a sober lock-in calculation get the best of both worlds. Those who reverse the order let the prototype dictate the architecture. It goes well for a while and becomes expensive exactly when you have the least time for migration.

Frequently Asked Questions

How much does the Agent Toolkit for AWS cost?

The toolkit itself costs nothing extra. You are only billed for the AWS resources that the agent creates or accesses during its work, at standard service prices.

What is the difference between Agent Toolkit and AgentCore?

The Agent Toolkit supports development by giving coding agents access to AWS services. AgentCore is the operational platform with a serverless runtime where finished agents are run in production with isolated sessions, memory, and observability.

Am I tied to a specific agent framework with AgentCore?

No. AgentCore works with CrewAI, LangGraph, LlamaIndex, Strands, and custom frameworks. The lock-in sits one level deeper, in the operational layer consisting of runtime, gateway, identity, and memory.

How does an agent access external services via AgentCore?

Through the identity component. It brokers secure access to AWS services and third-party services like GitHub, Salesforce, or Slack, so the agent doesn’t have to work with hardcoded keys.

Which teams should get started right away?

For teams without their own memory, identity, or observability layer whose use case is not yet proven. Anyone with multi-cloud or strict data residency requirements should consciously decide on the operational layer before the production rollout.

More from the MBF Media Network

Image source: AI-generated (June 2026)