Agent Identity and Durable Workflows: The Two Problems MCP Can't Solve

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 retry, because the continuity rides in the payload. Mid-conversation failover stops being a data-loss event. The release also hardened authorization: RFC 9207 issuer validation, RFC 8707 resource indicators against the confused-deputy problem, client metadata documents replacing dynamic client registration, and Enterprise Managed Authorization as a named extension. That work is real. It secures the channel between a client and a server, and it settles which server a token was minted for. The question enterprise platform teams keep raising sits one layer up: which principal the agent acts as inside that channel, and what that principal may commit to. Identity: four principals behind one request A pilot agent usually runs on one set of developer credentials. It can reach whatever the developer can reach. That works while prototyping. In production it is a standing incident. An enterprise platform has to separate four things: - The human who initiated the work, a*****@example.com - The agent as a software principal, production-planning-agent - The runtime session, meaning the specific execution context - The delegated task, meaning what was actually requested Permissions do not flow automatically from the first of these to the rest. A finance director can approve €50,000 payments. A meeting-summary agent running on that director's behalf has no business inheriting that authority. The effective permission at any moment is the intersection: human permission ∩ agent permission ∩ task scope ∩ current policy Capability levels instead of binary access Can-or-cannot access to a service is too coarse for an agent. Split it into levels: | Level | Example | |---|---| | Read | View production schedule | | Analyze | Run what-if scenarios | | Recommend | Propose schedule changes | | Simulate | Execute in sandbox | | Create draft | Write proposal for review | | Request approval | Trigger human decision | | Execute | Commit the change | | Approve | Authorize another's request | An agent may simulate a production-plan change without publishing it. It may request approval for a change it has no authority to execute itself. Each level carries different risk, different audit requirements, and different authorization rules. What decides where the approval line sits is consequence rather than technical risk: money, employment, legal rights, or access to a service. Anything that touches one of those belongs above "request approval." Treating agent identity as a security discipline AWS Identity and Access Management (IAM) and Amazon Bedrock AgentCore Identity each cover part of this: delegated access, OAuth flows, machine-to-machine auth, credential distribution, audit trails. The architectural principle outlives any single service. Agent identity is a first-class security principal and needs the same rigor you already apply to workloads and users: lifecycle management, credential rotation, permission reviews, anomaly detection, revocation. The controls that govern service accounts and assumed roles, extended to software that makes decisions. Durable workflows: where agent reasoning has to stop Consider a schedule change that breaks a committed delivery date. | Step | Needs | |---|---| | 1. Investigate the line deviation | Model reasoning | | 2. Read order book and capacity | Model reasoning | | 3. Interpret delivery commitments | Model reasoning | | 4. Propose a revised sequence | Model reasoning | | 5. Request plant manager approval | Durable execution | | 6. Wait for approval (days) | Durable execution | | 7. Publish the plan to the MES | Transaction | | 8. Notify affected customers | Reliable delivery | | 9. Record evidence | Audit | Steps 1 to 4 benefit from model reasoning: ambiguous language, edge cases, policy interpretation. Steps 5 to 9 cannot live inside a model conversation. The context window will be gone. The session will have ended. The approval may take 72 hours. What the protocol now covers, and where it stops Two mechanisms in 2026-07-28 look like answers here. Both deserve precision. requestState solves the protocol-level multi-round problem. The server returns a pending result with the questions it still needs answered, the client re-issues with answers, and any backend instance handles the continuation. This is progress for short-lived elicitation: clarifying ambiguous tool parameters, collecting missing inputs inside a single task. Its guarantee is scoped to one logical call. It has no concept of waiting days for a human decision, compensating a prior step when a later one fails, or producing an auditable record of what was authorized and when. The Tasks extension (io.modelcontextprotocol/tasks , SEP-2663) goes further. Promoted out of the experimental core after production feedback forced a redesign, it lets a server answer tools/call with a task handle. The client then drives tasks/get , tasks/update , and tasks/cancel , and can disconnect and come back later. For a CI run, a video render, or a data import, that is the right mechanism. A durable task ID still does not make the underlying work durable. Tasks gives you a handle plus a small state machine pointing at a result. It does not give you compensation when step 7 fails after step 5 committed, an approval queue with delegation rules, per-step retry policy, or an evidence trail an auditor will accept. Two constraints matter for planning. Task creation is server-directed and requires the client to advertise the extension per request, so an unsupported client falls back to synchronous calls. And tasks/list was removed outright, because listing tasks cannot be scoped safely once the protocol is stateless. Client and SDK support is still filling in. So the division of labor holds. Interpretation belongs to the agent, reliability belongs to a workflow engine. start_schedule_change_workflow(plan_id, affected_orders, reason, evidence) Behind that call, AWS Step Functions, Temporal, or Conductor manages durable state, timeouts, retries, compensation, and auditability. The agent picks the workflow; the engine owns everything after that. The handoff pattern The principle is worth stating plainly: probabilistic systems decide, deterministic systems execute. Evaluate at every boundary HTTP 200 tells you the tool call succeeded. It says nothing about whether the agent acted correctly. Was this the right tool? In the right order? Was the source data current? Was the proposed change within policy? Should the agent have refused? | Layer | Question | |---|---| | Model | Did it understand the task? Did it flag its own uncertainty? | | Retrieval | Were authoritative sources used, deprecated ones excluded? | | Tool selection | Correct tool, valid parameters? | | Execution | Expected operation performed? | | Policy | Action permitted, approval requested where required? | | Outcome | Business result correct, and how much human correction was needed? | Every change to model, prompt, tool description, retrieval index, or policy can shift behavior. The platform needs representative task suites that run on a schedule as well as at release. AWS reference architecture For AWS-heavy organizations, use the existing deterministic services as the backbone: Four things decide whether this holds up. Credentials come from AgentCore Identity. Permission is a separate question, answered by the target service. The policy engine sits at the Gateway, outside agent code. Cedar rules read principal, action, and resource, and every decision lands in an audit log. Temporal policies add the sequence checks: where an argument came from, how old the data is, whether a human signed off. Consequential work runs in Step Functions. The agent picks a workflow. Proceed, wait, retry, compensate: all of that belongs to the engine. The trace is the audit record. It runs from user request through agent session, model decision, authorization check, tool call, workflow, human approval, system change, evidence. And it has a shelf life. Step Functions keeps th