Two hyperscaler agent runtimes, head to head: sandboxed sessions, memory, tool catalogs, channels, and the pricing models that actually decide which one you ship on.
Foundry Agent Service vs Bedrock AgentCore: which hosted runtime should you pick?
Pick Bedrock AgentCore if you want a fully generally available, component-priced runtime you can deploy any framework on today; pick Foundry Agent Service if your users live in Microsoft Teams and Microsoft 365 Copilot and you value one-click publishing into them. That is the short version of the Foundry Agent Service vs Bedrock AgentCore decision, and the rest of this comparison shows the evidence behind it.
Both are hosted agent runtimes: managed compute that runs your agent loop, isolates each session, gives it a filesystem and memory, and scales to zero when idle. They are not low-code builders like Copilot Studio, and they are not model APIs. They are the layer underneath, the part that turns agent code into a production service with networking, identity, and observability attached.
The crucial status difference as of June 2026: Amazon Bedrock AgentCore has been generally available since October 2025. Microsoft’s equivalent, the new hosted-agents runtime inside Foundry Agent Service, is in public preview, announced April 22, 2026, with general availability expected by early July 2026 per the Microsoft Foundry Build 2026 announcements. The broader Foundry Agent Service (the Responses API runtime and evaluations) went GA on March 16, 2026, but the sandboxed hosted-agents compute that competes directly with AgentCore is still preview.
If you have already deployed to AgentCore and want a refresher on the AWS side, our deploy an AI agent to AWS Bedrock AgentCore tutorial walks the full path. This piece stays neutral and compares the two runtimes feature by feature, dollar by dollar.
Bedrock AgentCore: GENERALLY AVAILABLE (since October 2025). Foundry Agent Service hosted-agents runtime: PUBLIC PREVIEW (announced April 22, 2026; GA expected early July 2026). Always re-check the vendor’s status page before committing production workloads.
How do the managed runtimes and sandboxed sessions compare?
Both runtimes give every agent session its own hardware-isolated sandbox with dedicated CPU, memory, and a filesystem, and both scale to zero so you pay nothing while idle, so on the core isolation primitive they are near-identical. The differences are in session limits and protocols, not the security model.
Bedrock AgentCore Runtime provisions a dedicated microVM per session. AWS documents a configurable session length from 60 seconds up to 28,800 seconds, an 8-hour maximum, after which the session terminates; sessions also terminate after a 15-minute inactivity threshold or a failed health check. That long ceiling is built for multi-step, long-running autonomous work where state accumulates across calls within one session.
Foundry’s hosted agents use what Microsoft describes as a VM-isolated sandbox per session with hypervisor-level isolation, a persistent filesystem that survives scale-to-zero events (“resume with filesystem intact”), and near-instant cold starts. Microsoft has not published a hard maximum session-duration figure for hosted agents at preview, so if you need a guaranteed long-running ceiling, AgentCore’s documented 8 hours is the concrete number to design against.
On protocols, both speak an OpenAI-compatible stateful interface (Foundry calls it OpenResponses with mapping to its Activity Protocol; AgentCore exposes its own Runtime invocation API plus MCP) and both offer a lower-level pass-through mode (Foundry’s Invocations protocol with AG-UI support) for custom request/response shapes. Framework code ports cleanly either way.
| Dimension | Foundry Agent Service (hosted agents) | Bedrock AgentCore Runtime |
|---|---|---|
| GA status (June 2026) | Public preview; GA expected early July 2026 | Generally available since Oct 2025 |
| Per-session isolation | VM-isolated sandbox, hypervisor-level | Dedicated microVM per session |
| Filesystem | Persistent, survives scale-to-zero | Isolated per-session filesystem |
| Max session duration | Not published at preview | Up to 8 hours (60–28,800s, configurable) |
| Idle / inactivity behavior | Scale to zero when idle | Terminates after 15 min inactivity |
| Scale to zero | Yes | Yes |
| Stateful protocol | OpenResponses (Responses API) | Runtime invocation API + MCP |
| Pass-through protocol | Invocations protocol, AG-UI | Custom payload invocation |
Is Bedrock AgentCore or Foundry more framework-flexible?
Both runtimes are explicitly framework-agnostic and let you deploy popular agent frameworks without a rewrite, so framework flexibility is effectively a tie, and your existing code is portable to either. This is the single biggest reason the Foundry Agent Service vs Bedrock AgentCore choice is reversible: the agent loop is no longer the lock-in.
Microsoft lists supported frameworks for hosted agents as LangGraph, the Microsoft Agent Framework (which reached a stable v1.0), the Claude Agent SDK, the OpenAI Agents SDK, and the GitHub Copilot SDK. AWS positions AgentCore Runtime as working with any framework, and any model, naming open-source options such as LangGraph, CrewAI, Strands, and the OpenAI Agents SDK, with models from Amazon Bedrock, Anthropic, Google, and OpenAI.
The practical takeaway: if you have a LangGraph or OpenAI Agents SDK agent today, you can containerize and deploy it to either runtime. The real switching cost is not the framework, it is the surrounding managed services, memory, tool gateway, and identity, that you bind to. Treat those as the components you are actually buying, because re-platforming them is the work.
Framework-agnostic is now table stakes. Both runtimes run the same LangGraph or OpenAI Agents SDK code, so your lock-in lives in the memory, tool, and identity services around the agent, not the agentHow do memory and tool catalogs differ between the two?
AgentCore ships memory and a tool gateway as generally available, separately metered services, while Foundry’s Memory and Toolboxes are both in public preview, so AWS is more mature here but Microsoft’s is bundled rather than line-item billed. If you want predictable, itemized memory and tool costs today, AgentCore is further along.
On memory, Foundry Agent Service added Memory in public preview with three tiers, procedural, user, and session, and Microsoft reported 7–14% absolute success-rate gains at near-baseline cost in early testing. AgentCore Memory is GA and splits into short-term and long-term, with consumption pricing you can model precisely (covered in the next section).
On tools, Foundry’s Toolboxes (public preview) provide a unified managed endpoint for tools, MCP clients, and enterprise data integration. AgentCore Gateway is GA and turns APIs, Lambda functions, and existing MCP servers into agent-callable tools with semantic tool search and IAM authorization. Both converge on the Model Context Protocol as the connective tissue, so tool definitions are increasingly portable across the two.
One more capability worth flagging: real-time voice. Foundry offers Voice Live, generally available for prompt agents and in public preview for hosted agents with custom orchestration, providing speech-to-speech, turn detection, and interruption handling. AgentCore does not bundle an equivalent managed voice channel; you assemble voice from other AWS services. If voice is core to your product, Foundry has the more turnkey path.
Foundry feature status at a glance (June 2026)
Hosted agents: public preview (GA expected early July 2026). Memory (procedural/user/session): public preview. Toolboxes: public preview. Voice Live: GA for prompt agents, public preview for hosted agents. Routines (scheduled/timer runs): public preview. Agent Optimizer (trace-driven improvement suggestions): coming soon in public preview. Publishing to Teams + M365 Copilot: planned GA June 2026.AgentCore component status at a glance (June 2026)
Runtime, Memory, Gateway, Browser tool, Code Interpreter, and Identity are all generally available as part of the platform GA in October 2025, across nine AWS regions (US East N. Virginia/Ohio, US West Oregon, Europe Ireland/Frankfurt, Asia Pacific Mumbai/Singapore/Sydney/Tokyo).What does Bedrock AgentCore vs Foundry pricing actually cost?
AgentCore publishes fully itemized consumption pricing you can model today, while Foundry had not published a public meter for hosted-agents compute at preview, which makes AWS the safer choice when you need a defensible cost estimate before you build. This is the sharpest practical split in the entire Foundry Agent Service vs Bedrock AgentCore comparison.
AgentCore Runtime charges $0.0895 per vCPU-hour and $0.00945 per GB-hour, billed per second with a 1-second minimum, and because agents spend much of a session idle waiting on model or tool responses, you are billed on active consumption rather than wall-clock time. AgentCore Memory charges $0.25 per 1,000 new short-term events, $0.75 per 1,000 long-term records stored per month (built-in), and $0.50 per 1,000 long-term retrievals. AgentCore Gateway charges $0.005 per 1,000 tool invocations, $0.025 per 1,000 search queries, and $0.02 per 100 tools indexed per month. New AWS customers get $200 in Free Tier credits.
Microsoft confirmed that Foundry hosted agents bill on a scale-to-zero model, you pay nothing while idle, which is structurally similar to AgentCore’s active-consumption approach. But the per-vCPU and per-GB rates for hosted agents were not published in the preview announcements we reviewed, so a like-for-like dollar comparison is not yet possible. For budgeting, that gap matters: you can build an AgentCore cost model in a spreadsheet now, but you cannot yet do the same for Foundry hosted agents.
The chart below shows AgentCore’s published unit rates side by side so you can see the relative weight of each component; runtime compute and memory retrieval dominate most real workloads.
Because Foundry’s hosted-agents compute rate wasn’t published at preview, any head-to-head ‘cheaper’ claim is premature. Model AgentCore precisely now; re-run the comparison once Foundry publishes its GA meter in early July 2026.
How do agents reach end users: channels and distribution?
Foundry Agent Service wins distribution decisively for Microsoft-centric organizations because it publishes agents directly into Microsoft Teams and Microsoft 365 Copilot, while AgentCore has no equivalent native end-user channel and expects you to build your own front door. If your users already live in Microsoft 365, this is the feature that tips the decision.
Microsoft is shipping one-click publishing from Foundry to Teams Chat, Microsoft 365 Copilot Chat, and BizChat, with identity, permissions, and policy flowing automatically and every published agent routed through the Microsoft 365 Admin Center for review and approval. That capability is planned for general availability in June 2026. Foundry also gives each agent an Entra Agent ID and supports OAuth 2.0 On-Behalf-Of for acting in a user’s context.
AgentCore takes the building-blocks approach: it secures and scales the runtime, gateway, memory, and identity, but you assemble the end-user channel yourself, whether that is a web app, Slack bot, or API. AgentCore Identity handles authentication to AWS and non-AWS resources (the latter billed at $0.010 per 1,000 tokens or API keys requested), but there is no managed Teams or Copilot publishing equivalent.
The strategic read: AgentCore optimizes for builders who want maximum control and AWS-native composition; Foundry optimizes for enterprises that want agents in front of Microsoft 365 users with minimal plumbing. Neither is wrong, they are betting on different buyers.
Pros
Cons
Foundry Agent Service vs Bedrock AgentCore: the verdict
Two strong runtimes, one preview asterisk
Choose Bedrock AgentCore for a generally available, transparently priced runtime you can deploy and forecast today, and choose Foundry Agent Service when distribution into Microsoft Teams and M365 Copilot, or turnkey real-time voice, outweighs the fact that its hosted runtime is still in preview. Both are credible production runtimes; the right answer depends on where your users are and how much you value GA certainty.
If you are AWS-native, need long-running sessions with a documented 8-hour ceiling, or must produce a defensible cost model before approval, AgentCore is the lower-risk pick right now. If you are Microsoft-native, want agents inside Teams and Copilot with identity and policy handled for you, and can wait for, or tolerate, the early-July GA, Foundry is compelling. Re-evaluate once Foundry publishes its hosted-agents GA meter, because that single data point will settle the pricing half of this comparison.
Builder’s take
I run agent infrastructure for Cyntr and Loomfeed, so I read these two runtimes the way I read a hosting bill: where does my money leak, and what locks me in? Here is how I’d actually choose between them.
- Both runtimes solved the same boring-but-hard problem: per-session isolation with a filesystem and scale-to-zero. That is the right primitive. If a vendor still hands you a long-lived container and calls it an ‘agent runtime,’ walk away.
- Pricing is the real differentiator, not features. AgentCore prices every component separately (runtime vCPU/GB, memory events, gateway calls) so you can model it on a spreadsheet today. Foundry’s hosted-agents meter wasn’t public at preview, and an unpriced preview is a budgeting risk I flag on every project.
- The lock-in is in the distribution, not the runtime. Foundry’s one-click publish to Teams and M365 Copilot is a genuine moat if your users live in Microsoft 365. AgentCore has no equivalent native end-user channel, you wire your own. Choose on where your users already are.
- Framework-agnostic is now table stakes on both. I bring the same LangGraph or OpenAI Agents SDK code to either. That means your switching cost is the surrounding services (memory, gateway, identity), not the agent loop, so treat those as the thing you’re really buying.
- Watch the GA labels. As of June 2026, AgentCore is fully GA; Foundry’s hosted-agents runtime is still public preview with GA targeted for early July. For anything load-bearing, I don’t put preview infrastructure on the critical path.
Frequently asked questions
It is split. The broader Foundry Agent Service, the Responses API runtime and evaluations, went generally available on March 16, 2026. The new hosted-agents runtime that competes directly with AgentCore is in public preview, announced April 22, 2026, with general availability expected by early July 2026 per Microsoft’s Build 2026 announcements.
Yes. Amazon Bedrock AgentCore reached general availability in October 2025 as a full platform, including Runtime, Memory, Gateway, Browser, Code Interpreter, and Identity, available across nine AWS regions with consumption-based pricing and no upfront cost.
It cannot be answered precisely yet. AgentCore publishes itemized rates ($0.0895 per vCPU-hour, $0.00945 per GB-hour, plus separate memory and gateway charges). Microsoft confirmed Foundry hosted agents bill on a scale-to-zero model but did not publish per-vCPU or per-GB rates at preview, so a like-for-like dollar comparison is not yet possible. Re-check after Foundry’s GA in early July 2026.
Yes. Both runtimes are framework-agnostic. Foundry lists LangGraph, Microsoft Agent Framework, Claude Agent SDK, OpenAI Agents SDK, and GitHub Copilot SDK. AgentCore advertises support for any framework and any model, naming LangGraph, CrewAI, Strands, and the OpenAI Agents SDK among others. Your agent code is portable; the surrounding services are the switching cost.
AgentCore Runtime documents a configurable session length from 60 seconds up to 28,800 seconds (8 hours), terminating on the 8-hour limit, after 15 minutes of inactivity, or on a failed health check. Microsoft has not published a hard maximum session-duration figure for Foundry hosted agents at preview, so AgentCore’s 8 hours is the concrete number if long-running sessions are a requirement.
Foundry Agent Service publishes directly to Microsoft Teams, Microsoft 365 Copilot Chat, and BizChat, with this planned for general availability in June 2026. AgentCore has no native managed end-user channel for Teams, Copilot, or Slack, you build your own front end on top of the runtime. If your users are in Microsoft 365, Foundry has the clear distribution advantage.
Primary sources
- Foundry Agent Service is GA: private networking, Voice Live, and enterprise-grade evaluations — Microsoft Foundry Blog
- Introducing the new hosted agents in Foundry Agent Service — Microsoft Foundry Blog
- What’s new in Microsoft Foundry | Build 2026 Edition — Microsoft Foundry Blog
- Amazon Bedrock AgentCore Pricing — Amazon Web Services
- Amazon Bedrock AgentCore is now generally available — Amazon Web Services
- Configure Amazon Bedrock AgentCore lifecycle settings — AWS Documentation
- Publish agents to Microsoft 365 Copilot and Microsoft Teams — Microsoft Learn
Last updated: June 2, 2026. Related: Agent Infrastructure.
