AI agents work fine, your workflow doesn’t

Boards everywhere are saying “we need AI agents.” That pressure moves down the organization fast. Teams build a pilot and achieve good results in a sandbox. Then they try to put it in production and everything slows down. Usually, the model performed fine. What was missing was what surrounded it—monitoring, ownership, a plan for when things go wrong.

I’ve been shipping software in regulated industries for 20 years. In those industries, when something hallucinates, planes don’t fly or money doesn’t move. So you learn to care about the process more than the tools, and realize that the model is the easy part. You can swap one for another in an afternoon. What you can’t swap is the workflow underneath it, and the domain knowledge baked into how an agent actually makes decisions.

THE WORKFLOW IS THE PRODUCT

In production, you don’t release anything without a rollback plan. You collect metrics from day one because if you forget, you can’t answer questions later. Every layer needs to be traceable. None of it changes just because the code is being written by an agent instead of a person.

An agent in a regulated environment needs control on its decision logic, defined inputs and outputs, monitoring, and a way back to a safe state when something breaks. But the harder part is what comes before any of that—domain knowledge. The reason companies keep working with the same engineering teams for years is that those teams know which systems interact, which areas are fragile, and where a small change cascades. That accumulated understanding of a client’s business, processes, and technical landscape is what allows you to build agents that hold up in production. Without it, you may be automating processes you don’t fully understand. MIT’s 2025 research shows that 95% of enterprise AI pilots produce no measurable business impact, and the problem is consistently how organizations adopt, integrate, and govern AI.

ONBOARD AGENTS THE WAY YOU ONBOARD ENGINEERS

You don’t expect a new developer to do a proper feature or fix in the main branch on day one. There’s a ramp-up period and supervision. You start them on smaller tasks, review their work closely, and gradually increase the scope as they prove they can deliver reliably. Agents need the same treatment. That means giving them a clear “definition of done,” evaluating their output against known benchmarks, having someone review the results until trust is earned, and building an escalation path for when the agent hits something it can’t handle. The discipline we’ve spent decades building around human onboarding applies directly here, as well—we just haven’t been applying it.

Stack Overflow’s 2025 Developer Survey, with more than 49,000 respondents, found that 45% of developers say debugging AI-generated code is more time-consuming than expected. The output looks right. Then you look closer and it isn’t. A function passes its tests but handles an edge case in a way no experienced engineer would accept. That’s where the human job is moving—not writing code, but catching what the machine got almost right. And doing that well requires people who know what “right” looks like in a given domain.

REVIEW THE BLUEPRINT, NOT THE BRICKS

An agent can produce a thousand lines of code in seconds. If your senior engineers are reviewing all of that after the fact, they become a permanent bottleneck. A better approach would be to do a shift left and review the spec before the agent starts. A small misalignment early on compounds quickly. By the end, you’re looking at an output that barely resembles what was intended.

The teams understanding that have moved their senior people into something closer to an architect-supervisor role. They spend most of their time sharpening the brief, not inspecting finished work. That takes people who’ve shipped things in production, who know what breaks at scale, and who understand the domain well enough to write specs an agent can follow without drifting.

The models will keep getting better on their own. The workflows, the guardrails, the knowledge of what actually matters in a specific industry, all come from years of doing the work.

Denis Danov is CTO at Dreamix.

View the full article