The Multiplayer Software Factory: What Uber and Slack's Agentic Coding Bets Reveal About Where Enterprise Dev Platforms Are Heading

Uber's engineering organisation has disclosed that agents now generate more than 70% of its pull requests. Slack is building infrastructure to make agent-authored work visible across entire teams, not just to the individual developer who triggered it. These are not pilot programme metrics. They are production signals from organisations that have already crossed a threshold that most enterprises are still treating as a future consideration. The argument here is that the bottleneck in agentic development is no longer what agents can do. It is whether the platform around them can handle what happens when dozens of agents are working simultaneously, across the same codebase, under different team mandates, without a coordination layer that keeps the whole thing coherent.

The Infrastructure Gap That Productivity Framing Misses

Most CTOs encountering agentic coding for the first time frame it as a developer productivity question. The framing is understandable, because the early evidence looks like productivity: faster pull requests, shorter iteration cycles, less time on boilerplate. But productivity framing leads to a specific kind of infrastructure mistake.

When agents are treated as faster developers, the natural instinct is to give them the same tools developers use and measure them the same way. The problem is that agents do not behave like developers at scale. A developer working on a feature will pause, check Slack, read a comment, and adjust. An agent will continue executing its task graph until it hits an error or completes. At 70% of pull request volume, the coordination problem is not human-scale anymore.

The infrastructure gap that opens up is not in the agent itself. It is in everything the agent touches: the context it retrieves, the decisions it cannot make without human input, the changes it makes that other agents do not know about, and the audit trail that compliance teams will eventually ask for.

MCP Gateways as the New Platform Primitive

The Model Context Protocol is emerging as the architectural layer that makes multi-agent development manageable at enterprise scale. Rather than each agent maintaining its own tool integrations and context retrieval pipelines, an MCP gateway centralises those connections and enforces consistent access patterns across every agent operating in the environment.

Why Centralised Context Control Matters

The case for a gateway architecture is not primarily about efficiency. It is about consistency. When two agents are working on adjacent parts of the same service, and both are retrieving repository context independently, they can develop divergent understandings of the codebase state. The gateway becomes the single source of truth for what the codebase looks like at any given moment, which is a prerequisite for agents that need to coordinate without constant human mediation.

We have written separately about why repository context is frequently the silent failure point in enterprise AI coding deployments. The indexing architecture and retrieval strategy that works for a single developer-facing assistant does not hold when agents are making concurrent writes and the context window needs to reflect live state rather than a snapshot.

Companion piece to our broader work on production AI coding infrastructure. See Repository Context: The AI Coding Stack Bottleneck for a detailed treatment of indexing trade-offs and retrieval architecture decisions at enterprise scale.

Governance as a First-Class Gateway Concern

An MCP gateway that only handles tool routing is incomplete. The governance layer needs to sit inside the gateway, not downstream of it. This means rate limiting by agent identity, scope restrictions tied to team boundaries, and logging that captures not just what the agent did but what context it was operating with when it made a decision.

Without this, the audit trail becomes reconstructed rather than native. Reconstructed audit trails are a compliance liability because they depend on inference rather than observation.

Team Visibility as a Coordination Mechanism

Slack's investment in making agent work visible across teams reflects a specific insight: the coordination problem in multi-agent development is not primarily technical. It is social. When an agent commits a change that affects a shared library, the people who need to know about that change are not always the person who triggered the agent.

Team-visible agent workflows solve this by treating agent activity as a first-class event stream in the same channels and surfaces where human engineering work is discussed. The effect is that the team's shared mental model of the codebase stays current even when most of the changes are not coming from humans.

The design implication for platform teams is that agent observability cannot be bolted on after the fact. It needs to be designed into the workflow at the point where the agent receives its task, so that the visibility artefacts are generated as a byproduct of execution rather than as a separate reporting step.

Governance Layers and the Coordination Debt Problem

Coordination debt is the enterprise-scale version of technical debt. It accumulates when agents make decisions that are locally correct but globally inconsistent, and no mechanism exists to surface those inconsistencies before they compound. At low agent volume, this is manageable. At Uber's reported volumes, it becomes a delivery risk.

Policy-as-Code for Agent Behaviour

The most durable approach to governance in multi-agent environments is treating agent behaviour policies the same way infrastructure teams treat infrastructure configuration: as versioned, reviewable code that lives in the repository and is enforced at runtime. This means defining what an agent is permitted to do in a given context, what requires human approval, and what is blocked outright, in a form that can be audited, tested, and rolled back.

Policy-as-code for agents is not yet a standard practice, but the organisations building at Uber's scale are converging on it because the alternative is governance by convention. Governance by convention breaks down precisely when the system is under pressure and agents are moving fast.

Human-in-the-Loop Design That Does Not Create Bottlenecks

The instinct to add human approval gates to agent workflows is correct in principle but frequently implemented in ways that recreate the bottlenecks agents were supposed to eliminate. The design principle that works in practice is asymmetric approval: agents operate autonomously within defined policy bounds, and human review is triggered by policy exception rather than by default.

This requires that the policy bounds are well-specified upfront, which is itself a significant design investment. Organisations that skip this step tend to find that their human-in-the-loop gates become the rate-limiting constraint on the entire system.

What Engineering Leaders Need to Build Now

The organisations that will avoid coordination debt are not necessarily the ones with the most capable agents. They are the ones that have built the platform layer before the agent volume arrives, rather than retrofitting governance onto a system that was already moving.

The practical sequence is: establish MCP gateway architecture with governance built in, define policy-as-code standards for agent scope and approval triggers, instrument agent workflows so that team visibility is native rather than added, and treat repository context as a live infrastructure concern rather than a static configuration. None of these are agent capability problems. They are platform engineering problems that require platform engineering investment.

The competitive gap that is opening between organisations like Uber and the median enterprise is not in the agents they are using. Both groups have access to the same foundation models and the same coding tools. The gap is in the surrounding infrastructure that determines whether those agents can operate at volume without creating more coordination overhead than they eliminate.