Agent Factory Capability Supply Chain and Registries
Explain how reusable agent capabilities move from an idea to an approved, discoverable, operable factory component.
A rapid review of the chapter’s existing Quick Read, principles, definitions, lessons, and review material.
The chapter in one pass.
- Purpose: Explain how reusable agent capabilities move from an idea to an approved, discoverable, operable factory component.
- Best for: Platform architects, agent engineers, security engineers, and technical leaders defining the boundary between capability creation and delivery authority.
- Prerequisites: Software Factory Stack Boundaries and Agent Architecture.
- Reading time: 14 minutes.
- You will learn: The records, gates, ownership, and lifecycle required for agent, skill, tool, prompt, model-profile, and evaluator registries.
- Keep three ideas: a registry is an authority surface, not a directory; a capability is a versioned dependency graph, not a name; and publication never authorizes delivery work.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Draw the supply chain for an agent that composes two skills, three tools, a model profile, a context policy, and an evaluator. Add one incompatible harness, one revoked tool, one unowned dependency, and one expired evaluation. Mark where each condition is detected and who can approve an exception.
3. Enduring Principle
Treat capabilities as governed supply-chain artifacts
The Agent Factory creates and manages reusable capabilities. The Software Factory consumes exact, approved versions to execute authorized delivery work. Keep those responsibilities separate:
Use one capability identity model
Every registered capability needs:
- a stable identity, type, owner, source, license, and support tier;
- immutable version and digest;
- declared inputs, outputs, side effects, permissions, and data classifications;
- dependencies on tools, protocols, models, runtimes, policies, and other capabilities;
- evaluation suites, results, limitations, and known failure modes;
- compatibility ranges and qualified environment combinations;
- lifecycle state such as draft, candidate, certified, deprecated, quarantined, or revoked; and
- provenance from source revision through package and signature.
Agents, skills, tools, prompts, model profiles, evaluators, context packages, and workflow recipes share this envelope while retaining type-specific contracts. A tool needs executable schemas and side-effect declarations. A prompt needs parameter and output contracts. A skill needs decision criteria, examples, tools, and evaluation cases. An agent definition composes several of these artifacts.
Separate catalogs from registries
The catalog is optimized for people and agents to discover capabilities. The registry is optimized for authoritative resolution. Search may use natural language, tags, domains, and examples; execution must resolve a canonical identity, version, digest, policy decision, and compatibility result.
Make resolution fail closed
The resolver evaluates the entire dependency graph. It must reject missing versions, revoked transitive dependencies, incompatible harness features, unapproved data access, expired certification, or ambiguous ownership. “Latest” is not a reproducible execution binding.
8. Notes and lessons learned
Capability reuse becomes safe only after ownership, identity, evidence, and retirement are as easy to inspect as the capability itself. The useful analogy is not an app store; it is a package registry combined with policy, qualification, and operational inventory.
9. Interview and discussion questions
- Why is a searchable list not necessarily a registry?
- Which metadata belongs in the shared capability envelope?
- How should a resolver react to a revoked transitive tool dependency?
- What should certification prove, and what can it never prove?
- Why must capability publication remain separate from delivery authorization?
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence