AWS Bedrock AgentCore Just Went GA. Serverless Agent Runtime With Lambda-Priced Billing. The Agent Framework Wars Are Over And Nobody Told You.

Hey guys, Mr. Technology here.

It is Tuesday, July 28, 2026, and I have spent the last three hours reading the AgentCore GA blog post, the AgentCore pricing PDF, the Strands SDK 1.0 release notes, and a 47-page service composition guide that AWS published without any fanfare at 9:00 AM Eastern. The thing I want to talk about today is not another model release. There have been enough of those. The thing I want to talk about is the moment AWS quietly settled the agent runtime war that has been wasting your engineering team's time for the last eighteen months.

Friday morning, AWS made Bedrock AgentCore generally available. It is seven managed services that, taken together, are the first credible answer to the question every agent team has been asking since Claude 3.5 Sonnet shipped in October 2024: where do my agents actually run? Not the model. The model runs on Bedrock. The runtime. The orchestration. The long-lived state. The memory. The tool gateway. The identity. The observability. The thing that takes a model, gives it a goal, and lets it execute against real systems for minutes, hours, or weeks without falling apart.

Up until Friday, the answer to that question was "whatever your team cobbled together in a hurry." LangGraph for the loop. Postgres for the state. Redis for the cache. S3 for the artifacts. A custom WebSocket layer for streaming. A separate tool-calling proxy. A separate observability stack. A separate auth layer. A separate memory subsystem. Tens of thousands of lines of glue code that every agent team in the industry has been writing the same way, badly, in parallel. AWS just packaged that glue code, hardened it, made it pay-per-millisecond, and called it a managed service. That is the entire story. And it is the most consequential infrastructure release of 2026 so far.

Let me explain why.

What AgentCore Actually Is

AgentCore is not a single product. It is seven services, each of which corresponds to a piece of the agent runtime that every team has been building by hand. The list is short and the names are intentionally boring:

1. AgentCore Runtime — the execution environment. A session-isolated, containerized, microVM-backed sandbox with a 1.5 GB memory floor for each agent invocation, 8 vCPU ceiling, and a 15-minute maximum execution window per step. You ship your tool code as a Docker container, AWS provisions it on demand, and you pay per millisecond of vCPU time. Yes, this is Lambda. It is Lambda with a 1.5 GB floor and a 15-minute ceiling, which is exactly what most agent steps need. The session isolation is per-invocation, not per-account, which means you can run 10,000 concurrent agent steps against the same Bedrock model without any of them seeing each other's memory or filesystem.

2. AgentCore Memory — the persistence layer. A managed, namespaced, vector-and-key-value store with three access modes: short-term (per-session, automatic, 30-day TTL), long-term (cross-session, semantic, no TTL), and episodic (timestamped event log, queryable by range). The default memory schema is the OpenAI memory schema, which means existing LangChain and LlamaIndex memory adapters drop in without code changes. The semantic recall is backed by Titan v3 embeddings at $0.02 per million tokens, which is roughly what you would pay on your own with vLLM and a 7B embedding model. The difference is that you do not have to run the embedding model yourself.

3. AgentCore Gateway — the tool registry. A unified MCP-compatible endpoint that converts your existing Lambda functions, OpenAPI specs, and Smithy models into MCP tools with one Terraform resource. This is the bit that matters. Up until Friday, every agent team was either running their own MCP server (which is fine, but you have to host it, scale it, and keep it alive) or building one-off HTTP tool adapters per integration. The Gateway is the AWS-hosted MCP server. It does auth (SigV4, OAuth, IAM), throttling (per-tool rate limits), schema validation (JSON Schema 2020-12), and observability (CloudWatch metrics per tool call). Two lines of Terraform and you have a production-grade MCP endpoint.

4. AgentCore Identity — the credential vault. Long-lived OAuth tokens for SaaS tools (Salesforce, Slack, GitHub, Google Workspace) that the agent can mint short-lived access tokens from at runtime. Background token refresh. Just-in-time scope elevation. Per-agent identity isolation. Audit logs to CloudTrail. This is the feature that lets you actually ship an agent that touches a real production SaaS account without losing sleep.

5. AgentCore Browser — the headless browser. A managed, screenshot-streaming, CDP-compatible Chromium instance that agents can drive with the same Playwright or Puppeteer API they would use locally. The browser is session-isolated, has a 4 GB memory ceiling, and runs in the same VPC as your other AgentCore services. The latency from agent.click('#submit') to DOM update is 80 to 140 ms, which is competitive with a local headless Chrome. The browser is expensive to run ($0.092 per hour of active session) but the alternative is harder to operate than the cost makes it look.

6. AgentCore Code Interpreter — the sandboxed Python runtime. A Firecracker microVM with a CPython 3.12 environment, a 4 GB memory ceiling, a 30-minute execution window, and pre-installed data science stack (pandas, polars, numpy, scipy, matplotlib, plotly, scikit-learn). The agent can write Python code, execute it, and get the result back, all without egress to the public internet. The execution is 6 to 20 seconds cold start, sub-second warm. The pricing is $0.000016 per vCPU-millisecond, which is competitive with Lambda but with the data stack pre-installed.

7. AgentCore Observability — the tracing and metrics layer. OpenTelemetry-compatible traces from every agent step, every tool call, every model invocation, every memory access. The traces are searchable in CloudWatch with a 30-day TTL by default. The metrics are pre-aggregated: step latency, tool failure rate, token spend per session, cost per goal completion. The dashboard is functional, not beautiful, and it is the single best reason to put your agent on AgentCore instead of rolling your own LangGraph + Langfuse stack.

That is the seven-service suite. The price-per-millisecond billing model is the headline. AWS is pricing AgentCore like a serverless compute product, not like a managed service. The implication is that the unit economics of running an agent step on AWS are now within 8% of running it on a spare EC2 instance, with the operational complexity of running a Lambda function. That is a 10x reduction in the operational overhead of running a production agent.

Pricing Is The Actual Story

I want to spend a minute on the pricing because the press coverage is going to miss it. The pricing is the news.

AgentCore Runtime is $0.000016 per vCPU-millisecond after the first 1 million vCPU-milliseconds per month, which is $0.016 per hour of vCPU time at 1 vCPU. At 4 vCPU per step (the default ceiling), a 1-second step costs $0.000064. A 10-second step costs $0.00064. A 100-step agent session costs $0.064. A 100,000-step month costs $64. Compare this to your bill for the same workload on a self-managed ECS cluster with an M5.4xlarge ($0.768/hour, always on, regardless of load) and the ratio is 12:1 to 24:1 in favor of AgentCore for the workloads an agent actually generates.

AgentCore Memory is $0.25 per million reads, $1.00 per million writes, plus $0.02 per million tokens of embedding. For a 100-step agent session with 5 memory reads and 2 memory writes per step, the memory cost is roughly $0.000135 per session. Embedding cost is $0.000040 per session. Total: $0.000175 per session. A 100,000-session month is $17.50 in memory cost.

AgentCore Gateway is $0.05 per million tool invocations. For a 100-step agent with 6 tool calls per step, you are at $0.000030 per session. A 100,000-session month is $3.00 in gateway cost.

AgentCore Identity is $0.10 per million token mint operations. A 100-step agent with 2 token mints per session is $0.000020 per session. A 100,000-session month is $2.00 in identity cost.

AgentCore Browser is $0.092 per hour of active session. Active session means the Chromium instance is alive and a CDP connection is held. If your agent is driving the browser for 15 seconds per page load and 5 page loads per session, the browser is active for 75 seconds per session. That is $0.00192 per session. A 100,000-session month is $192 in browser cost. This is the single most expensive line item per step.

AgentCore Code Interpreter is $0.000016 per vCPU-millisecond (same as Runtime) plus $0.0001 per cold start. At 4 vCPU and a 10-second execution, the per-invocation cost is $0.00064 plus $0.0001 = $0.00074. For a 100-step agent with 2 code interpreter invocations per session, the cost is $0.00148 per session. A 100,000-session month is $148 in code interpreter cost.

AgentCore Observability is $0.10 per million spans ingested. A 100-step agent generates roughly 120 spans (each step + tool call + memory access emits one span). The per-session observability cost is $0.000012. A 100,000-session month is $1.20 in observability cost.

Sum it up. A 100,000-session month on AgentCore costs $428.40 in compute, plus your Bedrock model spend. Compare this to your bill for the same workload on a self-managed ECS cluster with an M5.4xlarge running 24/7 ($532/month per instance), a self-managed Redis ($45/month per instance), a self-managed Postgres ($95/month for RDS db.r6g.large), and a self-hosted Langfuse ($80/month for the Pro tier). The self-managed cost is $752/month per agent workload, before you add the operational overhead of running it. The AgentCore cost is $428/month. And the AgentCore workload can scale to 100x without any infrastructure changes. The self-managed workload can scale to 100x only with a 48-to-72-hour Kubernetes re-provisioning cycle and a procurement ticket.

I am going to put this in a table because the comparison is the entire point.

================================================================================
                                PER-MONTH COST (100,000 agent sessions)
                            Self-Managed ECS       AgentCore
--------------------------------------------------------------------------------
Compute (4 vCPU always-on)   $532                  $64.00
Memory (Redis + Postgres)    $140                  $17.50
Tool gateway (MCP server)     $0 (you host it)     $3.00
Identity (OAuth vault)        $45 (SSO provider)   $2.00
Browser (headless Chrome)     $90 (Playwright)     $192.00
Code interpreter (sandbox)    $180 (Firecracker)    $148.00
Observability (Langfuse Pro)  $80                  $1.20
--------------------------------------------------------------------------------
Subtotal                      $1,067               $427.70
Operational overhead          30 hrs/month         ~2 hrs/month
================================================================================

The cost comparison is 2.5x in favor of AgentCore. The operational overhead comparison is 15x in favor of AgentCore. And the elastic-scaling story is unbounded — the self-managed side cannot burst to 10x sessions without manual intervention, the AgentCore side handles it automatically.

This is the part every agent team needs to spend the afternoon with a spreadsheet on.

The Strands SDK Is The Quiet Win

The Strands SDK is the second piece of the AgentCore story and the one that the AWS marketing team is underselling. Strands is an open-source (Apache 2.0) Python and TypeScript SDK that provides the agent loop, the tool calling, the multi-agent coordination, the streaming, and the Bedrock model integration. It is the AWS-recommended way to write an agent that runs on AgentCore. It is also a perfectly good way to write an agent that runs anywhere else — the SDK is model-agnostic (works with Bedrock, Anthropic, OpenAI, Gemini, Llama, and any OpenAI-compatible endpoint) and runtime-agnostic (works on AgentCore, ECS, Lambda, your laptop, or any container host).

This is the bet. AWS is letting you write the agent in an SDK that does not lock you to the AWS runtime. The runtime is just a better, cheaper, more operationally simple place to run the agent. If you decide to leave, your code comes with you. If you decide to stay, you get the cost and operational benefits above.

This is the right bet. It is the same bet AWS made with the Lambda function runtime in 2014: do not lock people in with the language, lock them in with the operational experience. The result is that Lambda is the default serverless compute platform in 2026 not because Node.js or Python is uniquely good, but because Lambda is the easiest way to run code without thinking about servers. AgentCore is the same bet for agents. The code is portable. The experience is not.

Strands 1.0 ships with:

• A native agent loop with built-in token budgeting, context window management, and adapter-style tool plumbing.
• A multi-agent coordination primitive that supports supervisor, peer-to-peer, and hierarchical orchestration patterns without forcing you into a graph DSL.
• A streaming layer that pushes partial outputs to the client over Server-Sent Events, WebSockets, or the new AgentCore Realtime channel.
• A built-in observability hook that emits OpenTelemetry spans for every step, every tool call, every retry, and every branch.
• A model adapter that does the boilerplate of going from "the model said call tool X with arguments Y" to "the tool X was called with arguments Y and returned Z" without you writing the parser.

The SDK is 14,000 lines of Python and 8,000 lines of TypeScript. It is well-documented. It is well-tested. It is the first time a major cloud provider has open-sourced the agent loop itself instead of burying it in a managed service. That is a meaningful signal.

How AgentCore Compares To The Stacks You Are Already Running

I have been through the agent runtime stack articles I wrote in July — the one on the LangGraph-vs-Inngest-vs-Temporal-vs-Hatchet-vs-DBOS-vs-Restate comparison, the one on the no-framework pure-Python tool-calling loop, the one on the multi-agent substrate. Most of my readers are running one of these stacks. Here is how AgentCore compares.

Against LangGraph: LangGraph is a good orchestration primitive. The DAG model is clean. The persistence layer is solid. The dev experience is excellent. AgentCore delivers the same orchestration primitive through the Strands SDK with a managed runtime, managed memory, and a managed gateway. You do not lose LangGraph's expressiveness — Strands can express the same DAG patterns — but you also do not have to run the DAG persistence, the checkpointing, the retry logic, or the human-in-the-loop infrastructure. The break-even point is roughly 10,000 sessions per month. Below that, self-managed LangGraph is cheaper. Above that, AgentCore is cheaper and dramatically less operationally expensive.

Against Inngest: Inngest is the closest spiritual competitor. The durable execution model, the event-driven step functions, the retry-with-jitter semantics are all there. Inngest is self-hosted or Inngest Cloud. AgentCore is AWS-native. The unit economics favor AgentCore for workloads under 100 ms per step (the Lambda-style pricing dominates). The unit economics favor Inngest for workloads over 10 seconds per step (the durable execution model is more efficient). For an agent with 6 to 10 steps per session averaging 1 to 5 seconds per step, the two are within 15% of each other on cost. The deciding factor is operational simplicity, which goes to AgentCore.

Against Temporal: Temporal is the durable execution standard. The Temporal Workflow model is the most rigorous expression of "long-running, retry-safe, exactly-once" agent orchestration that exists today. AgentCore is not Temporal. The 15-minute step ceiling and the session-isolation model are not designed for the multi-day workflow patterns Temporal was built for. If your agent runs multi-day workflows with external system dependencies and human-in-the-loop stages, run Temporal. If your agent runs 5 to 30 minute sessions with 5 to 100 steps and a single human-in-the-loop at the end, AgentCore is the better fit.

Against Hatchet: Hatchet is the open-source alternative to Inngest and Temporal. The architecture is similar. The cost is lower than the managed offerings. The operational complexity is comparable to Inngest. Same comparison as Inngest: AgentCore wins on operational simplicity for short-step workloads, Hatchet wins for long-running multi-day workflows.

Against DBOS: DBOS is the database-native agent framework. The idea is that the agent's state lives in Postgres from day one, and the orchestration is just SQL queries. The cost is low (RDS Postgres pricing), the durability is excellent, the operational surface is small. AgentCore is not a database-native framework. The Memory service is a managed persistence layer but it is not Postgres. If your agent's state model is fundamentally relational (workflow dependencies, audit trails, business rules), DBOS is a better fit. If your agent's state model is conversational (memory, tool history, episodic recall), AgentCore is a better fit.

Against Restate: Restate is the fast-restart-correctness framework. The execution model is "checkpoint everything, restart from the last checkpoint." The cost is low. The latency is excellent. Same comparison as the durable execution frameworks: AgentCore wins on operational simplicity for short-step workloads, Restate wins for the specific case where you need exactly-once semantics across a heterogeneous system of downstream services.

Against the pure-Python no-framework loop: The pure-Python loop with manual retry, manual checkpointing, and manual observability is the 200-lines-of-glue pattern I wrote about in June. It is the cheapest option for prototyping. It is the most operationally expensive option for production. AgentCore is the production version of the pure-Python loop. The break-even is roughly 1,000 sessions per month in production. Below that, the pure-Python loop is fine. Above that, AgentCore is the responsible choice.

The honest summary: AgentCore is the right default for new agent projects in the second half of 2026. Existing agent projects on LangGraph, Inngest, Temporal, DBOS, or the pure-Python pattern should not migrate for the sake of migrating. They should migrate when the operational overhead of running their current stack exceeds the cost difference. For most teams, that is happening now.

What AgentCore Is Not Good At

I want to be honest about the limits because nobody at AWS is going to be.

AgentCore is not a multi-region service. Today, AgentCore is available in us-east-1, us-west-2, eu-west-1, and ap-northeast-1. The cross-region replication model is asynchronous, with a 5 to 15 second replication lag. The agent session is pinned to the region it starts in. If your users are globally distributed, the latency to the agent is region-dependent. If you need active-active multi-region agents, AgentCore is not the answer yet. Run AgentCore in one region and front it with a global routing layer.

AgentCore is not a self-hosted product. You cannot run AgentCore on-prem. You cannot run AgentCore in your VPC. The Runtime and Browser services run in AWS-owned accounts. The Identity service has a VPC endpoint, but the actual credential vault is AWS-managed. If you have a strict data-residency requirement that excludes AWS, AgentCore is not the answer. Run LangGraph + Temporal + your own Postgres + your own MCP server.

AgentCore is not cheap for always-on workloads. If your agent is running 24/7 with a steady stream of sessions, the per-millisecond pricing is more expensive than running an EC2 instance. The break-even is roughly 30% sustained utilization. Below that, AgentCore is cheaper. Above that, an EC2 instance is cheaper. Most agent workloads are below 30% sustained utilization. If you are running a 24/7 batch agent that does data processing, EC2 is cheaper.

AgentCore Code Interpreter is not a full Jupyter environment. It is a CPython sandbox with a fixed data science stack. There is no interactive notebook. There is no session persistence between code interpreter invocations. The agent has to write its code, execute it, and capture the result in one step. If your agent needs an interactive REPL with state preserved across steps, AgentCore Code Interpreter is not the answer.

AgentCore Browser is expensive. The $0.092 per hour of active session is two to three times the cost of running a self-hosted headless Chrome on a Spot Instance. If your agent is driving the browser for 60+ seconds per page load, AgentCore Browser is uneconomical. Run a self-hosted browser farm and call it from AgentCore Gateway.

AgentCore Memory is eventually consistent. The cross-region replication is asynchronous. The long-term memory semantic recall is a 200 to 400 ms query. The episodic memory range queries are 100 to 300 ms. If your agent needs strict consistency with sub-50ms latency on memory access, run your own Redis cluster.

These are the trade-offs. The AWS marketing team is not going to spell them out. I am.

What You Should Do This Week

I am going to be concrete because I want this to be useful, not philosophical.

If you are starting a new agent project today: Build it on AgentCore. Use Strands SDK. Use Bedrock for the model. Use the Gateway for tools. Use Memory for persistence. Use Observability for tracing. The total cost is $400 to $500 per million sessions, which is the lowest available for a managed agent runtime. The operational overhead is 2 hours per month. The path to production is 2 to 4 weeks, not 2 to 4 months.

If you are running LangGraph + Langfuse + Postgres + Redis: Migrate the production workloads that are above 10,000 sessions per month. Leave the prototype and low-volume workloads on the existing stack. The migration is a 2 to 4 week project per workload. The cost savings are 40 to 60%. The operational overhead reduction is 10x.

If you are running Temporal or Inngest: Do not migrate. The long-running workflow patterns these tools are built for are not what AgentCore is optimized for. Use AgentCore for short-lived agent loops. Use Temporal or Inngest for durable execution workflows. The two compose cleanly — you can have a Temporal workflow that calls an AgentCore agent as a step.

If you are running DBOS: Evaluate per workload. If your agent's state model is fundamentally relational, stay on DBOS. If your agent's state model is conversational, migrate to AgentCore Memory. The Strands SDK has a DBOS persistence adapter that lets you keep the relational state layer and add the conversational memory layer incrementally.

If you are running the pure-Python no-framework loop: Migrate the production workloads. The pure-Python loop is fine for prototyping but it is not a production runtime. The path to production-ready on AgentCore is 1 to 2 weeks per workload. The cost and operational benefits are significant.

If you are a vendor building an agent platform: AgentCore just commoditized the runtime layer. Differentiate on the model, the tools, the memory, the observability, or the dev experience. Do not differentiate on the runtime. The runtime is now a $400/month line item per million sessions. The race to the bottom is over.

Mr. Tech's Take

AWS Bedrock AgentCore GA is the most consequential agent infrastructure release of 2026. It is the moment the agent framework wars ended. The previous winners were LangGraph for orchestration, Temporal for durability, Langfuse for observability, Postgres for state, Redis for cache, and a custom MCP server for tools. The new winner is AWS, because AWS just packaged all of those into a single managed suite with Lambda-style pricing.

The teams that are still running their own LangGraph + Postgres + Redis + Langfuse stack are not wrong. They will be right for another 6 to 12 months. After that, the operational overhead argument alone will force the migration. The teams that are running Temporal or Inngest for long-running workflows should stay. The teams that are running them for short-lived agent loops should migrate the loops to AgentCore and keep the durable workflows in Temporal.

The next question is what AWS does next. The obvious move is a managed vector database for RAG (the current Bedrock Knowledge Bases is good but lacks the pgvector-level operational control). The next obvious move is a managed fine-tuning runtime (the current Bedrock Model Customization is a notebook, not a service). The next obvious move after that is a managed RLHF runtime. The next obvious move after that is a managed multi-agent coordination service with conflict resolution and consensus primitives.

AWS is going to package the entire agent stack over the next 18 months. The framework vendors who are not differentiating on the model, the tools, or the dev experience will be acquired, deprecated, or out-competed by the end of 2027. The runtime layer is now a commodity. The race is over.

It is Tuesday. You have a weekend to read the AgentCore docs. Monday morning, you should be running a proof-of-concept. The cost is $400 per million sessions. The dev experience is the best in the industry. The operational overhead is two hours per month. The agent framework wars are over.

Build accordingly.

— Mr. Technology

Quick Summary

• What: AWS Bedrock AgentCore GA — 7 managed services for agent runtime
• When: Friday July 25, 2026 (GA), Tuesday July 28 general availability
• Where: us-east-1, us-west-2, eu-west-1, ap-northeast-1 (4 regions at GA)
• Cost: ~$428 per 100,000 sessions (vs $1,067 self-managed ECS)
• Break-even: Self-managed cheaper below 10K sessions/month; AgentCore cheaper above
• Strands SDK: Open-source Apache 2.0, Python + TypeScript, model-agnostic, runtime-agnostic
• Replaces: LangGraph + Postgres + Redis + Langfuse + custom MCP server for most workloads
• Does not replace: Temporal or Inngest for long-running multi-day workflows
• Biggest line item: AgentCore Browser at $0.092/hour (2-3x more expensive than self-hosted)
• Biggest win: AgentCore Gateway at $0.05 per million tool invocations (replaces self-hosted MCP)

Sources

• AWS Bedrock AgentCore GA announcement, July 25, 2026, aws.amazon.com/bedrock/agentcore.
• AWS Bedrock AgentCore pricing page, July 2026, aws.amazon.com/bedrock/agentcore/pricing.
• AgentCore service composition guide, 47 pages, AWS, July 2026.
• Strands SDK 1.0 release notes, Apache 2.0, github.com/awslabs/strands, July 2026.
• AWS Bedrock AgentCore Runtime architecture white paper, July 2026.
• AWS Bedrock AgentCore Memory reference architecture, July 2026.
• AWS Bedrock AgentCore Gateway MCP compatibility guide, July 2026.
• AWS Bedrock AgentCore Identity OAuth token rotation guide, July 2026.
• AWS Bedrock AgentCore Browser CDP integration guide, July 2026.
• AWS Bedrock AgentCore Code Interpreter CPython 3.12 sandbox spec, July 2026.
• AWS Bedrock AgentCore Observability OpenTelemetry spec, July 2026.
• LangGraph 1.0 documentation, langchain-ai.github.io/langgraph, July 2026.
• Temporal durable execution reference, temporal.io/blog, July 2026.
• Inngest durable execution reference, inngest.com/docs, July 2026.
• Hatchet open-source durable execution, github.com/hatchet-dev/hatchet, July 2026.
• DBOS durable execution framework, dbos.dev, July 2026.
• Restate durable execution framework, restate.dev, July 2026.
• Anthropic Claude Sonnet 5 pricing benchmarks, for Bedrock model spend comparison.
• Mr. Technology — The 2026 Agent Runtime Stack: Why "Just a Loop" Beats Every Framework for 80% of What You're Building, July 8, 2026.
• Mr. Technology — Frontier API Lock-In Died This Week. Here's the Multi-Vendor Stack That Replaces It., July 21, 2026.
• Mr. Technology — Reasoning Models Just Killed Your Cost Predictability — Here's the Observability Stack That Fixes It, July 14, 2026.
• Mr. Technology — Anthropic Just Finished the Claude 5 Lineup — And Opus 5 Is the One You'll Actually Use, July 27, 2026.