16 June 20262 min read

How to make AI coding agents reliable in production

Reliable agents aren't a better model, they're the engineering around it: scoped permissions, review gates, observability, and context the agent can trust.

tsukumo

How to make AI coding agents reliable in production

Short version: making AI coding agents reliable in production isn't a better model; it's the engineering around it. Four things do the work: scoped permissions so an agent can't touch what it shouldn't, review gates that a human or a check must pass before merge, observability so you can see what each agent did and what it cost, and context the agent can trust. Skip them and you get confident, expensive mistakes.

Why agents are unreliable by default#

An agent dropped into a real codebase with broad access, no gate, and no record is a liability, not because it's dumb, but because nothing is set up to constrain or check it. It acts on whatever it believes, and when what it believes is wrong, it's wrong confidently and at machine speed. The widely-reported incidents where an agent deleted data or shipped a breaking change all share that shape: capable model, missing guardrails. Agent verification and observability became commercial disciplines in the last year for exactly this reason.

The four things that make an agent reliable#

1. Scoped permissions#

An agent should be able to touch only what its task requires, nothing more. Broad, standing access is how a small mistake becomes a big one. Scope it like you'd scope a service account.

2. Review gates#

Nothing the agent produces should reach production without passing a gate: a human review, a required check, your existing CI, or all three. This is the same bar you hold a new engineer to, and it's where most "the agent broke prod" stories would have been caught.

3. Observability#

You cannot operate what you cannot see. You need to know, close to real time, what each agent did, what it cost, and where it failed, so agents become a measurable system instead of a black box with commit access. We built yoru because we needed exactly this on our own fleets.

4. Context the agent can trust#

A lot of "unreliable" is really "uninformed." An agent fed stale or partial context is confidently incorrect. Serve it the current, canonical answer about your codebase on demand and a whole class of failures disappears. (It's why we built trovex.)

The operating model: a human at the gate#

Guardrails are software; the last layer is people. Reliable agent work has a developer operating it, setting the goal and guardrails, reviewing at the right altitude, and stepping in when the agent goes wrong. The agents do whole units of work; the human owns the gate and the outcome. Across a fleet, that's coordination too, which is why orchestration (our WRAI.TH) sits under it.

How tsukumo does it#

We run agent fleets in production to ship our own software, so we've paid for every failure mode above and built the four layers to fix them. When we work with your team, we install the same guardrails, observability, and context on your stack and standards, and train your developers to operate them, so reliability stays after we leave.

If your agents work in a demo and scare you in production, that gap is the work we do. Read running agent fleets in production for the fuller picture, or talk to us about your team.

Common questions

Why are AI coding agents unreliable in production?

Not because the model is bad, but because nothing around it is set up. By default an agent has broad access, no gate before its changes land, no record of what it did, and weak context, so it acts confidently on wrong information. Reliability comes from the engineering that constrains and checks it, not from the model alone.

Can you trust an AI agent with commit access?

Only with scoped permissions and a gate. An agent should touch only what its task needs, and its changes should pass a human review or an automated check before they merge, the same bar you'd hold a new engineer to. Public incidents where agents deleted data happened precisely where those guardrails were missing.

What makes a reliable agent different from an impressive demo?

A demo runs once, on a clean example, with a human quietly fixing what breaks. A reliable agent runs repeatedly, on your real codebase, inside your standards, with guardrails and observability instead of a person rescuing it. The difference is all the unglamorous engineering a demo is built to hide.

Do better or bigger models make agents reliable?

They help at the margin and don't fix it. A stronger model still needs scoped permissions, review gates, observability, and good context to be trustworthy in production. Reliability is an operating problem, not a model upgrade.

Want this running on your team?

Talk to us about your team