Managed Skills and Their Improvement Lifecycle

The platform needs more than tools. It also needs reusable ways to perform work.

Uber describes this layer as managed skills. A skill encodes a procedure for an agent. An MCP tool, by contrast, exposes an operation that the agent can invoke. A tool answers what can be done. A skill gives guidance about how several operations should be organized to complete a task.

The difference matters because a large tool catalog does not automatically produce a reliable workflow. The organization must also make useful procedures easy to find, safe to distribute, and capable of improving from evidence.

From individual scripts to a managed catalog

Imagine that several engineers need the same kind of agent procedure. Each engineer builds a slightly different version. Later, other engineers cannot tell which version is trustworthy, how to configure it, or whether an existing version already solves their problem.

Teaching example: A service-maintenance task might require finding a service owner, checking the service's current dependency, proposing a safe update, and validating the result. If every team creates that sequence independently, effort is duplicated and quality becomes difficult to compare.

The speakers describe a marketplace of about 2,500 skills. The marketplace is an organizational answer to duplication and discovery. It provides a place where skills can be listed and distributed, while core and domain ownership provide stewardship for different kinds of skills. The source does not claim that listing a skill makes it correct. A catalog is useful only when people can discover a skill and someone remains responsible for its quality.

This is the first important mental model:

A skill marketplace is not just a download page. It is a managed supply chain for agent procedures.

Tool versus skill

The distinction can be made concrete with one task:

Identify the owner of a service and safely update that service's dependency.

A tool might provide one operation to search ownership data. Another tool might read a repository file. A third might open a change or run a check. Those tools are capabilities.

A skill can arrange them into a procedure:

1. Locate the service and its owning team.
2. Inspect the dependency declaration and the repository's rules.
3. Choose an allowed update path.
4. Make the change.
5. Run the relevant checks and report what happened.

This sequence is a teaching example, not a claim that the talk specifies this exact dependency workflow. Its purpose is to show why the two concepts are complementary. MCP makes operations available. A skill makes a repeatable task understandable to the agent.

The managed skill lifecycle

The chapter presents skills as something that moves through a lifecycle rather than something that is written once and forgotten:

flowchart LR
    A[Core or domain skill] --> B[Quality gates]
    B --> C[Managed marketplace]
    C --> D[Command or persona distribution]
    D --> E[Agent executions]
    E --> F[Traces and comments]
    F --> G[Continuous evaluations]
    G --> H[Skill patch]
    H --> B

Each stage answers a different question.

1. Ownership: who maintains it?

Skills may be owned centrally as core capabilities or by a domain team that understands a particular area. Ownership creates a path for maintenance. Without it, a skill can remain available even after the systems, conventions, or assumptions around it change.

2. Quality gates: is it ready to distribute?

The talk's quality-gate visual shows lint, evaluation, and model gates before catalog distribution.

• A lint gate can catch structural problems in the skill package or its instructions.
• An evaluation gate tests behavior against defined cases.
• A model gate can check how the skill performs when used by a model.

These gates check different failure modes. Passing a structural check does not prove that the procedure works on real tasks. Passing a few evaluations does not prove that every repository or domain case is covered. The point of multiple gates is to collect several kinds of evidence before broader use.

The talk's quality-gate diagram, shown at about 07:46, places lint, evaluation, and model checks before distribution.

3. Marketplace distribution: how does it reach users?

After the quality stage, a skill can enter the managed marketplace. The speakers describe command- or persona-based distribution.

These are separate lifecycle concerns:

Stage	Question	Possible failure
Publishing	Has the skill been accepted into the managed catalog?	It never becomes available.
Installing or enabling	Has it been made available to a target environment?	It is cataloged but absent where needed.
Selecting or invoking	Did the agent or user choose it for this task?	The wrong procedure is used, or the skill is not discovered.

This separation is useful for debugging. If an agent does not use a skill, the problem might be quality, distribution, or discovery. Treating all three as “the skill failed” hides the real bottleneck.

4. Execution: does it work in practice?

The speakers report more than 20,000 skill executions per day. That scale changes the operational question. A skill is no longer an isolated prompt owned by one person. Its behavior produces a stream of real execution evidence across agent harnesses.

High execution volume is evidence of usage. It is not, by itself, evidence of correctness or business value. A frequently used skill can still be confusing, outdated, or wrong in an important edge case.

5. Feedback and improvement: what should change?

The source identifies traces, comments, and continuous evaluations as feedback signals. The feedback-loop visual shows signals flowing toward evaluations and skill patches.

• A trace records what the agent did during an execution.
• A comment records a human response to the result or change.
• A continuous evaluation repeatedly checks the skill against known cases as the skill or its environment changes.
• A skill patch updates the maintained procedure in response to the evidence.

The loop becomes valuable only when evidence changes the skill or its evaluation set. Collecting traces without reviewing them creates observability, but not learning. Collecting comments without turning recurring problems into fixes creates a queue, but not improvement.

The talk's feedback-loop diagram, shown at about 08:17, connects traces and comments with evaluations and skill patches.

A complete example

Consider a domain team that creates a skill for a recurring service change.

1. The team owns the procedure because it understands the domain rules.
2. The skill passes lint, evaluation, and model gates.
3. It is published to the marketplace.
4. A command or persona makes it available to an agent harness.
5. Agents execute it on real work.
6. Traces reveal where agents take an unnecessary step, and comments identify a repeated review problem.
7. Continuous evaluations reproduce the problem as a test case.
8. The owner patches the skill and sends it through the quality gates again.

The exact example above is teaching context. The source-supported point is the lifecycle: ownership, managed distribution, quality checks, execution evidence, and feedback-driven patches form one system.

The key caution: available does not mean correct

Automatic availability can make a skill easy to use. It cannot guarantee that the skill is suitable for every task. A managed system therefore needs both:

• Discovery and distribution, so agents can access the right procedure.
• Quality and feedback, so procedures remain useful after they encounter real work.

This is why catalog scale increases the importance of ownership and evaluation. At a few skills, people may rely on personal knowledge. At roughly 2,500 skills, reliable selection and maintenance must be designed into the platform.

In the broader agentic SDLC, managed skills are the reusable procedure layer. They connect platform capabilities to repeatable engineering work, then use execution evidence to improve that connection over time.

Source notes

• Chapter coverage: approximately 07:12–08:40 in Agentic SDLC at Uber.
• The reported marketplace size and daily execution count are claims made by the speakers. They are usage and scale figures, not independent quality measurements.