How to Make AI Agents Reliable in Production: 4 Conditions That Decide It

Ninety percent of the developers in this year's DORA survey use AI at work. More than eighty percent say it has made them more productive. Thirty percent say they have little or no trust in the code it writes.

Read those three numbers together and they look like a contradiction. Almost everyone uses it, most people feel faster, and a third of them do not believe the output. That is not a contradiction. That is what a tool looks like when it has been adopted faster than it has been absorbed.

DORA surveyed nearly 5,000 technology professionals and collected over 100 hours of qualitative interviews to get at why, and the finding they led with is the most useful sentence written about agents this year:

"AI doesn't fix a team; it amplifies what's already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems."

I have been running agent systems in production across my own products for most of a year now, and that line matches what I see every week. The model is not the variable. Every serious builder is within a few months of the same frontier capability. The variable is the surface the model lands on.

Which means the useful question is not "which agent should I use." It is "what does my current setup amplify."

Four conditions, and what happens without each one

I want to give you these as pairs, because the interesting part is never the good version. Everyone can picture the good version. The interesting part is what the exact same agent, on the exact same model, produces when the condition is missing.

1. A written standard.

Present: the agent inherits your judgment. It knows what you consider finished, what you consider sloppy, and what you would never ship. It applies that consistently at three in the morning, when you are asleep and cannot be consulted.

Absent: it invents a standard. Not once, but freshly, every run. You get output that is defensible in isolation and incoherent in aggregate, because nine runs made nine slightly different calls about the same question. This is the most common failure I see, and it never announces itself. Each individual result looks fine.

The fix is boring and it works: write the standard down in the place the work actually reads from. Not in your head, not in a chat you had last week. Most teams skip this because writing a standard is hard and prompting is easy, and then they spend the saved hour ten times over.

2. A bounded job.

Present: a wrong run is cheap, visible, and reversible. You can afford to let the thing be wrong, which is the entire reason it can be autonomous at all.

Absent: the blast radius is whatever the agent decided to touch. And here is the part people underrate: unbounded jobs do not just fail worse, they fail slower. A bounded job that goes wrong tells you in ten minutes. An unbounded one tells you in three weeks, through a customer.

Bound every job with a window and a budget before you bound it with a prompt. If you cannot say what the worst run of this job costs you, it is not ready to run unattended.

3. A record you can check.

Present: you can tell a good week from a lucky week. You can look back at thirty runs and see the shape of the thing, which is the only way anyone has ever improved a process.

Absent: the agent reports its own success in prose, and prose about your own performance is unfalsifiable. "Completed successfully, reviewed 14 items, no issues found" is a sentence that reads identically whether the job worked perfectly or did nothing at all. I have been fooled by exactly this sentence more than once.

Make the deliverable an artifact rather than a summary. A file, a row, a diff, a queue entry. Something that exists whether or not the agent felt good about the run.

4. A named owner.

Present: somebody rules on the output. Not reviews everything, rules on the edge cases, and their ruling goes back into condition one.

Absent: output accumulates. This is the quietest of the four and the most expensive. Nothing breaks. There is just steadily more of something, and no one has decided whether any of it was right, and by the time anyone looks the volume makes looking impossible.

If you cannot name the person who owns an agent's output, you do not have an agent. You have a generator.

Where this is going

DORA also found that AI acceleration exposes weaknesses downstream, and identified seven distinct team profiles rather than one path. That plurality is the signal. There is no single "adopt AI" move, because the move depends entirely on what your organization already is.

Here is my read on where the paying work goes. Generation has collapsed in price and will keep collapsing. What has not collapsed, and shows no sign of collapsing, is the cost of making generated work survive contact with a real business. That is a specification problem, an ownership problem, and an operations problem, and none of the three gets solved by a better model.

So the person who gets paid over the next few years is not the one who can build the thing fastest. It is the one who can install the four conditions above into a business that does not have them, and then keep the whole arrangement running. That role has a name now in more than one company: forward deployed engineer. I think it becomes the default shape of technical work, not a specialty.

If you are trying to position yourself, position there. Not on prompt tricks, which have a shelf life measured in months, but on the ability to make an autonomous system trustworthy inside somebody else's operation. That skill is durable because it is mostly not about the model.

What I built around this

The Agent Ops Club is where I put all of it. Eight AI employees you can hire for real roles, SEO, go to market, web development, social media, ads, sales, customer satisfaction and a chief of staff, plus a 45 lesson masterclass that walks through deploying and customizing them, and a product pass covering 27 premium systems with a resale license, so you can install a system for a client and keep every dollar of the deployment.

The free account is genuinely free and takes no card. It gets you the eight AI employees under an MIT license, the first two masterclass modules complete, the public trainings, and daily access to Agent Ops Chat. If the four conditions above are the argument, the free tier is the cheapest possible way to test whether you agree with it.

Have a look: https://club.reinventing.ai

One ask, and it is a small one. If you have run an agent unattended in production, tell me in the comments which of the four conditions you got wrong first. I will bet on number three more often than not, and I would like to know if I am wrong about that.

If you want the ongoing version of this conversation, Vibe Coding is Life is where I spend my time, 335,000+ builders arguing about exactly this: https://facebook.com/groups/vibecodinglife

Source for the survey figures: the 2025 DORA State of AI-assisted Software Development report, https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report