What Uber had to build before it could run 1,500 agents in production

At the MCP Dev Summit in April 2026, Uber's Meghana Somasundara opened the company's talk with a line that has been repeated in nearly every recap since: "It takes us humans a lot more effort to break things. But with agents, it's a lot faster, a lot quicker, and the blast radius is a lot higher." Uber now runs 1,500+ monthly active agents that execute 60,000+ tasks per week across the company's 10,000+ internal services. The number that most coverage led with was 1,500. The number that matters is 10,000.

What Uber describes isn't a story about deploying agents. It is a story about the infrastructure that had to exist before the agents could be deployed — specifically, a centralized MCP gateway and registry that the agents talk to instead of talking to the underlying services directly. That gateway is the load-bearing piece. The agents are the cargo.

What Uber actually built

Uber's MCP infrastructure, as described at the summit, has three components:

• A Gateway Orchestrator that converts the company's 10,000+ service endpoints into MCP tools by parsing protobuf and thrift IDL files and using an LLM to generate tool descriptions. Service owners stay in control; the gateway does the manual integration work that would otherwise be paid for by every individual team building an MCP integration.
• A Gateway Service that serves the MCP definitions to consumers and manages updates through version-controlled pull requests.
• A Central Registry that acts as the single source of truth for tool discovery, with version tracking and conformance metadata attached.

Layered onto those three components: authorization services applied at the gateway, PII redaction on responses, periodic code scanning of registered MCPs, and a hard block on mutable endpoints that could damage critical services. The two-tier trust model treats internal MCP servers as standard-vetted and third-party servers as requiring "significantly more rigorous security scrutiny" — Uber's words, not a paraphrase.

Notice what is not in this picture: the agents themselves. The agents are the consumers of the gateway, not the source of the gateway's guarantees. A researcher pointing at the Uber stack and saying "look, 1,500 agents in production" is pointing at the outputs of the system, not its design.

Why this is the shape of the answer, not a one-off

Three of Uber's stated problems read like a generic enterprise's MCP adoption diary. From the AAIF summary of their talk:

1. Teams independently built custom MCP integrations with no reusability, creating technical debt.
2. Without visibility into call patterns and data access, unauthorized access posed significant risks.
3. Engineers lacked assurance that discovered tools were reliable, performant, and safe.

The first is a standards problem. The second is an observability problem. The third is a conformance problem. None of them is solved by adopting MCP the protocol; all of them are solved by adopting MCP plus a registry that mediates between agents and services and plus governance applied at that mediation point. The protocol is necessary; it is not sufficient.

Somasundara's blast-radius quote is the practical case for why mediation matters. A human accidentally querying a wrong table touches one row. An agent that learned to use that table tool through an MCP registration, and that runs in a loop with retries, can touch the table thousands of times before anyone notices. The MCP gateway doesn't prevent the agent from making a mistake. It bounds the consequences of the mistake by enforcing auth, redaction, and write-path policy at a single chokepoint.

The MCP authorization spec formalized OAuth 2.1 + PKCE for client→server flows in March 2025, and it remains optional. Uber's deployment shows what enterprises actually do with that: they make it non-optional, they enforce it at a gateway they control, and they layer in PII handling and write blocking that the spec does not specify because the spec cannot specify them — those are deployment-specific policies, not protocol-level features.

The registry layer is where this lives

The interesting comparison is between Uber's MCP Central Registry and AAIF's hosted MCP Registry, the foundation's public discovery layer for MCP servers. Both are called "registries"; they are not doing the same job. The AAIF registry publishes servers' self-declared metadata. The Uber registry attaches conformance data, version policy, scan results, and authorization configuration to each registered server, and refuses to expose servers that have not cleared the bar.

Drawn as a diagram, the difference is the policy layer:

This is not a criticism of the AAIF registry. A public discovery directory shouldn't impose deployment-specific policy on third-party servers; that is the job of the operator that consumes them. The observation is that the gap between "publish-and-discover" and "production-ready" is filled by infrastructure that every serious deployment has had to rebuild independently. That gap is the registry-of-registries layer the agent web has not yet standardized.

The work Uber describes is a well-defined set of operations: converting IDLs to tools, scanning for safety, attaching auth, tiering trust. It recurs in every large MCP deployment. It is the most obvious candidate for the next foundation-governed primitive after MCP itself: a conformance profile that says "this server, when probed, behaves the way this scan report describes, and these are the policies a consumer should apply to mediate it."

Agenstry's registry operates one step removed from that — we probe what is published and we publish the probe. Uber's stack is the consumer-side mirror of that probe: they don't just want to know what an MCP server claims; they want to know what their gateway has verified about it before any agent in the building is allowed to call it. Both halves of that workflow are the same shape. One runs at the public registry. The other runs at the enterprise gateway. The protocol is the same. The policy is not.

What we're watching

Three things, observable in the next two quarters:

1. Whether the AAIF MCP Registry roadmap absorbs a conformance-profile schema that gateways like Uber's can consume directly, instead of every enterprise reimplementing the scanning and tiering work. If the registry stays publication-only, the gateway pattern will fragment by vendor.
2. Whether the MCP authorization spec moves from optional to required for new server registrations. Uber's deployment treats it as required; the spec does not. The gap is what distinguishes a hosted directory from a production-ready one.
3. Whether the next disclosure of a production MCP failure attributes it to a missing gateway, a missing scan, or a missing auth boundary. The blast-radius quote is the easy version of this argument. The hard version is a concrete post-mortem. Uber has now shipped the framing; the next field report will probably ship the case study.

The 1,500-agent number is the headline. What is actually being built is the gateway between those agents and the rest of the company. Most coverage will reverse the figure-ground. Read it the other way around.

Sources

• MCP Is Now Enterprise Infrastructure: Everything That Happened at MCP Dev Summit North America 2026 — Agentic AI Foundation, April 13, 2026.
• Uber Shares What Happens When 1,500 AI Agents Hit Production — ShiftMag, May 4, 2026.
• Scaling Model Context Protocol (MCP) Infrastructure for Enterprise Agentic AI — ZenML LLMOps Database, 2026.
• Authorization — Model Context Protocol — MCP Specification, accessed May 2026.
• MCP Registry — modelcontextprotocol/registry — Model Context Protocol, accessed May 2026.