feat(registry): central agent asset registry for capabilities, skills, plugins, and MCP servers

[krokoko]

Component

CDK / infrastructure, API or orchestration, Agent (Python runtime), Scripts / CLI

Describe the feature

Introduce a central agent asset registry — a versioned, platform-managed catalog from which agents and blueprints resolve runtime artifacts instead of vendoring them in source or redeploying CDK for every tool/skill change.

The registry holds typed records for multiple artifact kinds, including (non-exhaustive):

Asset kind	Examples
Capabilities	Verification strategies, knowledge-tool configs, task workflow definitions
Skills	Agent skill packages (prompt + tool guidance)
Plugins	Claude Code / agent plugin bundles
MCP servers	Server definitions, tool descriptors, connection config
Prompt fragments	Reusable system-prompt sections
Cedar policy modules	Soft-deny packs, repo-specific policy extensions
Event rule packs	Lifecycle governance rules (pairs with #230)
Notification profiles	Channel rendering templates

Each record is immutable at a given version; blueprints pin semver constraints (no floating latest in production). At task start the orchestrator resolves pins, fetches artifacts, and provisions the agent environment — decoupling asset authoring from infrastructure deployment.

This enables more flexible, capability-driven tasks beyond the three hardcoded task types (new_task, pr_iteration, pr_review) without forking core orchestrator logic for every new workflow.

Use case

• Generic / composable tasks: Submit work defined by a capability bundle (tools + prompts + validation + policy) rather than a fixed enum task type.
• Org-wide rollout: Publish a new MCP server or skill version; blueprints re-pin when ready — running tasks keep their original pin.
• Reproducibility: Every execution records which asset versions were resolved (audit + eval).
• Extensibility without forking: Teams add skills/plugins/MCP defs through the registry instead of patching agent/ or CDK per tenant.
• Governance integration: Registry becomes the source of truth for tool-surface validation (RFC: Event-Driven Governance and Actions #230 Change Manifest L1/L5 concepts).

Proposed solution

Phase 0 — Schema and API contract

• Define asset record schema: { id, kind, version, semver, descriptor, artifact_ref, publisher, created_at, status }.
• Capability descriptors: structured metadata per asset — tool surface, permissions required, egress domains, Cedar actions introduced, runtime dependencies, minimum compute profile.
• Operator/publisher API: publish, get, list by kind/namespace, resolve (semver constraint → pinned version).

Phase 1 — Registry MVP

• Storage implementation (metadata index + artifact blobs) — implementation choice left to design PR; this issue does not prescribe specific cloud services.
• Resolve pinned assets at task start; pass resolved bundle to agent hydration / runtime bootstrap.
• CLI: bgagent registry list, bgagent registry show <id>@<version> (names TBD).

Phase 2 — Blueprint integration

• Extend Blueprint construct: mcp_servers, skills, capabilities, policy modules, etc. reference registry IDs + version constraints instead of inline definitions.
• Orchestrator resolves and records resolved versions on the task record.

Phase 3 — Lifecycle (follow-up or stretch)

• Deprecate / retire flow; bulk re-pin migration API.
• Cedar-governed publish ACLs (who can publish/pin by asset type and namespace).

Explicitly out of scope for MVP

• Full meta-agent tool generation (Feature: Integrate AKW multi-agent capabilities into ABCA #99 ToolBuilderAgent vision).
• Replacing shipped repo-local config (.mcp.json, AGENTS.md) — registry complements per-repo overrides.
• EventBridge as primary bus.

Acceptance criteria

• Asset kinds enumerated in schema; at minimum: capability, skill, plugin, mcp_server, cedar_policy_module, prompt_fragment.
• Publish + resolve API with semver pinning; immutability enforced per version.
• Blueprint can reference at least one asset kind via registry ID + constraint; orchestrator resolves at task start and persists resolved versions on task metadata.
• Agent runtime receives resolved artifact bundle and can load an MCP server or skill from registry (one end-to-end path sufficient for MVP).
• Capability descriptor validated at publish time (required fields, egress/policy declarations).
• Tests: resolution logic, semver edge cases, pin immutability; docs in design + roadmap sync.

Other information

• Roadmap: Agent asset registry section (docs/guides/ROADMAP.md) — Central asset registry, Capability descriptors, Blueprint registry references, Asset versioning, Registry access control.
• Related: RFC: Event-Driven Governance and Actions #230 (event-rule-pack assets defer to registry Phase 3), Feature: Integrate AKW multi-agent capabilities into ABCA #99 (broader AKW/generic-task vision — this issue is the focused, current-architecture registry track).
• Does not replace: Tool capability tiers (extended tool profile per repo) — may be a separate issue; registry supplies what to load, tiers supply policy gate on tool surface.

Acknowledgements

• I may be able to implement this feature
• This might be a breaking change

[scottschreckengaust]

Hi @Kalindi-Dev , before you begin work on this, let's chat about #381 to see what overlaps and what if any ADRs need to be revisited.