Promote agents through lifecycle gates

Promotion gates are one of the AgentOps certification methods. They define the lifecycle stages an agent moves through on its way to production, the criteria it must meet to enter each stage, and the workflow that promotes it.

Why agents need promotion gates

Today, an agent that works in a developer's experiment either goes straight to production with that developer's access, or stays in a pilot indefinitely because nobody has defined what "ready" means.

With promotion gates, every agent has a lifecycle stage in Port, and the criteria for each stage are scorecard rules. A promotion workflow checks those criteria, moves the agent forward automatically or with approval, and widens its permissions to match.

Pain point	Without Port	With Port
No definition of ready	Useful agents stall in pilots for months, while others reach production before they're safe.	Agreed gate criteria for each stage, so ready agents move forward fast and unready ones don't.
Unproven agents in production	Some agents skip evaluation or get production permissions before they've proven themselves, so one bad decision by an untested agent can change production systems.	Every agent passes the same gates, and permissions widen stage by stage, so an agent's access matches the trust it has earned.
No record of why	Nobody can say who approved a misbehaving agent or on what evidence, so the mistake repeats.	Every promotion records the criteria it passed and who approved it, so you can learn from every incident.

Lifecycle stages

A typical agent lifecycle has five stages:

1. Development - the agent is being built. It runs only in local or test environments, with read-only or sandboxed access.
2. Evaluation - the agent runs against a fixed set of tasks to measure its quality, safety and cost.
3. Pilot - a small group of users or a single team uses the agent on real work, usually with human approval required for every action.
4. Production - the agent is available to everyone it is meant for, with the permissions it was certified for.
5. Deprecated - the agent is being retired. It no longer receives new users, and its credentials are scheduled for removal.

As an agent advances, its permissions widen and so does its blast radius: the systems, data and users it can affect if it misbehaves. Each gate makes sure the agent has earned that wider reach, and there is no direct path from development to production.

Gate criteria

Each gate defines what must be true before an agent enters the next stage. Express each criterion as a scorecard rule, so Port evaluates it continuously.

Gate	Example criteria
Development to evaluation	The agent has an owning team. It runs under its own scoped identity, not a personal token. It is registered with its skills and MCP servers.
Evaluation to pilot	The agent meets your evaluation pass threshold. Every skill and MCP server it uses is certified at its current version. It is configured to use the approved AI gateway.
Pilot to production	The agent has an SLA, on-call coverage and an escalation path. Its blast-radius score is within the allowed range. Its pilot results meet your quality and cost targets.
Production to deprecated	The agent has been replaced, is unused, or no longer meets its ROI target. Dependent workflows have been migrated.

Start with a few criteria and add more as you learn what matters for your agents.

How agents get evaluated

No single method is enough to evaluate an agent. Combine several:

• Deterministic checks - scorecard rules on the agent's configuration, such as ownership, identity, gateway use and certified dependencies.
• AI-based evaluation - an LLM judge reviews the agent's configuration, such as its system prompt, skills and tools, and its possible outputs on a fixed set of tasks, for correctness, safety, policy compliance and token efficiency.
• Sandbox environments - run the agent against partial or mock data in an isolated environment, so you can see how it behaves on realistic tasks without touching production systems.
• Adversarial testing - before production, try to make the agent misbehave: manipulate its inputs, chain its tools in unexpected ways, or bypass its approvals. Turn every finding into a new gate criterion or guardrail.

If you already use an evaluation or observability tool, keep it. Ingest its results into Port as properties on the agent, so your gates can use them alongside everything else Port knows about the agent.

The promotion workflow

A promotion workflow moves an agent from one stage to the next:

1. The agent's owner requests promotion, or the workflow triggers when the agent reaches the required scorecard level.
2. The workflow checks every criterion for the target stage.
3. If a criterion fails, the owner gets a clear list of what is missing.
4. If all criteria pass, the agent is promoted, automatically for early stages or after human approval for production.
5. The workflow updates the agent's lifecycle stage and widens its permissions to match.

Gates also work in reverse. If a skill or MCP server an agent depends on loses its certification, the agent is automatically restricted, for example by removing tools or allowed workflows or requiring approval for every action, until the dependency is certified again. See contain agents with a kill switch for how violations are handled.

Related guides and docs

• Manage scorecards - define gate criteria as scorecard rules.
• Workflows overview - build the promotion workflow, including approval steps.
• Agent registry - track agents and their lifecycle stage in Port.