Are Your Processes Making AI Agents Worse?

Joseph Ours leads the AI Strategy Practice at Centric Consulting.

gettyThe fastest way to waste an investment in AI agents is to make them work exactly like people.

Organizations are doing it anyway—dropping agents into human-designed processes, then mistaking the resulting friction for a limitation of the technology. They keep the same handoffs, review points, templates and interim work products, then wonder why the agent doesn’t deliver the speed or efficiency they expected.

The process is frequently what’s holding it back.

A recent Deloitte study found that among senior leaders at organizations already piloting agentic AI, 74% expect nearly half of their business processes to be redesigned or rebuilt around agents within four years. Yet, business processes were the least prepared area in the survey. Only 21% of leaders called their processes ready, and just 5% called them highly prepared.

That sounds like a process-readiness problem, but organizations often solve for the wrong kind of readiness. They document what’s already there and repackage it for an agent to consume, without asking whether any of it makes the agent more effective.

Software delivery is a useful example because the process is full of artifacts created to move context between people. For decades, teams have used user stories, acceptance criteria, specifications and review documents to translate business stakeholders’ intent into requirements for analysts, developers, testers and approvers.

Now agents are entering that flow, where every artifact either helps the agent do the work, helps humans review the work, or adds friction.

I’ve seen teams spend weeks rewriting a specification document by hand to match the format human reviewers expected, even though the agent had already produced a correct, working solution from the original ticket. The rewrite did not help the agent deliver the solution, and it did not make approval meaningfully faster. It simply added weeks of cost to satisfy an artifact the agent never used.

The team assumed the specification was required because the current process treated it as required. That mistake isn’t limited to documents written for people. In a recent peer-reviewed study, researchers tested whether giving coding agents extra repository-specific instructions improved their success on real tasks. Across several leading agent and model combinations, the added instructions increased computation cost by 20% or more, yet success rates fell in most of the settings where the instructions were AI-generated rather than written by the repository’s own developers.

An agent can use an artifact that doesn’t help it. What matters is whether producing those artifacts improves the agent’s next action.

Some artifacts move the work forward. They clarify intent, expose constraints, capture decisions or preserve context the agent needs to act correctly. Others are projection layers: artifacts that are created so humans can inspect, approve or feel comfortable with work that may already be complete. Those artifacts may still serve a governance purpose, but they should not be mistaken for inputs the agent needs.

Before redesigning an artifact, ask what job it performs. Does it help the agent decide, build, compare, validate or recover? Or, does it translate the agent’s work back into a familiar human format after the useful work has already happened? That distinction tells you more about the process changes you need than a theoretical future-state diagram.

A pilot should not only tell you whether the agent can do the work. It should show which surrounding artifacts improve the work, which help people inspect and govern the work, and which exist mainly because the current process produces them.

Give the agent work with incomplete inputs, exceptions and decisions that require judgment. A demo can show capability, but real work shows what the agent uses, where it struggles and where the surrounding process adds or removes friction.

For every ticket, specification, review document, checklist or status artifact, apply that test: Did it help the agent’s next action? Also ask whether it helped the agent produce it only because the team produces that deliverable today.

Some artifacts do not help the agent act, but they help humans inspect the agent’s work, approve outcomes, meet compliance expectations or create an audit trail. Keep those artifacts when they serve that purpose, but name them for what they are: evidence for human governance, not necessarily inputs for agent performance.

Some review steps exist because leaders do not yet trust the agent or cannot see enough of its internal process. That may be reasonable early on, but it should not automatically become a permanent process design. As evidence grows, decide which checks are still necessary, and which are compensating controls for unfamiliar technology.

Preserve the artifacts that improve the agent’s next action. Keep the evidence humans need for judgment, accountability, compliance or approval. Challenge everything else, especially deliverables that survive only because the old process made people produce them.

If agents are going to reshape how work gets done, organizations should redesign aggressively. But redesign should not start by translating today’s process into agent-friendly formats.

Meet the agent in the work first, then decide what to preserve, what to govern and what to stop producing.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?