In Issue 28, we talked about what happens when enterprises try to deploy AI agents into processes that still carry process and data debt. More often than not, they stall or fail. Agents do not navigate ambiguity well and cannot make judgment calls with unstructured process and data.  Can they ask for clarification when something unexpected happens? Perhaps, but they need legibility, documented rules, and relatively clean data.

In this article, I have collaborated with Rishi Choudhary from Covasant who has added context to the narrative with real examples of how to do this with their Covasant Agent Management Suite (CAMS).

The Sequence That Works for Success

Start by mapping your processes, documenting the rules, and identifying where data quality breaks down. Understanding where the time goes comes from that work. While unglamorous, it is the prerequisite for everything that comes next. Depending on the size and complexity of your operation, this will likely take three to six months.

Next, pick one or two high-volume processes where you have paid down the debt and have clean data flowing through documented procedures, and then run an agent through it. Measure the outcomes, and prove the model works in your specific context. This step will likely take two to three months.

Now comes the acceleration by deploying agents across similar processes. This is where value starts to compound and ROI gets measured. Organizations that skip these steps encounter undocumented exceptions, bad data, and systems that do not integrate.

Agent Orchestration

The best deployments use agents within an orchestrated operating model where the agent handles documented, rules-heavy work while humans handle high level exceptions or white glove customers that require more rigorous judgement.

Remember that you are not necessarily replacing the process, but  documenting it clearly enough that an agent can execute the predictable parts and route everything else to a human.

Rishi: An orchestration model only holds if the agent’s boundary is enforced at runtime rather than hard-coded into each agent. In Covasant CAMS, every agent is registered with an owner, an environment, and an explicit scope of systems it is allowed to reach. In addition, CAMS ‘Control Tower’ monitors that boundary live against policy. When an agent meets work outside its documented path it stops at the edge of its scope and surfaces there and then, instead of improvising and being discovered in a log a week later. That’s the difference between an enterprise agent operating model and a pilot that happens to be running in production.

The agent needs to log what it is doing, explain its decisions, and hand work off to humans when confidence levels drop. It needs to connect to your systems without custom integration work and measure outcomes in real time so you can see what is happening.

Rishi: Attribution breaks when the agent’s ‘record’ and the business ‘record’ sit in different places. CAMS tracks activity and cost per agent and per call, so you know what the agent consumed and what it actually did – and that’s the half most teams never builds. The other half, cycle time and exception rate, lives in your ERP and case systems. Capture that baseline before the agent goes in, because a before-and-after you can audit is worth more than any projected ROI number.

Good vendors build all of this into the foundation and give you visibility into the agent’s work, continuous measurement, and the ability to turn it off if something goes wrong.

The Operating Model Shift

Deploying an agent correctly changes your operating model fundamentally. Work that three people did becomes one person plus an agent and cycle time that used to be days becomes hours.Your baseline is now entirely different.

You only get those outcomes if you paid down the debt first. If you did not, you are automating the workarounds and scaling the problems.

What Comes After Your First Domain

Once you have proven the model on one process, the next question is which domain to tackle second. This is another area where organizations can either accelerate or stall.

The right second domain is not always the most obvious one. It is the one that creates a compounding effect, as some processes depend on outputs from other processes. Some share the same data sources and in some cases, use the same systems. If you sequence correctly, the debt paydown you did for domain one reduces the work needed for domain two. This will increasingly become the case as you progress.

The organizations that scale quickly are not the ones that deploy agents across a certain amount of domains. They are the ones that chose three domains where the sequencing meant each one got progressively easier as they moved forward.