Agent infrastructure
Agents in production
AgentCore vs the tools layer: a clear comparison of AWS's agent runtime and where it fits — and where SaaS teams still need something else to unblock agents.
Amazon's Bedrock AgentCore launched in preview in July 2025 and reached general availability in October. It's now one of the most-asked-about pieces of agent infrastructure in enterprise architecture reviews. The question keeps coming back in the same shape: is AgentCore the thing we've been waiting for, or does it solve a different problem than the one we have?
This comparison is for engineering leaders at established B2B SaaS companies who are evaluating AgentCore as the runtime for their agent projects — and trying to work out whether it closes the gap between their agents and their own products. The short version: AgentCore is a strong agent runtime, but a runtime is not a tools layer. If your bottleneck is orchestration, sessions, and memory, AgentCore is a credible answer. If your bottleneck is that your agents can't reach what your product actually does, AgentCore won't move that.
AgentCore is a set of modular services for running agents in production on AWS. The pieces are sold separately and composable: Runtime (serverless execution with session isolation and long-running task support, up to 8-hour workloads), Memory (short- and long-term memory stores), Identity (delegated auth via OAuth/OIDC, IAM, and API keys), Gateway (turning APIs and Lambda functions into MCP tools), Browser (a managed headless browser), Code Interpreter (sandboxed code execution), and Observability (traces, metrics, logs through CloudWatch).
The positioning is framework-agnostic and model-agnostic. You can bring LangGraph, CrewAI, Strands, or your own orchestration, and you can call Bedrock models or external foundation model providers. AgentCore handles the operational substrate: how the agent runs, where its memory lives, how it authenticates, how you observe it. The Gateway component is the part most often mistaken for a tools layer — it wraps existing APIs or Lambda functions in MCP, so an agent can call them. That's a useful adaptor. It's not the same as generating, maintaining, and running tools against the parts of your product your APIs don't currently expose.
The tools layer is a separate concern in the agent stack. Its job is to give agents reliable, maintained, permissioned access to what a product can actually do — not just what its public API happens to expose today. For a deeper map of where this sits, see the agent stack reference.
A tools layer has three responsibilities. First, generation: producing tool definitions from the systems a company already owns — codebases, internal services, the surface area behind the UI — rather than waiting for an API rewrite. Second, runtime: executing tool calls as the authenticated user, handling failure, rate limiting, and auth lifecycle. Third, maintenance: keeping tools current as the product changes, ideally tied into the same CI and test infrastructure the engineering team already uses. The structural problem this addresses is the one most established SaaS companies hit: their APIs expose a fraction of what their products can do, and rewriting the API layer is a multi-year project. Your APIs expose roughly 2% of what your product can do — and agents need the other 98%.
The table makes the divide clear. AgentCore answers operational questions about agents. The tools layer answers the access question about products. They live at different points in the stack and the decisions about them are independent.
AgentCore is the right call when several conditions line up. You're already an AWS shop — your data lives in AWS, your IAM is the source of truth for identity, your observability is in CloudWatch. You want a managed runtime so your team isn't building session isolation, memory persistence, and long-running task handling from scratch. The agents you're building primarily call APIs and services that already exist and already expose what you need — internal microservices, AWS-native data sources, well-covered third-party APIs. You're comfortable with the Bedrock pricing model and the lock-in that comes from building on AWS-specific primitives.
It's particularly strong for agents that need long-running workloads (the 8-hour runtime is unusual), heavy memory requirements, or sandboxed code execution. If you're using Strands or LangGraph and want a production substrate without standing up Kubernetes, AgentCore is a credible default. For greenfield projects where the surface area you need is already covered by APIs, it can be the only infrastructure decision you need to make.
A tools layer is the right call when the bottleneck is access, not runtime. You have an established SaaS product with years of UI-driven capability that the API never caught up with. Your agent project has stalled — not because the model can't reason, but because half of what the agent needs to do has no API to call. Your engineering team has run the numbers on rewriting the API surface and the answer is 2–5 years. You've tried bespoke connectors per product or per integration and watched the maintenance cost compound — see the hidden cost of bespoke agent connectors for the shape of that curve.
This is the situation most established B2B SaaS companies actually find themselves in. The pattern is consistent enough that agent projects stall at the same point across companies. AgentCore Gateway can re-wrap whatever APIs you have as MCP tools — but if those APIs only cover 30% of what your product does, the agent still can't reach the other 70%. Wrapping a partial surface in a different protocol doesn't extend the surface.
The two choices aren't mutually exclusive. You can run agents on AgentCore and have a tools layer feed it tools. The point is that picking AgentCore doesn't decide the tools question — it leaves it open.
The reason this comparison gets confused is that AWS, Anthropic, OpenAI, and the agent framework vendors all touch the word tools in some way. Most of them mean the interface for an agent to call a tool. That's a real piece of infrastructure. It's not the same piece as making your product's capabilities accessible in the first place.
Pontil sits in the Tools-as-a-Service layer of the stack. We generate tools from systems you own, run them as the authenticated user, and keep them current as your product changes — no API rewrite, no bespoke connector treadmill. AgentCore is a good answer to how do I run my agents in production on AWS. We're a good answer to how do my agents reach what my product actually does. Teams evaluating both usually end up needing both, which is why we're built to be runtime-agnostic. If you want to see how the generation and maintenance side works against a real codebase, book a walkthrough.
If your agents are blocked on operational concerns — sessions, memory, identity, observability — and the APIs they need already exist, AgentCore is the right answer. It's well-engineered, the pricing is predictable, and the AWS-native integration is real value if you're already on AWS.
If your agents are blocked on access — your product can do things your API can't reach, and you've already tried the obvious workarounds — AgentCore won't solve that, and no amount of better runtime will. You need a tools layer. The honest answer for most established SaaS companies is that they need both, and the mistake is treating the runtime decision as if it also closes the tools question. It doesn't. Pick AgentCore for the runtime if AWS is where you live. Pick a tools layer for the access problem regardless of where you run.
Stay up to date on the ever changing agentic landscape.
GET STARTED
Start with a 30-minute discovery call
contactus@pontil.com
