Inquiries seeking to "query core systems directly from AI" have surged noticeably over the past six months. At the same time, projects stalled due to an inability to make a call have also increased. The underlying reason is almost always the same: the specifications appear to still be shifting.
The fear is that standards will change after you build, forcing a rewrite. On the other hand, if you wait and see for more than a year, you end up giving up on any operational improvements during that time.
The new MCP roadmap published in August 2026 can directly guide this decision, because it clearly separates what is set to change from what is not planned to change.
What was announced
The Agentic AI Foundation (AAIF), which oversees the specification of the Model Context Protocol (MCP) under the Linux Foundation, has released a roadmap outlining its future direction. Media coverage summarizes it across five key focus areas.
| Area | Details |
|---|---|
| Transport evolution | Next-generation Streamable HTTP; stateless operation across multiple instances and deployment behind load balancers |
| Server discovery | Automatic discovery of MCP servers through Server Cards standardization |
| Inter-agent collaboration | Enhanced asynchronous task processing (Tasks) |
| Enterprise readiness | Audit trails, advanced authentication/authorization, and standardization of gateways and proxies |
| Governance maturity | Establishing a specification development process via open working groups |
As background, MCP was transferred to the Linux Foundation in December 2025, so the governance of standardization itself is no longer in the hands of a single vendor. This roadmap represents the first medium-term plan under this structure.
What will change is the connection layer, not the business logic
When read from the perspective of implementation and procurement decisions, the five areas divide neatly into two groups.
What is changing is the outer layer: transport, server discovery, gateways, and authentication handoffs. All of these are about "how to connect."
What is not changing is the inner layer: which business data to expose, at what granularity, and to whom. This is not included in any item on the roadmap, because it is not for a specification to decide, but for each company to determine.
This distinction is the essence of deciding when to start. In fact, most of the workload in adopting MCP lies in the inner layer. It is the work of scoping out what units can be handed off to agents from existing APIs and databases, setting permission boundaries, and deciding the granularity of returned information. When redesigning existing APIs as MCP servers, what takes time is this design work, not the implementation of converters.
Advancing the inner layer while the outer layer is still shifting will not go to waste.
Statelessness is already here
Another major practical shift has arrived ahead of schedule. In the late July 2026 specification revision, HTTP transport was reorganized toward stateless operations. Around the same time, the Enterprise-Managed Authorization extension, which centrally manages authorization for enterprise environments, also reached stability.
What changes is the operational baseline. When there is no need to maintain state per connection, MCP servers can be placed behind load balancers just like ordinary web applications. Redundancy and scaling can be handled as straightforward extensions of existing operational procedures.
This means you can avoid the setup of "standing up one special server for AI agents and managing it in isolation." When integrating into internal systems, this is a huge advantage. Components that require special treatment usually stop being maintained a few years down the line.
Drawing the line for decisions
Based on the above, whether to proceed generally breaks down as follows.
What you can move forward with right away
- Designing which business data to expose to agents and in what units
- Defining permission boundaries (mapping who the action executes on behalf of to business roles)
- Deciding what to record in audit logs
What you do not need to rush
- Architectures that assume automatic server discovery (Server Cards standardization is still ahead)
- Designs that assume asynchronous multi-agent orchestration (enhancements to Tasks are still ahead)
In other words, you can design right now up to the point of exposing a single business system as a single MCP server. You can afford to wait a little longer before tackling architectures where multiple agents collaborate autonomously.
In real-world consultations, it is the former that is delivering real results. Setups focused on one system for one purpose—such as "querying inventory status in natural language" or "searching across quotation histories"—are operating reliably.
Starting with read-only makes subsequent decisions easier
Safety is not the only reason to start read-only: actual usage often diverges from initial expectations.
Discrepancies happen all the time—the team thought users would want to "check inventory allocation," but in practice, users mostly wanted to "find the same product number as last month." This kind of insight never surfaces on the drawing board.
What you should capture during the read-only phase is the log of which queries were most frequent. With this data, you can decide on actual evidence "which operations to allow under whose permissions" when adding write capabilities. Without those logs, designing write operations will once again rely purely on guesswork.
This is also why deciding early what to log in audit records matters: they serve not only for compliance audits, but also as input for deciding what to build next.
What to do next
First, narrow it down to a single business system you want agents to interact with. Looking at several simultaneously will inevitably lead to debates on overall system orchestration, which is an area that has yet to solidify on the roadmap.
Next, list the read-only operations to permit on that system. Deciding whether to incorporate write actions can easily wait until read operations are running reliably. Once this list is in place, even if specification details change down the road, only the connection layer will need to be reworked.
At GleamHub, our development, AI, and automation consulting covers connecting internal systems to AI agents, designing and implementing MCP servers, and architecting permission boundaries and audit logs. Feasible approaches depend on your existing system architecture, so please reach out for an individual consultation via Contact Us.
Sources
- New MCP roadmap released, focusing ahead on AI agent support, unification to HTTP communication, identity, and improved developer experience — Publickey
- MCP announces latest roadmap, defining five focus areas including agentic AI, asynchronous communication, and security — @IT
- New MCP roadmap unveiled, prioritizing AI agent support and unification to HTTP communication going forward — ITmedia NEWS
