Ship an agent like a service.
An agent should be something you version, gate and roll back — not something a person keeps alive. Deployments will turn an agent into a unit you ship into the boundary you already run. It is the furthest-out layer, and the ones beneath it are further along.
If it can reach production, it needs a version.
An agent that touches internal systems is production software, and it should get what production software gets: an artefact, a release, a gate before it ships and a way back when it regresses.
An agent becomes a unit
The loop, the tools, the prompts, the model policy — one versioned artefact you ship, rather than a process someone keeps alive by hand. What ran last Tuesday is a thing you can name.
Forward and back
Roll a new version out, canary it against a slice of the work, and roll it back when it regresses. A prompt change is a deploy, which means it has a diff, an owner and a way to undo it.
Gated before it goes live
An agent will not reach production because someone merged. It passes its check first — the same measure-and-verify loop that decides which model may serve a turn, applied to whether a version may ship at all.
Into your boundary, not ours
The deploy target is the deployment you already run. No agent leaves the perimeter to be hosted somewhere else, and no new egress path opens for the control plane to reach in.
The top of a stack, not a product on its own.
Deployments only mean anything once there is a runtime to deploy into and a plane to serve the work. Both are further along than this layer, and one of them is live.
Your release process is the spec.
How agents get reviewed, approved and rolled back inside a regulated estate is not something we can design in the abstract. If you already know what that has to look like, tell us.