Photo: Google Gemini · AI-generated
An AI agent can now take a task, write the code, run the tests and open the change for review, on its own. The question is no longer whether to allow that. It is where the agent has to stop.
We use agents every day, on client systems and on our own. Here is the line we draw, and how we make sure it holds.
Two lists, not one dial
We do not run a “trust level” that slides up as the tools improve. We keep two lists.
The agent drives without asking when it works on its own branch, drafts code against a written task, writes and runs tests, refactors inside one module, proposes a database migration, writes documentation, or reads logs to diagnose a fault. All of that is reversible. If it is wrong, a person rejects the change and nothing has happened.
The agent stops and waits for a person before anything that is not reversible: merging into the main branch, touching production data or a production system, handling secrets or credentials, adding a dependency, changing an interface that other systems depend on, and any side effect outside the repository, which means sending, posting, paying or deleting. Architecture decisions are on that list too. The agent can argue for one. It does not make one.
A rule is a wish. A checkpoint is a mechanism.
Writing “the agent must not touch production” into a guideline changes nothing. The stop has to be built into the path.
So the agent’s credentials cannot reach production at all. Deny by default, the same rule we apply to any service account. Merging requires a human review and a green pipeline, and the pipeline runs the mechanical checks first, so the person reviews judgment rather than formatting. Secrets are injected at deploy time and never exist in the agent’s environment. And every action leaves a record: commits, pipeline runs, who approved what and when. The audit trail we build for a medical labelling system is the same idea applied to a machine.
What it looks like on a pipeline we run every day
This website and our LinkedIn content are produced with an agent. It picks the topic, writes both language versions, generates the image, builds the site, checks every internal link, commits, publishes and posts. Three stops are designed into that path.
First, mechanical checkers fail the run before anything ships. One walks the built site and rejects any link or image that does not resolve. Another rejects a social post that breaks a formatting rule, is missing alt text, or claims a personal experience in the wrong voice.
Second, a video never posts until a person has watched it and replied. The agent generates it, deploys it for review, sends a notification and stops. Twice this month it produced a clip we rejected; both times a person saw it first.
Third, the keys it needs live in the environment, not the repository, and posting from a personal profile is not automated at all. An endorsement produced by automation is not an endorsement.
The result after two months: dozens of publishes without an incident, and the human time spent on the parts that need judgment.
What it looks like in client work
The shape is the same. An agent’s change is a branch. It walks development, QA, test and live like any other change, the way every change to a manufacturer’s purchasing portal does. A person merges. Dependency scanning fails the build if the agent pulled in something with an advisory. The agent never holds a production credential.
The client sees the same pipeline whether a person or an agent wrote the change. That is the point. The guardrails belong to the delivery path, not to the tool, so they do not need renegotiating every time the tool gets better.
Where the line moves, and where it does not
The first list will keep growing. As tests and checks get better, more work becomes safely reversible, and the agent can take it. The second list does not shrink. Production, secrets, side effects and architecture stay with a person, because the cost of being wrong there is not a rejected pull request.
If you are introducing agents into a team and the plan is a policy document, start with the pipeline instead. Read how we build one path to production and how testing sits inside delivery, or talk to us about where your line should be.