An agent running a database migration hits a step that requires someone to approve it. Under MCP's old session model, the server kept a connection open - and your load balancer, your ops team, and your patience all waited with it. The August 22 roadmap update closes that chapter.
The new mechanism is called Multi Round-Trip Requests (MRTR), and it shipped in the 2026-07-28 MCP specification - described by the maintainers as the largest revision of the protocol since launch. The roadmap published last week sets the next direction: mature the Tasks extension, unify transport, and build out agent identity. Together, these push MCP from "a protocol for IDEs talking to tools" toward infrastructure for agents that run for hours and never touch a browser.
This post is about the approval moment specifically - what changed, why the old way was quietly broken, and what teams should do now.
Why the old approval model was a hidden infrastructure tax
The problem was architectural, not cosmetic. Before MCP 2026-07-28, a server that needed something mid-call kept the original request active while the client responded.
Stateless, horizontally scaled deployments could not support this without reintroducing sticky routing, shared coordination state, or long-lived infrastructure that stayed alive while the user responded.
In plain terms: if your agent needed a human to confirm "delete these 3 files?" before proceeding, your server had to sit there holding a connection open - possibly for minutes - waiting for that click. The initialize/initialized handshake and the Mcp-Session-Id header are now gone entirely from the spec.
The practical effect is that any request can land on any server instance - a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer.
That's the scaling headline. But the more interesting change for teams is what replaces the held connection.
What Multi Round-Trip Requests actually do
MRTR is the mechanism that makes human-in-the-loop safe on stateless infrastructure.
Instead of pushing a request down an open stream, the server returns resultType: "input_required" along with the requests it needs answered. The client then retries the original call with the answers attached in inputResponses. The interaction is preserved, but nothing has to stay connected between turns.
The server finishes the HTTP response with "I need input," hands the client an opaque continuation value, and walks away. When the human answers, the client retries. Any healthy server replica can pick up where the first one left off.
Approval becomes two requests instead of one held connection, which is simpler to deploy - but it means the wait for a human no longer sits inside a single invocation. That last clause is the non-obvious consequence: your observability layer needs to correlate two separate HTTP calls to reconstruct a single logical approval event. Teams used to watching a single request duration as a proxy for "time to human approval" will need to instrument differently.
The Tasks extension is the piece teams will actually feel
MRTR handles the approval handshake. But for any workflow that runs longer than a single tool call - a research task, a batch migration, a multi-step deploy - you also need the Tasks extension.
Two official extensions shipped with the 2026-07-28 release. MCP Apps let servers deliver interactive HTML interfaces that hosts render in a sandboxed iframe. Tasks, which graduated from an experimental core feature, provide a stateless model for long-running work: a server can respond to tools/call with a task handle, and the client drives it using tasks/get, tasks/update, and tasks/cancel.
Tasks are now an official MCP extension for long-running work.
The August 22 roadmap identifies maturing the Tasks extension (SEP-2663) toward inclusion in the core specification as the next priority. If your server already runs long jobs - a multi-step research task, a batch job - this is the area to watch for a standardized way to report progress without holding a stream open.
The combination of MRTR and Tasks is what makes a real agentic approval workflow possible end-to-end. Without Tasks, you have a clean approval handshake but no standard way to report what the agent is doing between approvals. Without MRTR, you have task state but no safe way to pause for human input in a scaled deployment.
| Piece | What it solves | Status |
|---|---|---|
| Stateless core | Scale horizontally without a shared session store | Shipped (2026-07-28) |
| Multi Round-Trip Requests | Pause for human input without holding a connection | Shipped (2026-07-28) |
| Tasks extension (SEP-2663) | Long-running work with a state machine and task handles | Official extension, moving toward core |
| Server-initiated events | Webhooks/channels so clients stop polling for results | On August 22 roadmap, not yet shipped |
The gap in that table is the last row.
The work ahead spans server-initiated events - webhooks and channels, so clients aren't left polling for results - and a composition review across the Agents, Transports, and Triggers and Events Working Groups.
Until that lands, a client that wants to know "has the human approved yet?" has to poll tasks/get. It works, but it's the seam in the current design.
Beagle in action#deployments, 2:47pmWhat your team should actually do this week
Nothing in the August 22 roadmap breaks clients on the 2026-07-28 spec today. Progressive discovery, new auth flows, and server-initiated events arrive as future spec revisions or extensions, negotiated per connection as MCP extensions always are.
But the session-based model has a clock on it. Session management complexity tends to be hidden across multiple layers - the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time.
Three concrete steps worth taking now:
- Audit your gateway config for sticky-session routing. If you're load-balancing an MCP server today, check whether your setup assumes sessions. The new spec doesn't need them, but your infrastructure might still enforce them silently.
- Instrument approval latency as two-request spans. MRTR splits what used to be one request into two. Distributed tracing that treats them as one logical unit will give you the human-response-time metric you actually want.
- Read the Tasks extension spec before building your own job-state pattern. MCP is repositioning from "a protocol for IDEs connecting to tools" toward infrastructure for fleets of agents that run for hours, call each other, and never see a browser. Building a bespoke task-state system now means migration work later.
A tool like Beagle, living inside Slack, sits naturally in the MRTR loop - it's the channel where a human's approval already lands, and where the continuation can be triggered without anyone opening a separate UI.
MCP human-in-the-loop agents: common questions
What is Multi Round-Trip Requests in MCP?
Multi Round-Trip Requests (MRTR, SEP-2322) let an MCP server pause mid-tool and ask a human or client for input without holding a network connection open. The server returns input_required with an opaque continuation token, the client collects the answer, and retries the original call. Any server replica can handle the retry - no sticky sessions required.
Does the MCP stateless update break existing servers?
Not immediately. The spec includes a formal deprecation policy with a twelve-month minimum window before old patterns are removed. The session handshake is gone from new connections, but backward compatibility is maintained for the transition period. Teams with custom session-based infrastructure should audit their gateways soon.
What is the MCP Tasks extension?
Tasks, which graduated from an experimental core feature in the 2026-07-28 release, provide a stateless model for long-running work. A server responds to tools/call with a task handle, and the client drives it using tasks/get, tasks/update, and tasks/cancel.
It's the standard way to run multi-step agent jobs without holding an open connection for the whole duration.
When is MCP getting server-initiated events?
Server-initiated events - webhooks and channels so clients stop polling for results - are on the August 22 roadmap, with a composition review across the Agents, Transports, and Triggers and Events Working Groups to ensure they compose cleanly.
No ship date is published yet; the current workaround is polling tasks/get.
How does MCP agent approval work in Slack?
Today, the standard pattern is: agent hits an approval gate, surfaces the MRTR input_required payload to a Slack message, waits for a human reply, then retries the tool call with the continuation token. The Tasks extension gives the job a stable handle so the Slack message can reference it and the right server replica can resume it - regardless of which instance was running when the pause happened.