Uber Engineering has offered a detailed look at how AI agents are being integrated into a large company’s internal workflow. According to the company, AI tools now appear across multiple stages of the software development lifecycle, or SDLC. More than 70% of pull requests, or PRs, are attributable to local or cloud-based agents. Employees have also created more than 3,600 agent skills, which are being executed more than 30,000 times a day.
Uber said the role of AI agents inside the company has moved well beyond a developer opening a coding assistant and asking it to write a few lines of code. A growing share of work is no longer initiated directly by humans. Managed agents are taking on those tasks automatically, while human engineers are shifting toward final review and escalation when an agent cannot complete the job. Uber describes that direction as a “Software Factory.”
From developer-led AI use to agents receiving work directly
Uber said the more important shift is the move from an interactive developer workflow to fully managed agents. In the older pattern, AI coding remains centered on the engineer: a developer encounters a problem, opens Claude, GPT, or another coding agent, enters a prompt, and waits for an answer.
Managed agents work differently. If a CI pipeline fails, for example, the process does not have to wait for an engineer to notice the issue, copy the error message, and ask an AI model what happened. An agent can receive the failure event directly, gather the relevant context, analyze the problem, and attempt a fix, then produce a change for human confirmation.
Uber said code review is being folded into the same model. The company has built an AI code review system called uReview to handle pull requests. To check whether the system can actually identify problems, Uber uses PRs tied to real bugs as a benchmark. Those examples are divided into Easy, Medium, and Hard categories, and the company evaluates precision, recall, F1, latency, and error rate. In that setup, AI code review is no longer an occasional question a developer asks a model. It becomes a standing part of the software development process.
One agent does not have to do everything
Uber also said its internal AI workflow is moving away from the idea that one model should handle an entire task on its own. As newer models improve in agent orchestration, the company is seeing more sessions create subagents on their own.
The division of labor resembles a small team. A primary agent interprets the objective, breaks the work into steps, and checks the results. Subagents then carry out clearly defined tasks with narrower inputs and boundaries. Because those tasks are more constrained, Uber said they do not always require the strongest frontier model. The company therefore defaults subagents to weaker, lower-cost models, while the main model handles the more complex reasoning and quality judgment.
That makes the agent setup look less like a single chatbot and more like a manager working with an execution team.
Inside the enterprise, finding information became the first bottleneck
Uber said that once AI agents entered a real company environment, a practical problem emerged quickly: much of the time was not spent writing code, but searching for information. Uber has hundreds of millions of lines of code and thousands of data tables. Relevant details are spread across services, pull requests, incident logs, architecture documents, deployment records, and different datasets.
Without internal context, an agent may keep searching code, calling tools, and creating subagents, yet still end up with the wrong answer. To address that, Uber built an AI Context Graph. The company said this enterprise knowledge network integrates more than 30 internal systems and currently contains about 24 million nodes and 80 million edges. It covers services, engineering teams, incident records, PRs, architecture documents, deployments, datasets, and historical table usage records, and agents can query it in natural language.
Uber described a test using the same model on the same question. An agent with the Context Graph used historical records to locate the correct table, one that had actually been used by more than 50 analysts, and finished the task in 38 seconds. An agent without the Context Graph spent 20 minutes inspecting service code, created two subagents, ran into three errors, and still ended by incorrectly deciding that the dataset could not be queried.
More than 1,000 MCP servers, but not all loaded at once
Knowing where data sits is only part of the problem. Agents also need to know which tools to use. Uber said it already has more than 1,000 MCP servers internally, connecting a large number of internal services and third-party SaaS products.
But loading every tool description into a model from the start creates its own cost. Uber said that when more than 100 tools are installed, preloading tool schemas alone can consume roughly 50,000 to 70,000 tokens. The company changed its approach. Instead of requiring an agent to know every tool in advance, Uber lets the agent use CLI and tool search to find the right tool when needed, then load it dynamically.
Uber compared that design to how a new employee learns a company. Someone joining the firm does not need to memorize every internal system on day one. They need to know where to go when a specific problem comes up.
Agents can write code to operate company tools
Uber said it has also adopted a code mode that allows agents to do more than make one tool call at a time. In this mode, an agent can write a Python script that chains several actions together.
For a data warehouse query, for instance, a conventional agent might submit SQL, wait, check status, wait again, query again, and then collect the result. A model has to stay involved at each step. With code mode, the agent can generate a Python loop that handles waiting and polling on its own, then return only the useful result to the model.
Uber said its tests showed that even running five identical SQL queries in this way cut token use by more than 50%. In larger batch jobs, the savings could exceed 90%. The company has already built more than 25 code-mode skills for the MCP servers used most often, packaging common internal actions into repeatable capabilities for agents.
3,600 skills as executable SOPs
Uber’s inventory of more than 3,600 agent skills sits at the center of this system. In many companies, knowledge lives in documentation, SOPs, or the heads of experienced employees. Uber said the idea behind agent skills is to package “how this kind of work should be done” into capabilities that AI can execute directly.
The company is also preparing what it calls continuous skill improvement. Under that plan, problems encountered while an agent runs a skill, described in the article as “papercuts,” would be recorded automatically. Those execution traces could then be used to generate updates to the skill itself.
From the figures Uber shared, the effort has already moved past isolated experimentation. It is becoming a system that connects company knowledge, tool usage, and software development workflow into an operational agent stack.