Capability Packaging, Versioning, and Dependency Resolution
Make agent capabilities reproducible, composable, and safely replaceable.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Open the source exercise
Design resolution for a repository-review agent with two alternative model routes and a tool available only in one environment. Add a critical tool revocation during an active Attempt. Separate behavior for the active Attempt, queued work, and historical replay.
4. Tradeoffs and alternatives
Strict locks reduce drift but slow emergency provider substitution. Prequalify bounded fallback graphs and record when a fallback changes the execution identity. Broad version ranges ease upgrades but increase the chance that the same workflow behaves differently over time.
Bundling every dependency into one artifact improves reproducibility and creates large release units. Fine-grained packages increase reuse and dependency complexity. Choose boundaries aligned to ownership, evaluation, and rollback.
5. Current Mission Control Implementation
The studied architecture freezes many material bindings in Factory Versions and Execution Manifests and defines capability manifests for harnesses, environments, routes, and agents. The existing guide also recognizes exact model routes and immutable context packages.
It does not yet show a single package format, complete transitive lock, universal compatibility suite, or migration mechanism spanning agents, skills, prompts, tools, and evaluators. Runtime substitutions therefore require explicit scrutiny rather than an assumption of parity.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence