MCP Went Stateless. Build Your AI Product Around Tool Contracts.
The most important AI infrastructure release last week was not a smarter model.
It was a protocol deciding to forget.
On July 28, the Model Context Protocol published its new 2026-07-28 specification. The headline change: MCP moved from a stateful, session-based design to a stateless request-and-response core.
That sounds like plumbing. For founders, it is a product lesson.
Your AI product becomes more durable when each action is explicit, each piece of state is visible, and no critical workflow depends on one model remembering what happened three steps ago.
What “stateless” actually changes
Earlier versions of MCP used an initialization handshake and a session identifier. A client and server established a relationship, then carried that session through later requests.
The new specification removes that protocol-level session. Each request carries its own protocol version, client identity, and capabilities. A request can reach any compatible server instance behind a standard load balancer without relying on shared session storage.
The protocol also adds an optional server/discover call. A client can ask what a server supports before acting, or make a request directly and handle a version mismatch if one appears.
This does not mean an AI product cannot remember anything. It means memory should not be hidden inside the transport layer.
If a workflow needs continuity, the server can create an explicit handle and pass it back as a normal tool argument. The model can see that handle and use it in the next step.
That distinction matters. Hidden state is convenient until it disappears. Explicit state can be inspected, tested, logged, and recovered.
Your moat is the contract, not the conversation
Many first-time AI founders start with a chat interface. The demo feels alive because the model appears to understand the user and carry context forward.
But the conversation is not the product.
The product is the set of reliable commitments underneath it:
- What actions can the system take?
- What inputs does each action require?
- What result does it return?
- Which actions need approval?
- What happens when a task takes longer than one request?
- What should the user see when a dependency fails?
Those are tool contracts.
A claims expert might define tools for extracting policy clauses, checking coverage criteria, flagging missing evidence, and drafting a review summary. A logistics operator might define tools for comparing routes, checking inventory, estimating delay risk, and escalating exceptions.
The model can change. The interface can change. The workflow contracts preserve the domain logic.
This is where experienced professionals have an advantage. You already know which decisions are reversible, which fields cannot be guessed, and which exceptions require a human. That knowledge belongs in the product architecture, not only in a prompt.
Design long workflows as visible state machines
The new MCP specification also formalizes patterns for multi-step work.
When a tool needs more information, it can return an input_required result. The client gathers the missing answer, then retries the original request with that response attached. For longer-running work, Tasks now live in an official extension with polling and update methods.
You do not need to implement MCP yourself to borrow the design pattern.
Map your core workflow as a small state machine:
- Requested — the user has stated an outcome.
- Validated — required inputs are present and acceptable.
- Approved — the user has confirmed a consequential action.
- Running — the system is doing the work.
- Completed or escalated — the result is delivered or handed to a person.
Then ask what evidence moves the workflow from one state to the next.
For example, an AI procurement assistant should not move from “validated” to “approved” because the model sounded confident. It should move because an authorized person approved a specific vendor, price, and scope.
Visible states make the product easier to explain to customers. They also make failures easier to diagnose. You can tell whether the model misunderstood the request, a tool returned bad data, an approval was missing, or a downstream system failed.
Build for compatibility before you build for scale
The new MCP release includes breaking changes, but it also defines modern, legacy, and dual-era compatibility. Servers can support both the new stateless revision and earlier session-based clients. The TypeScript SDK documentation makes the upgrade an explicit opt-in rather than silently changing existing behavior.
That is another useful founder lesson: migration behavior is part of the product.
Before choosing an agent platform or no-code builder, ask:
- Can I export my prompts, schemas, and workflow definitions?
- Can I call the same tools from a different model or interface?
- Is state stored in my database or trapped in a platform session?
- Can I version tool inputs and outputs?
- Can old clients keep working while I upgrade the backend?
- Can I test the workflow without a live user conversation?
You do not need enterprise-scale infrastructure on day one. You do need a path that does not force a rewrite every time the AI layer changes.
Start with one painful workflow. Define the actions. Make state explicit. Add approvals where judgment matters. Test the failure paths. Then place the best available model on top.
That is how domain expertise becomes a product rather than a clever demo.
If you want help turning what you already know into a structured AI product you can build and launch, book a strategy call with AI Product Accelerator. We will help you choose the right workflow, validate it before overbuilding, and turn it into a 12-week execution plan.