Application code has a lifecycle everyone recognizes: local, branch, staging, production, with gates between. Agents usually have none. A developer builds one, it works, it gets pointed at production, and it stays there indefinitely with whatever permissions it accumulated during development.

That is how you end up with production agents holding development-era credentials, no owner, no evaluation baseline, and no expiry. The fix is not heavy process — it is a small number of explicit stages with different default authority, and one gate that establishes the things nobody establishes later.

The Stages

Draft. Being built. No production data, no production credentials, no external side effects. Connections point at synthetic or de-identified fixtures. Spend ceiling small enough that a runaway loop is a rounding error. Broad tool access is fine here, because nothing it can reach matters.

Evaluated. The agent has an eval suite and a recorded baseline. Still not production authority, but its behavior is now measurable, which is the precondition for anyone reasonably approving it. See agent evaluations: catching quality regressions.

Staged. Running against production-shaped data with narrowed scope, either shadow (producing output nobody acts on) or serving a small cohort. Guardrails enforcing. This is where the operational surprises appear.

Production. Full intended scope, narrowest possible, monitored, with alerting and an owner on call.

Deprecated. Superseded but still running for compatibility. Scope should be reduced, not maintained, and an end date set.

Retired. Triggers disabled, credentials revoked, connections removed, audit history preserved. See secure agent offboarding and deprovisioning.

The important property is that stage determines default authority. A draft agent cannot reach production data because its stage forbids it, not because the developer remembered to point it elsewhere.

Promotion Narrows, It Does Not Widen

The counterintuitive part, and the one that matters most.

During development, agents are given broad access because narrowing scope while iterating is friction. Forty tools connected, a database credential with full access, no volume caps. That is defensible in a sandbox with fake data.

The failure is that promotion inherits it. The agent goes to production with the tool set and credentials it had in draft, because nobody enumerated what it actually needs.

So the promotion gate must include a scope reduction based on observed usage: which tools did it actually call during evaluation and staging, with which argument shapes, at what volumes. That is empirical data, not a guess, and it produces a narrow grant that will not break. An agent configured with forty tools and observed calling three gets three. See how to implement least privilege for agents and OTLP telemetry ingest for agent discovery.

Do the same for credentials: production connections get freshly-minted, narrowly-scoped, short-lived credentials, not the ones used in development. Development credentials have been in more places.

What the Gate Checks

Automate what can be automated so human review time goes to judgment.

Automated:

  • An eval baseline exists and meets the threshold for this agent's task class.
  • Adversarial test cases pass — no prohibited tool calls, no data leakage on the marker tests.
  • Requested scopes are a subset of observed usage, with any excess flagged.
  • Spend ceiling and rate limits are set, not defaulted to unlimited.
  • Guardrails are attached to every connection, in enforcing mode.
  • No credentials appear in prompts or configuration.
  • An owner is set and resolves to an active person or team.
  • A review or expiry date is set.

Human judgment:

  • Is the scope proportionate to the described function? This is the highest-value item and the one automation cannot do.
  • Does this create a new path between trust zones, or a cycle in the delegation graph? See agent topology maps.
  • Which actions are irreversible, and are those gated for approval?
  • What is the containment plan if it misbehaves — who is on call, and what is the kill path?
  • Is the data flow acceptable: what leaves the boundary, to whom, under what terms?

The scope-proportionality question is worth a specific reviewer discipline: read the agent's stated purpose, then read its requested scopes, and ask whether a reasonable person would predict one from the other. A summarizer requesting write access to a CRM fails that test regardless of how the requester justifies it.

Owner and Expiry at Creation

Two fields, set when the agent is created rather than at promotion, that prevent the most common long-term problem.

Owner. A named person or a team with an on-call rotation, not "the platform team." Ownership is what makes a review request actionable and what connects human offboarding to agent review — when someone leaves, their agents get reviewed.

Review or expiry date. Every agent has one. Renewal is a deliberate act: someone confirms it is still needed. Expiry-by-default converts silent accumulation into an explicit decision, and it is the single highest-leverage lifecycle control. Experimental agents get short defaults; production agents get longer ones with an annual review.

Without these two fields, agents accumulate indefinitely and nobody can say which are still needed. With them, the inventory stays roughly honest without anyone running a cleanup project.

Versioning Within a Stage

Promotion is not the only change. A production agent's prompt, tools, model, and policy all change over time, and each change is a potential regression.

Version the agent configuration as a unit — prompt, tool set, model and version, routing rules, guardrails, and scopes — so a change is a new version with an atomic activation and rollback. Then:

  • Every enforcement and execution record names the agent version that produced it.
  • Eval results attach to a version, so comparisons are meaningful.
  • Rollback restores a consistent state rather than requiring several coordinated edits.
  • Staged rollout applies to versions: new version to a cohort, promote on clean metrics.

See versioning and rollback for AI agents and policy as code and guardrail versioning.

Material changes — new tools, new connections, wider scopes, a different model tier — should re-enter the gate rather than shipping as an ordinary version bump. Non-material changes should not, or the process becomes an obstacle.

Keep It Fast

A promotion process that takes two weeks produces agents deployed outside it. The friction budget is roughly: automated checks in minutes, human review in a day for straightforward cases.

Get there by tiering. An internal read-only agent with narrow scope and no personal data gets a light review. An agent with write access to customer-facing systems gets a thorough one. Uniform depth means either slow promotion of simple agents or shallow review of risky ones — and teams notice which.

Also make the governed path convenient in itself: if promotion provisions the production credentials automatically, developers have a reason to use it beyond compliance. See detecting shadow MCP servers for the same dynamic applied to integrations.

Common questions

Is this not just SDLC applied to agents?

Structurally yes, with three differences that matter. The artifact is configuration rather than code, so it changes outside your deployment pipeline. Quality is statistical rather than binary, so the gate needs an eval baseline rather than passing tests. And the authority the artifact holds is a first-class part of the review, in a way that is unusual for application code — most code does not come with a permission request attached.

How do I handle agents built by non-engineers?

They need the same gates with a different interface. A business user assembling an agent from templates should hit the same scope-proportionality and owner-and-expiry requirements, presented as guided choices rather than configuration files. What must not happen is a low-code path that bypasses the gate, because that path will be the popular one. See chat-to-build AI workflow generation.

What about agents that other agents create?

Same lifecycle, with the creating agent recorded as the requester and a human as the approver. An agent that can promote another agent to production authority is a privilege escalation path. Agent-created agents should default to the most restrictive stage and require human promotion.

Do experimental agents really need governance?

They need the cheap parts: an owner, a short expiry, a small spend ceiling, and no production data. That is four fields and it costs almost nothing. Most orphaned agents in a mature estate started as experiments, so the expiry field is doing the heavy lifting — it turns "we forgot about it" into "it stopped working and someone had to decide."

How Praesidia approaches agent lifecycle

Praesidia registers agents as first-class entities with owners, connections, guardrails, spend ceilings, and trust requirements as versioned configuration, so an agent's authority is explicit and reversible in a single step. Because governed calls record the tools actually invoked and their argument shapes, promotion can narrow scope from observed usage rather than from a developer's estimate.

Evaluation runs and datasets provide the baseline a promotion gate needs, discovery surfaces agents that were never registered, and retiring an agent revokes credentials and halts in-flight work while preserving the tamper-evident audit history. See agent management console and the Praesidia documentation.