Agentic workflows don't work well with APIs. Web APIs are stateless by nature. A consumer makes a request, the API processes it, and returns a final response. The next request will be totally new. Unfortunately for the consumers, API servers can't remember who they are. Agentic workflows, on the other hand, need to handle a lot of back-and-forth communication between end users and APIs. In many situations, agents need to ask users for approvals or even extra input. The obvious choice is to keep stateful connections with API servers so that information can be exchanged both ways seamlessly. However, this is a rather expensive choice because it's not easy to scale and maintain. How do you keep thousands (or millions) of open stateful connections at a low cost? What's the solution then? Stay with me to learn more.
This article is brought to you with the help of our supporter, n8n.
n8n is the fastest way to plug AI into your own data. Build autonomous, multi-step agents, using any model, including self-hosted. Use over 400 integrations to build powerful AI-native workflows.
The challenge with agentic workflows and stateless APIs is related to the need to handle user input as a response to a request. In the beginning, mid-task inputs relied on persistent connections and long-lived server-sent event (SSE) streams. Even though these looked like good solutions, holding channels open forces platform teams to use sticky sessions, making horizontal scaling extremely difficult. Additionally, serverless functions and edge networks can’t hold socket connections open, which excludes the use of inexpensive cloud solutions. On top of all this, whenever there’s a network connectivity issue, all the active SSE connections will suffer. To the point that any multi-step agentic workflows will fail instantly and lose track of what really happened. On the instrumentation side of things, API gateways can’t inspect or rate-limit any callbacks happening inside open SSE streams. You end up with a whole ungovernable solution because of SSE. Is there an alternative?
MCP SEP-2322 from February 2026 introduces something that “will significantly reduce the cost of operating MCP servers at scale.” This Model Context Protocol Specification Enhancement Proposal is ground-breaking because it changes the way agents communicate with MCP servers. Instead of keeping connections alive, this SEP defines a “multi round-trip request” using something called InputRequiredResult. In practice, this shifts interactive pauses from connection-level callbacks into predictable, stateless HTTP responses. Yes, that’s a breaking change. And that’s probably why it took more than five months to get from a proposal to a version of the MCP specification. It was only in July 2026 that these enhancements finally saw the light.
So, how does InputRequiredResult really work, then? To begin with, every response now carries a required resultType field, explicitly set to either complete or input_required. Let me say that again. Every response now has a required resultType field. Whenever a client receives a response with an input_required resultType, it should ask its user for more information and then retry the request.
The MCP client then gets the missing information from the user and makes another request. The server now has enough information and, if everything goes well, will respond with a complete resultType. This approach decouples the retries, which can happen at different points in time. Now, there’s no need to keep a stateful connection open waiting for the MCP client to gather input from its user. In turn, this allows the protocol to take advantage of API gateways, proxies, and other network elements that already work well with HTTP. The best thing is that you probably don’t need to implement anything by hand yourself. Since the protocol has been updated, it’s safe to expect that SDKs and libraries for supported programming languages will follow along. The only thing you have to do is adapt your own MCP server to use the very latest version of the protocol library. And what about the API that sits behind the MCP server? How do you adapt it to handle multi round-trips well?
One thing is implementing the input-required approach at the MCP server layer. Another thing is making the underlying APIs compatible with this new approach. To fully understand it, let’s see what it really means to say that an input is required. First, it means that somewhere the input parameter must exist. That’s obvious, right? Then, it must be marked in some way as important or even required right from the start. Finally, the MCP server now must treat these inputs dynamically and flag them as required if it really needs them to complete an operation. In practice, at the API implementation layer, that means that all inputs should be treated as optional. Until there’s a situation where they become required. Then, the API should respond with the appropriate HTTP error code, and the MCP should translate it into a multi round-trip. Another drawback to the input-required approach is that not all MCP clients support it yet. What that means is that you’ll probably have to support both scenarios for some time. And that’s an extra cost.
At this point, you’re confronted with at least a couple of options. One option is to keep using SSE. You won’t have to make any changes to your existing MCP servers. This sounds like an interesting choice if you control your environments and all your clients are private. The drawback is that you won’t be able to offer the latest MCP features. And, sooner or later, MCP clients will become incompatible with SSE. The other option you have is to adopt the multi round-trip design. While this choice sounds more expensive now, it gives you a resilient, future-proof foundation. The decision is yours. Look at your current gateway metrics, check how your infrastructure handles long-running calls, and decide if your team is ready to design for an input-required world.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.