标签：#agentcore

MCP 2026-07-28 dropped sessions. The initialize handshake is gone. The Mcp-Session-Id header is gone from Streamable HTTP. Protocol version, client info, and capabilities now travel in a _meta field on every request, so any instance can serve any call. The protocol is cleaner for it. This is the largest revision since launch, and it leaves both of the questions that block enterprise agent deployments exactly where they were. MCP standardizes how a model reaches a tool. Neither question lives inside that scope, and no future revision is likely to put them there: Who is the agent acting as, and what is it allowed to do? What happens when a process takes three days and the model context is gone? The spoiler: on AWS the parts already exist. Policy in AgentCore evaluates every Gateway call in Cedar against a principal, an action, and a resource, and writes the allow or deny to an audit log. Temporal policies, added in August 2026, extend that across an agent's trajectory, including human approval ahead of a privileged action. AgentCore Identity distributes the credentials. Step Functions holds anything measured in days. The remaining work is composition: deciding which principal each agent acts as, and what it may commit to. No service ships that decision. What the stateless redesign actually solved The stateless redesign removes real pain. Long-held SSE connections forced sticky routing, which pushed teams into shared session stores and gateway packet inspection just to scale horizontally. The new model provisions for request rate instead of concurrent users. A round-robin load balancer is now enough. Lambda, Cloud Run, and Workers become viable backends. Multi Round-Trip Requests (SEP-2322) handle elicitation without a held connection. The server returns an InputRequiredResult carrying what it still needs plus an opaque requestState blob. The client collects the answers and re-issues the same call with inputResponses and the echoed state. Any instance picks up the retr

Since AWS Blocks entered public preview in June 2026, I have been making small contributions to the open-source project. AWS Blocks on GitHub In my previous post on AWS Blocks, Amplify, and App Studio , I looked at how these tools differ and what each is trying to achieve. While revisiting the Agent Block, one detail caught my attention: The AWS Blocks Agent is not currently running on Amazon Bedrock AgentCore. At a glance, it is easy to assume the relationship looks like this: AWS Blocks └─ Agent └─ Amazon Bedrock AgentCore But that is not how the current implementation works—at least not on main as of August 12, 2026. Then the story gets interesting. When I wondered whether an agent should simply use AgentCore directly, I found a fairly concrete set of pull requests that proposes moving the Agent Block's execution model to AgentCore Runtime. I contribute to AWS Blocks, but this is not an AWS statement or a roadmap. It is my reading of the public documentation and the open-source repository, from the perspective of both a user and a contributor. TL;DR The Agent Block on the current main branch does not run on AgentCore Runtime. It combines the Strands Agents SDK with AsyncJob , Realtime , FileBucket , and DistributedTable . A five-PR stack proposes migrating the Agent Block's execution model to AgentCore Runtime. As of August 12, 2026, all five migration PRs are still draft and unmerged. They are not an official roadmap. A separate open PR proposes Blocks for AgentCore Memory, Gateway, and Identity. So the most accurate conclusion today is this: AWS Blocks Agent is not AgentCore today, but the repository contains concrete proposals for bringing the two together. The Agent Block today is not AgentCore Let's start with the implementation on main . The Agent Block uses the Strands Agents SDK . But it is not a standalone agent runtime; it composes several Blocks to handle execution, streaming, and persistence. At a high level, the structure looks like this: Agent ├─ St

I've been building AI agents for a while now, and streaming responses to a UI has always been the painful part. In previous projects I tried API Gateway streaming, Lambda response streaming, and even AppSync Events via an agent tool call to notify the UI. I also looked at adding my own WebSocket API through API Gateway, which requires managing $connect , $disconnect , and $default routes, storing connection IDs in DynamoDB, and posting messages back through @connections . All of these approaches felt like too much ceremony for what should be simple. That's when I found that AgentCore has built-in WebSocket support. The browser can just connect directly to the agent. No middleman. I built WearCast to demonstrate this functionality. This is an AI agent that helps you pick out what to where based on the weather. I've found this very helpfu when packing for a trip. The code for this application is public and you can find the full implementation on this GitHub repo . The problem with the traditional approach We usually build app applications as we do REST APIs User → REST API → Lambda → AI Service → Lambda → REST API → User Every message makes a round trip through multiple intermediaries. The response waits until the entire generation is complete, and then it all comes back at once. For a chat interface, this feels sluggish. Users stare at a spinner while the model generates hundreds of tokens they could already be reading. Even if you add Server-Sent Events or long-polling, you're still stitching together a real-time experience on top of infrastructure that seemed like overkill. I wanted something better. The architecture Here's what I ended up with: ┌─────────────┐ ┌──────────────────┐ │ React UI │─── JWT ─▶│ API Gateway + │──▶ Lambda (presigned URL) │ (Cognito) │ │ Cognito Auth │ └──────┬──────┘ └──────────────────┘ │ │ WebSocket (SigV4 presigned URL) │ ← No middleman! Direct connection → ▼ ┌──────────────────────────────────┐ ┌────────────────────┐ │ AgentCore Runtim