# How Uber built a software factory for agentic coding: the MCP gateway and the platform underneath > Source: > Published: 2026-08-24 23:31:25+00:00 More than 70% of pull requests at Uber are now written by agents. Code shipped per engineer has doubled in a year, and in twelve months they ran over 250 automated migrations that rewrote 9 million lines of code. Those are the numbers people quote from Uber’s recent talk on their software factory. The short version is that those numbers came from a software factory, and that factory runs on a platform Uber built first. The platform gives agents the pieces they need to work safely across a few thousand engineers: a context graph for organizational knowledge, an MCP gateway for tools, an LLM gateway for models, somewhere to run, and governance over all of it. On top of that platform sit the workflows that turn agentic coding into shipped software, carrying a feature from an idea to a merged PR and keeping it maintained with DevOps automation afterward. The workflows are the visible part, and they only work because the platform underneath them is already there. This piece walks through both layers, using Uber’s own talk as the map. It answers four questions: What is an MCP gateway, and why does agentic coding at scale need one? What did Uber actually build to let AI agents work safely across a few thousand engineers? How do the spec-to-PR workflows and DevOps automation sit on top of that platform? Why does the platform, including the MCP gateway and the LLM gateway, have to come first? The first half covers the platform, one piece at a time. The second half covers the workflows, and where each one reaches back into the platform to do its job. ## Start with the platform, not the agents The platform gives AI agents what they need to work across the software development lifecycle. It does for agents roughly what an operating system does for applications. When you write an app, you do not manage memory or schedule CPU time yourself. The OS handles that, and you get on with the app. Agents need something similar underneath them, to handle context, tools, model access, and safety, so the workflows on top can stay simple. Uber’s platform is made of six pieces. Most of them are infrastructure ideas you would already recognize, applied to agents rather than people. ### Build one context graph instead of querying twenty systems Grab from video · 9:15–9:56— Caption: The context graph. 40 million entries across 150 node and edge types, linking apps, backend, data lake, design docs, Jira, and incidents. (The “cash trips in India” example runs from 9:56.)Alt text:Uber’s context graph slide showing 40 million entries and 150 node and edge types across its engineering systems. Of the six pieces, this is the one worth understanding first. Watching their own traces, Uber saw agents spending time and tokens just finding basic context. Where a service lives, what it depends on, who owns it, what patterns to follow. That information was spread across 20 to 30 systems, and each one needed its own query. The result was added latency and unpredictable answers. Their fix was to pull how the company actually runs into a single graph. It holds 40 million entries across 150 kinds of nodes and edges. It connects how the mobile apps are built, the backend, and the data lake, along with design docs, Jira, incidents, and bugs, all linked together. In other words, instead of the agent playing detective across thirty systems every time to work out what a service is and who owns it, they gave it one accurate, connected map of the company to read. Think of it as a wiki that is always current and fully linked, rather than thirty stale pages you have to stitch together yourself. Uber calls this a context graph. Platforms built for this pattern call the same idea a [context lake](https://www.port.io/platform/context-lake), and most of the other pieces lean on it. Ask their graph “how many mobility trips in India are paid in cash” and it already knows the concepts, the tables, and the entities needed to write the query. When they run the same task with the graph and without it, they see large drops in tokens, turns, and latency. ### Curate skills in a registry, not across random repos Once engineers can write skills for agents, they write a lot of them, and three problems show up fast. The same skill gets built five times by five people. Finding and configuring them is a hassle. And quality is all over the place. In other words, a skill here is a reusable set of instructions that teaches an agent how to do one task, like an internal library or a runbook, except written for an agent. Like any library ecosystem with nobody curating it, it sprawls. To handle that, Uber built a lifecycle around skills. Core and team-specific skills go into one managed registry, now holding 2,500 of them, and everything passes automated lint and review so there is a quality floor. Discovery and installation are simple. One command finds and installs any skill. And based on what an engineer works on, the right defaults get installed automatically, so the agent usually has what it needs without anyone choosing. They also collect usage traces and run continuous evals, then feed the results back to whoever wrote the skill. Across the fleet that comes to more than 20,000 skill runs a day. ### Route every tool through one MCP gateway An MCP gateway is a single, governed entry point that connects AI agents to the tools and APIs they can call. An agent is only useful because of the tools it can reach, and Uber started with thousands of internal APIs, none of them agent-ready, plus a pile of SaaS tools that each log in differently. Wiring these up created a new cost, because every tool an agent can see eats context tokens before it does any real work. In other words, an agent has a limited working memory, and every tool description you hand it fills some of it up. Give it fifty tools and it has read a phone book before you have asked your question. Their MCP gateway handles the setup problem first. An automated crawler turns an internal API into an agent-ready tool with one config change, and SaaS tools like Google, Slack, and Jira go through the same gateway, which hosts them and handles the login handshake. From there they cut the token cost in stages. First they replaced the pile of tools with a single tool that discovers and calls any of the others on demand, so the agent is not carrying all of them at once. Then they had responses come back in a compact form, so the answers stop eating context. Most recently they added a mode where the agent writes small scripts on the fly for the heaviest cases. Together that work cut their token usage by more than 40% across the fleet, with over 1,000 tools now reachable this way. This is the piece a platform team should copy first if agents keep running out of context, because an MCP gateway is where tool sprawl either gets controlled or quietly breaks your agents. ### Send every model call through one LLM gateway An LLM gateway is a single, governed entry point that every model call passes through. If you let thousands of engineers call models directly, you lose control of three things at once. What data leaves your network. How much delay your safety checks add. Who is spending what. The LLM gateway is how Uber keeps hold of all three, and it is the piece that makes the other five behave as a platform, because it is the point where every request is checked and accounted for. Uber routes every model call, internal and external, through a single gateway that speaks the standard model APIs. Behind that one door sits a short chain of checks. Identity and auth come first. Then a step strips more than 20 kinds of PII, so nothing sensitive leaves the network. After that, an “AI guard” of five smaller models handles safety and policy. Their hard rule is that all of this finishes in under 100 milliseconds, so the guardrails never become the reason a request is slow. Every call is also tagged to a project, a user, and a team, so spend and behavior can be traced in real time. In other words, this is the AI agent governance layer. AI agent governance is the set of controls that keep what agents can do, see, and spend inside policy, and here it takes the same shape as the API gateway already sitting in front of your services checking auth and rate limits. Applied to every model call and given a strict latency budget, it means nobody bothers routing around it. Uber’s [governance](https://www.port.io/platform/governance) layer now carries over 100 million model requests a day across 800-plus projects. Without something like it, agents at scale become a compliance and cost problem that tends to surface only once it is expensive. ### Keep environments warm so agents start in seconds Agents need somewhere to run, and their requirements are not the same as a person’s. An agent needs an isolated environment that comes up fast, runs for a long stretch, can be spun up in bulk, and exists at every site. Uber pre-provisions Kubernetes pods they call balloon pods. When an agent needs an environment, it grabs one that is already warm. The repos are snapshotted and the code search index is already built, so it is working within seconds. In other words, instead of building a fresh environment every time an agent wakes up, which means cloning a huge repo and indexing it first, they keep a shelf of ready-to-go machines with the code already loaded. It is like grabbing a rental car that is already fueled with the route set, rather than one you have to prepare yourself. ### Give everyone one assistant across every surface The last piece packages the other five for people to actually use. Their assistant, Cortana, has the context graph, the skills, and the tools plugged into it, and it shows up on Slack, the command line, and the web. Anyone can ask it something, and it will check the context graph, run a skill, and read code in any repo to answer. Teams can also personalize it with their own skills and prompts wired into a team channel, so it works like a member of that team. In one month they saw 300 team-specific versions and more than 20,000 sessions a day. That covers the platform. On its own it does not ship anything. It is the layer the delivery workflows run on, and those workflows are the second half of the talk. ## Then build the factory workflows on top With the platform in place, Uber can string its pieces into workflows that carry a feature from start to finish. Each of the workflows below leans on several of the platform pieces, which is the reason the platform has to exist before any of them. ### Take a feature from spec to prototype in one session Their walkthrough started with an idea kicked around in Slack. Someone tagged the assistant in, and things moved quickly from there. Backed by the context graph, the assistant helped size the opportunity, then moved into a web session for deeper research. From there it generated two mockup variants for an A/B test, and reasoned about which existing screens and backend services the team could reuse. Work that used to take weeks of alignment compressed into a single session and a prototype. None of that runs without the platform. The research came out of the context graph, the mockups and the reasoning about existing code came from skills, and the whole thing ran through the assistant. ### Hand off to an AI coding agent, but stop before CI The prototype went to Minion, one of Uber’s AI coding agents. Agentic coding is software development where an agent takes on a whole task, writing and changing code across a codebase with limited human steering, rather than only suggesting the next line. Minion is Uber’s version of that, and it runs in one of those warm environments so it can change backend and frontend together. One detail is worth calling out. Minion stops at a draft PR and does not push to CI. Uber found that pushing straight to CI was fine for small cleanup work but wasteful for real features, because it hammers shared CI before anyone has confirmed the feature even works. So they validate first. ### Move your checks into the inner loop That validation happens in the inner loop, before CI. In other words, the inner loop is everything that runs on the agent’s own machine before it pushes, and the outer loop is everything that runs after, in shared CI. Uber moved several checks that used to live in CI back into the inner loop: Static analysis, the same lint-style checks as before, just run earlier. Visual validation, where a skill boots a simulator, takes a screenshot, and compares it against the design. Integration checks, which stand up the backend in staging so the front end and back end can be tested together. Every one of those checks is a skill from the registry, running in a warm environment, using the context graph to know what “correct” looks like. The idea is to have the platform do the pre-flight, so shared CI only sees work that is already likely to pass. ### Let CI heal itself and show its work Once the inner loop passes, the change reaches CI. There, self-healing CI fixes many failures on its own. This is DevOps automation aimed at agent-scale output: when agents open far more PRs, the pipeline has to repair routine breakages without a human in the loop. Code review is split the same way, with a smaller, faster model reviewing on the machine and a bigger, slower model doing a deeper review in CI. Because a human is now reviewing a diff an AI coding agent wrote, the PR arrives with a table listing every check it already passed, screenshots included. In other words, instead of asking a reviewer to trust a raw first draft, the PR shows its work, the way you would trust a change more if you could see green checks and a test run attached. The reviewer then spends the time on whether the change is a good idea, rather than on catching basic mistakes. ### Run maintenance as one managed loop More code means more to maintain, so Uber treats maintenance as its own workflow, and it is some of the clearest DevOps automation in the talk. You enroll a service into maintenance skills, like one that cleans up a feature flag and removes the losing variant of an A/B test once it is decided. The important property here is that the loop is managed centrally, which is AI agent governance applied to recurring work. Rather than let thousands of loops run all over the company where nobody can see or stop them, there is one place you go to set a loop up. It runs on Sunday when CI has spare capacity, and it caps how many diffs land on an engineer’s Monday. In other words, instead of every team quietly setting up its own cron job to have an agent change things on a schedule, which is a good way to wake up to chaos nobody can trace, there is one controlled surface for all of it, with limits and a schedule you can reason about. The loop also feeds itself. When those diffs get comments and either land or not, that becomes useful data for improving the skill. And once a month, Uber mines its incident reviews for new maintenance skills to roll out across every service. ## Build the platform first The honest note Uber ended on is about where the constraint sits now. With this much code moving through the factory, the strain shows up in CI capacity, in how many experiments they can realistically run, and in decisions about what to actually build. As one of them put it, the question is no longer whether they can build something. They know they can. It is whether they should. That kind of problem is only available to a team that has already built the platform. Every workflow leans on it: Spec-to-prototype needs the context graph. The validation loops need the skills registry and the warm environments. Every action needs the MCP gateway, and every model call needs the LLM gateway. The maintenance loop needs AI agent governance to stay bounded. Without the platform underneath, the factory is a set of scripts that break the first time a repo moves or a model changes. So if you are planning to let AI coding agents write a real share of your code, the platform is where to start. The workflows are the part you will want to show people, but they sit on top of a context graph, an MCP gateway, an LLM gateway, environments, and a way for people to reach all of it. Uber built that groundwork first, and the numbers everyone is quoting are what it produced. ## Where Port fits Uber built all six pieces in-house, which very few teams have the scale to do, and closing that gap is what Port is for. Port gives you the same foundation without building it from scratch: a [context lake](https://www.port.io/platform/context-lake), an MCP hub, agent and skills management, workflow orchestration, and [governance](https://www.port.io/platform/governance) across the SDLC. On top of that foundation, teams run solutions like [autonomous ticket resolution](https://www.port.io/solutions/autonomous-ticket-resolution), [self-healing incidents](https://www.port.io/solutions/self-healing-incidents), and [engineering intelligence](https://www.port.io/solutions/engineering-intelligence). Companies including GitHub, dLocal, and PwC already use it to move from manual to agentic engineering, and you can read how in their [customer stories](https://www.port.io/customers). ## Frequently asked questions ### What is an MCP gateway? An MCP gateway is a single, governed entry point that connects AI agents to the tools and APIs they can call. It standardizes authentication, hosts internal and third-party tools as MCP servers, and reduces the context tokens each tool consumes. Uber’s MCP gateway made over 1,000 tools reachable and cut token usage by more than 40%. ### What is an LLM gateway? An LLM gateway is a single, governed entry point for every model call an organization makes. It handles authentication, redacts sensitive data, and applies safety checks, then attributes spend to a team, usually within a strict latency budget so it does not slow requests down. Uber’s LLM gateway carries over 100 million model requests a day. ### What is agentic coding? Agentic coding is software development where AI agents take on whole tasks, writing, changing, and validating code across a codebase with limited human steering, rather than only suggesting the next line. It depends on a platform that gives the agent organizational context, tools, and governed model access. ### What is DevOps automation? DevOps automation is the practice of handing repetitive software delivery and operations work to automated systems instead of people, including CI fixes, migrations, and routine cleanup. At Uber it runs at agent scale, covering more than 250 automated migrations and self-healing CI that repairs pipeline failures on its own. ### What is AI agent governance? AI agent governance is the set of controls that keep what AI agents can do, see, and spend inside policy. In practice it includes routing model calls through a governed LLM gateway, attributing every request to a team, redacting sensitive data, and bounding autonomous work so it stays observable. Credit: This writeup is based on a talk given by two Uber engineers, Uday Kiran Medisetty and Adam Huda, who walked through the platform and then the end-to-end feature flow in detail. The numbers, the architecture, and the design calls are all theirs. This blog summarizes what they shared so more teams can learn from it.