In the race to build better AI agents, it is easy to focus on the model: more reasoning, larger context windows, and more tools.

Uber is highlighting another layer that may be just as important: the infrastructure that tells an agent what it needs to know and helps the system reuse what it learns from execution.

The company describes two particularly interesting initiatives inside its Software Factory:

  1. an AI Context Graph connecting knowledge scattered across the organization;
  2. a Continuous Skill Improvement project intended to turn execution traces into automatically generated proposals for improving agent skills.

The first is already operating. The second remains an initiative in development.

Together, they point toward a different architecture for large-scale agentic systems. A powerful model is not enough. Organizations also need a structured way to provide institutional memory and an operational feedback loop that can turn accumulated experience into better procedures.

Information verified on September 29, 2026 from Uber Engineering’s official August 27, 2026 publication.

The problem is not always that the agent reasons poorly

Uber explains that across a massive codebase and a data ecosystem containing thousands of tables, agents spend many of their turns simply trying to locate information.

That changes the nature of the problem.

An agent can use an excellent model and still waste time because it does not know:

  • which service owns a particular responsibility;
  • which repository contains the relevant implementation;
  • which team maintains the system;
  • which historical incidents are related;
  • which pull requests changed the behavior;
  • which architecture document explains the original decision;
  • which dataset or table analysts actually use;
  • which deployment introduced a change.

Without this context, the agent starts exploring.

It opens files, searches documentation, queries tools, launches subagents, and keeps expanding its context window with more results.

Every search can increase latency, request count, and token consumption at the same time.

Uber summarizes the problem bluntly: an ungrounded agent can fail slowly rather than cheaply.

Source: Uber Engineering — Running a Software Factory Efficiently at Uber Scale

AI Context Graph: turning the organization into queryable context

To reduce this exploration, Uber built its AI Context Graph, a network that connects knowledge from more than 30 internal systems.

According to Uber, the graph contains approximately:

  • 24 million nodes;
  • 80 million edges;
  • 86 node types;
  • 117 edge types.

Connected sources include services, engineering teams, incidents, pull requests, architecture documents, deployments, datasets, and historical table-usage queries.

The important difference from simply putting more documents into a prompt is structure.

A graph can represent explicit relationships:

service
  ↓ maintained by
team
  ↓ changed through
pull request
  ↓ related to
incident
  ↓ uses
dataset

That lets an agent query relevant connections instead of reconstructing them from scratch in every session.

In practical terms, it looks less like a giant folder of documents and more like an operational knowledge layer for the organization.

38 seconds versus more than 20 minutes

Uber shared a particularly revealing experiment.

It submitted the identical prompt to the same model under two conditions: with grounding through the Context Graph and without it.

With the graph, the agent queried historical usage, identified the specific table used by more than 50 analysts, and returned the correct answer in 38 seconds.

Without the graph, the agent:

  • spent roughly 20 minutes investigating;
  • inspected service code;
  • spawned two subagents;
  • encountered three errors;
  • and ultimately concluded, incorrectly, that the dataset could not be queried.

The result does not prove that a Context Graph solves every agent problem. It does illustrate a broader principle: the quality of available context can radically change the cost and accuracy of an execution even when the model itself is exactly the same.

From “model + prompt + tools” to structured institutional memory

For the past few years, many agent architectures have been described roughly like this:

model + prompt + tools

At organizational scale, another requirement begins to appear:

model + tools + structured institutional context

The idea is not that the agent “remembers” the company the way a person does.

It is that a persistent layer exists where important relationships have already been modeled and can be retrieved when a task needs them.

That means every new execution does not have to rediscover who owns a service, which dataset is actually used, or which historical decisions explain the current architecture.

In that sense, Context Engineering becomes more than writing a good prompt.

It starts to look like designing the infrastructure that decides what knowledge enters the context, when it enters, and through which relationships.

Uber already operates thousands of agent skills

The second important piece is skills.

Uber says its engineers have built more than 3,600 agent skills across the software development lifecycle and that the platform sees more than 30,000 skill executions per day.

A skill encapsulates a repeatable way of performing a task: instructions, tools, and procedures that let an agent execute a specific workflow.

But a skill written today will inevitably encounter cases its author did not anticipate.

For example:

  • an API changes its response format slightly;
  • an instruction turns out to be ambiguous;
  • a workaround becomes common across executions;
  • a tool sequence creates unnecessary requests;
  • the same failure keeps appearing;
  • users repeatedly correct the same behavior.

Uber calls these small sources of friction papercuts.

In many agent systems, that operational knowledge disappears when the session ends.

Continuous Skill Improvement: turning traces into operational learning

This is where one of the most interesting ideas in Uber’s article appears.

Among its future initiatives, Uber describes Continuous Skill Improvement: the company is working on an automated way to record papercuts from skill executions and auto-generate skill updates from the collected traces.

The distinction matters: Uber presents this as an initiative in progress, not as a fully deployed capability.

The conceptual loop could look like this:

Skill
  ↓
Execution
  ↓
Trace
  ↓
Failure / friction / workaround
  ↓
Improvement proposal
  ↓
New skill version
  ↓
Next execution

That changes the value of an execution.

An execution no longer produces only the requested result. It can also produce operational data about how to improve the procedure that produced the result.

Traces become an asset

Agentic systems generate large amounts of signal:

  • tool choices;
  • execution order;
  • failures;
  • retries;
  • elapsed time;
  • token usage;
  • human corrections;
  • unnecessary paths;
  • decisions that ultimately worked.

If those signals are stored only as logs, they are mostly useful for debugging.

If they are evaluated systematically, they can become feedback for improving the platform.

And if that feedback can be transformed into reviewable skill updates, a form of accumulated operational learning starts to emerge.

This is not retraining the base model.

It is continuously improving the procedural layer around the model.

A possible architecture for agents that improve with use

Putting these pieces together suggests a fairly clear architecture:

Context Graph
      ↓
what the agent needs to know

Skills
      ↓
how the agent should perform the work

Traces + evaluations
      ↓
what happened during execution

Continuous Skill Improvement
      ↓
what should change next time

The model remains important, but it no longer carries all of the system’s intelligence.

Some intelligence lives in structured context, some in skills, and some in the feedback loops.

The moat may not be only the model

Two companies can use exactly the same model and get very different results.

One may give its agents access to thousands of tools and let them explore.

The other may have:

  • a graph connecting internal knowledge;
  • mature skills for repeatable tasks;
  • traces from every execution;
  • automated evaluations;
  • mechanisms for turning recurring failures into improvements.

The model is the same.

The infrastructure around it is not.

That may become one of the most important advantages of the next generation of agentic platforms: every execution can leave the system better prepared for the next one.

Uber does not claim to have fully closed that loop yet. The Context Graph exists and is being integrated into more autonomous agents, while automatic skill improvement from traces remains under development.

But the direction is significant.

We are moving from agents as isolated sessions that execute instructions toward systems with institutional memory and accumulated operational learning.

That looks much closer to a true software factory.

Source