Migrating your existing business system to agents — without a rewrite

The most common mistake in agent migration is treating it as a platform replacement. Your existing system — the ERP, the CRM, the spreadsheet everyone actually uses, the twelve-year-old internal tool — stays. Agents get added in front of it, take over specific workflows, and are measured against how those workflows run today.

Start from workflows, not systems

List the work, not the software. For each item write down volume, cycle time, who does it, what a correct outcome is, and what the worst realistic failure costs. Rank by volume times tedium, then filter out anything where a single mistake is unrecoverable and unmonitored.

What survives that filter is your migration backlog. In most businesses the first three items are intake and classification, cross-system reconciliation, and follow-up chasing — precisely because they are high volume, well defined, and currently done by someone who would rather not be doing them.

The integration reality

The question people ask first is whether agents work with the tools they already have. Usually yes: the agent calls the same APIs your staff's screens call, under a scoped identity of its own. The real constraints are narrower and worth checking early.

Some systems have no API for the step you care about. Some have one but no sandbox, so you cannot test safely. Some enforce per-user licensing that makes a machine identity awkward. Where an API is genuinely missing, the honest design is an explicit human step rather than screen automation that breaks on the next UI change.

Legacy data is the other constraint. Agents inherit whatever inconsistency your records already carry, and retrieval over messy documents produces confidently wrong answers. Cleaning the slice of data one workflow depends on is usually cheaper than a full data programme and is often the highest-return part of the migration.

A staged path that does not stall

Stage one: shadow. The agent runs on real inputs and proposes outcomes, but nothing it produces reaches a customer or a system of record. You compare its output against what your team actually did. This is the only cheap way to find out whether it is good enough.

Stage two: draft and approve. The agent's output becomes the starting point a person reviews and sends. Cycle time drops immediately, and the approval rate tells you exactly when the next stage is safe.

Stage three: bounded autonomy. Where accuracy is proven, the agent acts on its own inside limits — value thresholds, record types, working hours — and escalates everything outside them. Anything that writes, sends, or spends keeps an audit trail.

Stage four: the next workflow. Reuse the identity model, the tool layer, the evaluation harness, and the monitoring. This is where the earlier investment pays off, and it is why prototype-shaped agents are expensive at this point — see the limits of vibe-coded agents.

What to keep human on purpose

Exceptions, escalations, negotiation, and anything a regulator or customer would want a named person accountable for. Agents should make those cases arrive faster and better prepared, not decide them. Written down as policy rather than left implicit, this is also what makes the migration defensible internally.

Measuring the migration

Track the same five numbers per workflow before and after: completion rate, human intervention rate, cycle time, cost per task, and escalation quality. If a workflow does not move at least two of them, roll it back and move to the next item on the backlog. A migration that can be rolled back is one people will actually let you run.

The engagement shapes for this — audit, one production workflow, then platform — are on the AI agents services page. If you want the workflow audit first, take the free readiness scan or bring your backlog to a scoping call.