A managed lifecycle for reusable agent skills

By the end of this chapter, you should be able to describe the lifecycle of a reusable agent skill from authoring and quality checks through discovery, execution, evaluation, and improvement. You should also be able to explain why the speakers need a marketplace at the scale they describe.

The speakers present skills as the fourth building block in Uber's managed software factory. A skill is a reusable agent capability or workflow that engineers can discover, install, and execute. It is a unit of reusable behavior, not a model or a place where code runs.

The earlier blocks supply the pieces a skill may use. The model gateway manages model requests. An MCP is the tool-integration mechanism used in the talk, and the MCP gateway organizes access to those tools. An agent environment supplies a workspace in which the agent can operate. Their roles are different:

Layer	Role in the lifecycle
Model gateway	Provides managed access to model reasoning or generation.
MCP gateway	Organizes access to APIs and other tools.
Agent environment	Provides the workspace and runtime in which an agent can work.
Skill	Packages a reusable capability or workflow for discovery, installation, and execution.
Skills marketplace	Collects, distributes, and gathers feedback about those skills.

The skill is the reusable unit. The skills marketplace is the managed catalog and lifecycle around many such units.

Why a marketplace is needed

When a capability is useful, several teams may independently build versions of it. Without a shared catalog, engineers may recreate work they cannot find. Similar skills may go through different checks. Authors may have no common way to learn how a published skill behaves in practice.

A marketplace addresses those problems together. It gives skills a common path for authoring, quality checks, discovery, installation, execution, and evaluation. The speakers do not describe it as an unreviewed list of prompts. They describe a managed system for reusable capabilities.

The speakers distinguish between core skills and domain-specific skills. A core skill is intended to be useful across many domains. A domain-specific skill serves a narrower area of work. Both categories can enter the same marketplace even though their audiences differ.

They report about 2,500 skills and more than 20,000 daily executions. These numbers indicate the reported size of the catalog and the amount of use. They do not establish skill quality or successful outcomes. The source gives no definitions, baselines, or measurement methods for the counts.

Click to enlarge

The diagram shows teams building skills, a shared quality gate checking them, a centralized skill catalog collecting them, and defaults distributing them to users or teams. It supports the marketplace flow described here; the source does not define a skill's contents or interface in this slide. Source visual at 08:00

The skill lifecycle

The marketplace is useful because it connects a release path with a return path. A skill does not stop changing when it is published.

1. Teams author a reusable skill

Teams create core or domain-specific skills for capabilities they want to reuse. Authoring turns a repeated way of working into an agent-accessible unit.

The source does not specify a skill's file format, interface, or internal contents. Here, “skill” should therefore be understood at the capability level rather than as one particular implementation. At the moment of creation, it is only a candidate for shared use. It is not yet established as trusted or easy to find.

2. Quality gates establish a baseline

Before publication, the speakers say a skill passes a lint check and an automated review. A lint check is an automated check used here as one gate for baseline skill quality. The automated review is another machine-run check before distribution.

These gates matter because a marketplace makes a skill visible to more people. Discovery without checks could spread a weak or broken artifact more efficiently. The speakers do not define the lint rules, the automated-review procedure, or the evaluation criteria. The supported claim is narrower: lint and automated review are part of the described publication gate.

Passing the gate does not prove that a skill will work in every context. It creates a baseline for publication. Later execution evidence can still show that the skill needs changes.

3. The marketplace publishes and organizes the skill

Skills that pass the described checks enter the skills marketplace, the shared catalog for core and domain-specific skills. Publication gives engineers one place to find and distribute reusable capabilities instead of relying on private knowledge inside another team.

The catalog therefore solves a discovery problem as well as a storage problem. Easier discovery makes reuse more likely and reduces avoidable duplication.

4. Engineers discover or receive the skill

An engineer can discover a skill in the catalog and install it. Some skills can also become team defaults and be autoinstalled. Autoinstallation means that the system installs the skill without requiring every intended user to perform the setup manually.

This is scoped distribution, not universal distribution. A default for one team or persona does not mean that every skill is installed for every engineer. It also does not bypass the quality gates that came before publication.

5. The skill executes through the surrounding platform

After installation, the skill runs as part of an agent task. It may use the model access, tools, and runtime supplied by the earlier platform layers. This is why a skill is not interchangeable with a model, an MCP, or an agent environment. The skill describes a reusable capability or workflow; those layers supply parts of what the workflow needs to run.

The later context graph chapter adds another connection. A context graph is a connected representation of software and organizational information that an agent can query. It can supply context to a skill, but it is not the skills marketplace. The same feedback idea also continues into later maintenance workflows.

An execution creates evidence. An execution trace is a record of what happened during a skill run. The speakers also mention comments and other feedback as inputs to improvement. An execution count shows that a skill was used. It does not show that the run was correct.

6. Continuous evaluation sends evidence back to authors

Continuous eval means evaluating a skill's behavior over time with collected traces and feedback. Authors can use that evidence to find weaknesses and make changes instead of treating publication as the end of the process.

An updated skill can pass through the quality checks again and return to the marketplace. The resulting loop is:

author → lint and automated review → publish → discover or autoinstall
       → execute → collect traces and feedback → continuous eval
       → improve → check and publish again

The return path changes the marketplace from a static catalog into an improvement process. Distribution gets the skill to users. Execution and evaluation give its authors evidence for the next version.

Teacher-created walkthrough

Teacher-created example, not a scenario reported by the speakers: Suppose two teams independently create skills for the same recurring internal workflow.

Without a marketplace, an engineer on a third team may not know that either skill exists. The teams may repeat work, and their versions may be checked differently. With the managed lifecycle, the candidate skills can enter a shared catalog, pass common checks, and become discoverable. A team can install the suitable version or receive it through its defaults. Later runs produce traces and comments, and continuous eval gives the authors evidence for a revision.

This example shows why the marketplace matters at scale. Its role is not merely to store more skills. It coordinates reuse, distribution, and learning among the people who build and use them.

Keep the boundaries clear

The marketplace is not a model. The model gateway handles model requests, while the skills marketplace manages reusable capabilities and their lifecycle.

Autoinstallation is not universal. It reduces setup for the users covered by a default; it does not install every skill for every engineer.

Use is not quality. A skill used more than 20,000 times per day has evidence of use, not of correctness or outcome quality. The reported execution volume alone cannot distinguish those cases.

Publication is not completion. Lint and automated review create a release gate, while traces, comments, and continuous eval keep the skill in an improvement loop.

Check your understanding

1. What should happen after a skill passes lint and automated review?

It can be published to the skills marketplace, discovered or autoinstalled for the intended users, and executed. Traces and feedback from those runs then support continuous eval and improvement.

2. Why is a daily execution count not a quality score?

It measures use, not correctness. The speakers report the count without a quality definition or outcome measure, so it cannot establish that the skill performs well.

Synthesis

The speakers' fourth building block treats a skill as a managed product rather than a private artifact. Teams author core or domain-specific skills, shared gates check them, the marketplace distributes them, and execution traces plus continuous eval send evidence back to the authors. At the reported scale, the speakers present this lifecycle as the way to make reuse and improvement manageable.

The source segment runs approximately from 07:12 to 08:40. It does not define a skill's exact implementation or the criteria behind its lint and evaluation stages. The reported skill and execution counts are scale indicators from the speakers, not independent evidence of skill quality.