docs(adr): agent deployment — template/skills bundles → provider-tagged provisioning

[brettchien]

Direction ADR for the deployment vision we aligned on in-thread (2026-08-15).

The idea

Studio should stand up agents, not just observe them. Grounded on three facts:

• An agent = a prebuilt image tag + a plain-file bundle (config.toml + persona + .claude/skills). Nothing in an agent's identity needs compiling.
• Compilation is CI/CD, never the deploy path — Studio consumes an image tag.
• The runtime isn't always ECS — k8s is on the roadmap, so deploy is provider-tagged from the start.

Decision (summary)

• Studio holds a template/skills library; composes a per-agent bundle (template ⊕ overlay, last-writer-wins).
• Provision via a provider-tagged RuntimeDriver: pick an image tag + push the bundle to the runtime's file carrier (S3 state for ECS via pre_seed, ConfigMap/volume for k8s) + apply the workload. The driver is the only layer that knows S3-vs-ConfigMap.
• Credential/region binding reuses the hermetic, provider-tagged approach from feat(desktop): provider-tagged, hermetic oab-mcp target (backend) #60; desired state records into the Fleet Store (ADR: Fleet Store & Control-Plane State Ownership #18) when it lands.

Boundaries

• Non-goal: building/compiling (CI/CD's job); the remote file editor over /acp (docs(adr): two consoles — management + per-agent agent consoles (endpoint registry + remote file editor) #49 Part D — editing a running agent) is deferred (different surface).
• Sliced: (1) library+compose → (2) ECS provision → (3) k8s driver → (4) Fleet-Store wiring.

Status: Proposed (draft) — direction alignment; open questions in §6 (bundle transport, template storage, skills-by-reference, image/file boundary).

🤖 Generated with Claude Code