When a microservice fails in a cloud-native architecture, circuit breakers trigger, traffic reroutes, and Kubernetes spins up replacement pods within seconds. The system heals before end users even notice a blip.
Imagine deploying an AI agent to run a multi-day master data validation workflow. By day three, it has ingested thousands of records. The baseline governance rules you hardcoded into the system prompt at the start? They are gone. Pushed right out of active memory.
The Model Context Protocol's (MCP)'s largest revision since its initial launch shipped on July 28. By the end of the first day, all four Tier 1 SDKs were already speaking the new version, and Cloudflare's Agents SDK had support in place from day zero, with customers such as Sentry and Linear picking it up right away, meaning the surface this article describes is already live in production. A new 12-month deprecation policy keeps the changes in place through at least mid-2027. Most of the coverage has focused on what improvements have been made: A stateless core that scales on ordinary HTTP, OAuth-native authorization, and server-rendered UIs via MCP Apps.
Enterprise AI has entered a new era. Organizations are rapidly moving beyond assistants that answer questions to autonomous agents capable of reasoning, invoking tools, accessing enterprise applications, coordinating with other agents, and completing multi-step business workflows with minimal human intervention.
There is a clear repeating trend in agent deployments: The gateway is the first control teams reach for, but it is the one they are least ready to run. This is because gateways sit on top of identity and attribution layers that are mostly not there.
Enterprise AI has largely been built around context engineering. Teams connect enterprise systems, generate chunks and embeddings, build retrieval pipelines, and assemble the context needed by individual AI applications. While this approach works well for isolated assistants and copilots, it treats enterprise knowledge as application-specific context rather than a shared enterprise asset.
For much of the past two years, the general belief in enterprise AI has been that more autonomy equals better performance. Build agents that can plan, decide, and act across multi-step workflows, and give them as much room to run as possible. That assumption is now being tested at scale, in real production environments — and in a lot of deployments it's failing. The companies that end up benefiting from agentic AI won't necessarily be the ones that have given their agents the most flexibility. They're the ones who create AI agents with specific responsibilities and make sure they operate within clear rules.
Most teams building retrieval augmented generation (RAG) systems for high stakes classification make the same architectural bet: Route every ambiguous case straight to the language model and trust the retrieved context to sort it out. This works fine in a demo. It falls apart the moment the system has to survive an audit, a regulator, or a compliance officer asking why a specific decision was made six months ago.
There is a step in the development process for large language model (LLM)-assisted tooling that most teams skip because it's tedious, time-consuming, and doesn't produce results visible to end users: Verifying that what the model is saying is actually correct. Not fluent, not coherent, not topically relevant — correct in the sense of accurately identifying the right answer to the specific problem the tool was built to solve.
Enterprises must define AI agents' decision rights to prevent unauthorized actions, as 82% of firms report unknown agents, per a Cloud Security Alliance survey.