# AI Agent Rollout Checklist
By Alexandr Rich · alexandrrich.com

For engineering leaders whose teams are moving from AI coding assistants
to agents that act on their own.

A prompt is not a control system.
Every item below is something that should be enforced outside the model,
not just written into its instructions.
Tick an item only when you can point at where it is enforced.

## 1. Inventory: know what is running
- [ ] There is one list of every agent and AI tool that can change code or systems.
- [ ] Each one has a named human owner.
- [ ] You know which model and version each agent uses, and who can change it.
- [ ] You can answer "which agent is working on what right now?" without asking around.

## 2. Permissions: instructions are not access control
- [ ] Each agent can reach only the repositories, branches and systems its job needs.
- [ ] Credentials are scoped per agent, not shared from a person's account.
- [ ] No agent can push directly to a protected branch or deploy to production.
- [ ] Anything irreversible (data deletion, payments, messages to customers, infra changes) needs a human.
- [ ] Removing an agent's access takes minutes, and someone has tried it.

## 3. Context: agents work from what is true today
- [ ] Current architecture, standards and past decisions are written down where agents read them.
- [ ] Each task arrives with a brief: the outcome, the constraints, and what done means.
- [ ] When a decision changes, the agents' context changes the same day.
- [ ] Agents are told what they may not change, and something checks it.

## 4. Gates: work earns its way to merge
- [ ] Every agent-written change goes through a pull request.
- [ ] A required check blocks changes that skipped your process.
- [ ] Tests, security scanning and architecture rules run on agent work, not only human work.
- [ ] A person other than the requester approves anything risky. No self-approval, human or agent.
- [ ] Retries are limited. After a set number of failures the work goes to a person.

## 5. Coordination: many agents, one codebase
- [ ] Two agents cannot pick up the same piece of work.
- [ ] Conflicting changes are caught before merge, not after.
- [ ] Work moves between roles (build, review, QA, security) by rule, not by chance.

## 6. Audit: you can prove what happened
- [ ] For any merged change you can see who asked, which agent did it, what it was told, what checked it and who approved it.
- [ ] That record is kept somewhere the agent cannot edit.
- [ ] You could answer an auditor's question about a change made six months ago.

## 7. Measurement: manage agents like a team
- [ ] You track, per agent: work completed, first-pass approval rate, rework, cost and time.
- [ ] You know which agent is best at which kind of task.
- [ ] Spend has a budget per agent or per team, with an alert before it is exceeded.

## 8. People: agents still need managers
- [ ] Engineers know which work is theirs to supervise.
- [ ] Reviewing agent work is counted as real work, not squeezed in between tasks.
- [ ] There is a clear way to stop all agent work in an incident.

## Where are you?
Mostly ticked: you are running agents like a team.
Mostly empty: your agents are running on prompts and hope.
Start with sections 2 and 4. They prevent the most expensive mistakes.