RFC: Agent-initiated artifact promotion to asset registry

> **Roadmap:** Central asset registry (#246); Agent asset registry epic
> **Priority:** P3

## Primary area

Cross-cutting / multiple

## Related issue or feature request

Roadmap: Central asset registry, Asset lifecycle management; issue #246 (if filed)

## Summary

Design the lifecycle for **agent-initiated harness artifacts** — tests, temporary tools, reusable skills, verification scripts — created during task execution and optionally **promoted** into the platform asset registry. Literature (arXiv:2605.18747) identifies agent-authored executable artifacts as an underexplored harness layer distinct from system-provided infrastructure.

RFC only; no implementation in this issue.

## Use case and motivation

- Agents that write regression tests or helper scripts today leave them only on the task branch.
- Reuse across tasks requires manual copy or human promotion.
- Registry epic (#246) covers operator-published assets; this RFC covers **agent-origin** assets with stricter governance.

## Proposal

### Artifact classes

| Class | Example | Promotion gate |
|-------|---------|----------------|
| `verification_script` | New pytest module | CI green + human approve |
| `skill` | Claude skill markdown | Descriptor review + Cedar actions audit |
| `mcp_tool_stub` | Local MCP config fragment | Supply-chain review (MCP controls roadmap) |

### Lifecycle states

`ephemeral` (branch-only) → `draft` (registry, task-scoped) → `validated` (CI + review) → `production` (blueprint-pinnable)

### Promotion flow

1. Agent marks artifact in task output manifest (`agent_artifacts[]`).
2. Post-task Lambda or operator CLI `bgagent artifact promote` submits to registry.
3. Cedar policy: who may promote; HITL for production tier.
4. Blueprint pins asset version (no floating `latest`).

### Before / after

**Before:** Useful agent-generated test dies on branch after merge.

**After:** Operator promotes vetted test to registry; future tasks on repo resolve pinned version.

## Out of scope

- Autonomous promotion without human approval
- Unsupervised production deploy of agent artifacts
- Implementation in this RFC issue

## Potential challenges

- **Supply chain:** Agent-generated code in registry is high risk — require signing, scan, quarantine
- **Duplication:** Multiple tasks produce similar skills — dedup/version merge policy
- **Parity:** Registry descriptor must match what agent actually executed (hash match)

## Dependencies and integrations

- Central asset registry epic (roadmap)
- Cedar HITL for promotion approvals
- Tiered validation pipeline for verification scripts
- Capability descriptors roadmap item

## Alternative solutions

- **Git-only promotion:** Merge to repo; no registry — simpler but no cross-repo reuse.
- **Memory-only storage:** Loses executability and versioning semantics.
- **S3 task artifacts only:** No semver or blueprint pinning.

---
**Note:** Non-triaged RFCs may not get timely review. PRs on non-triaged issues might not be accepted.

* RFC PR:
* Approved by:
* Reviewed by:

Start by reading the central asset registry epic (#246), then review the proposed artifact classes, lifecycle states, promotion flow, and listed dependencies in this RFC. Done means producing a reviewed design with agreement on governance, validation, signing, deduplication, and version-pinning requirements; this issue explicitly has no implementation scope.

Written by the indexing model from the issue text.