There is a very specific moment in every AI project where the conversation stops being fun. It’s not when the model gives a wrong answer. It’s when someone asks: “Can it just fix it instead of telling us about it?”
That question is the line between a chatbot and an operator. Cross it and you’ve added a new kind of actor to your production environment—one that works at 3 a.m., doesn’t get tired, doesn’t ask for permission unless you make it, and can repeat a mistake four hundred times before anyone notices.
Read-only agents are safe, and mostly useless
Most organizations start with a read-only agent: it summarizes alerts, drafts a runbook, explains a stack trace. It’s a reasonable place to begin, and it’s genuinely helpful for onboarding.
But look closely at where the time actually goes in an incident. The expensive part is rarely understanding what happened—it’s the twelve steps after that: check the deploy, roll back the config, scale the pool, drain the node, open the ticket, notify the customer. A read-only agent watches you do all of it.
So the value is on the other side of the line. Which means the honest engineering question isn’t “should we let agents act?” but “what do we need to be true before we let them?”
The three questions I ask before granting write access
Before an agent gets a credential that can change something, I want clear answers to three things. They’re not exotic. They’re the same questions you’d ask about a new junior engineer—just asked more precisely.
- Blast radius: what is the worst thing this action can do if the reasoning is wrong? Not the likely thing—the worst thing.
- Reversibility: can we undo it, how fast, and does undoing it require the same agent that broke it?
- Attribution: six weeks later, can we prove exactly which agent, running which version, using which prompt and which credential, took that action?
If any answer is fuzzy, the agent doesn’t get write access yet. Not as a policy stance—as an engineering one. You can’t operate what you can’t explain.
Give the agent its own identity. Never your credentials.
The single most common shortcut I see is running an agent under a human’s token or a shared service account that already had broad permissions. It works immediately, which is exactly the problem.
An agent should be a first-class principal in your identity system: its own identity, its own short-lived credentials, its own scoped permissions, and its own audit trail. When something goes wrong at 2 a.m., “who did this?” must have a real answer—and “the deploy bot, which is technically Sarah’s account from 2023” is not one.
Scope permissions to the workflow, not the platform. An agent that restarts a service does not need the ability to delete a database. That sounds obvious written down; it is very rarely true in practice.
Tier your actions, then earn your way up
The pattern that has worked best for me is a simple tiered model. Every action an agent can take lands in one of three buckets, and the bucket determines the control, not the enthusiasm of the team.
- Tier 1 — autonomous: reversible, bounded, low blast radius. Re-run a failed job, open a PR, tag a resource, draft a ticket, roll a stateless pod.
- Tier 2 — propose and confirm: the agent prepares the exact change and a human approves it. Config changes, scaling decisions, dependency bumps, infrastructure plans.
- Tier 3 — never: data deletion, IAM changes, production database writes, anything touching customer funds or safety systems. These stay human, permanently.
Actions move from Tier 2 to Tier 1 by earning it: enough clean executions, a measured error rate, and a rollback path that someone has actually tested. Not by someone deciding the agent “seems reliable now.”
Design for the bad day, not the demo
Agents fail differently than scripts do. A script fails loudly and stops. An agent fails plausibly—it keeps going, it explains itself confidently, and it may work around the very guardrail you added because working around obstacles is what you asked it to be good at.
That has practical consequences for how you build:
- Rate limits on actions, not just on tokens. An agent that can restart one service can restart forty.
- A kill switch that doesn’t depend on the agent. If disabling it requires the agent to cooperate, you don’t have a kill switch.
- Idempotency everywhere. Assume every action may be retried, because it will be.
- Loop detection. The same action, on the same resource, three times in five minutes is a bug—stop and escalate.
- Structured action logs. Not the chat transcript. The actual API calls, with inputs, outputs, and the identity that made them.
Human-in-the-loop is a design decision, not a checkbox
“We keep a human in the loop” is comforting and frequently meaningless. If the human sees a summary and a green “Approve” button forty times a day, you don’t have oversight—you have a click ritual with a person’s name attached to it.
Real approval requires three things: the reviewer can see the exact change, they can see what it will affect, and saying no is genuinely easy. If your approval UX makes rejection feel like obstruction, your humans will approve everything, and you’ve built autonomy with extra steps and worse latency.
Approve less, but approve properly. Ten meaningful reviews beat four hundred reflexive ones.
The uncomfortable part: your process becomes the bottleneck
Here’s what surprises most teams. Once agents can act, the constraint stops being the model. It becomes everything the model has to work through: undocumented deploy steps, tribal knowledge, permissions nobody can explain, environments that drift, runbooks that describe a system from two years ago.
Agents are ruthless auditors of operational maturity. They expose exactly where your automation was always a person quietly compensating. Teams with clean infrastructure-as-code, real observability, and documented recovery paths get enormous leverage almost immediately. Teams without those get a very articulate assistant that keeps asking for context nobody wrote down.
Which, honestly, is the most useful thing an agent rollout does in year one: it tells you the truth about your platform.
A rule of thumb worth keeping
Let an agent take any action you would be comfortable letting a competent new hire take on their second week—with the same supervision, the same permissions, and the same expectation that they’ll occasionally get it wrong in a way that is annoying but not catastrophic.
That framing does most of the work. It keeps you from being paranoid about reversible things, and it keeps you from being casual about the things that end careers.
Agents in production are not a leap of faith. They’re an extension of the discipline you should already have: least privilege, strong identity, tested rollback, honest logging. If those are solid, this is exciting. If they aren’t, fix them first—the agent will find every gap anyway.