Most businesses have a person whose real job is moving data between systems that don't talk to each other.
They download a report from one place, reconcile it against another, fix the mismatches, and upload the result somewhere else. It's not in their job description. It takes half their week. Everyone knows it's absurd and nobody has fixed it, because the last three attempts to automate it broke within a month.
That's the most underrated use of agents in business, and it's the one we get asked about least.
Why the previous automation attempts failed
Traditional automation — a script, an ETL job, an RPA bot — encodes a fixed sequence. It's fast, cheap and deterministic, and it works beautifully until reality intervenes:
- A vendor renames a column in their export
- An invoice arrives as a scanned image instead of a PDF
- A product code has a trailing space
- Two records genuinely match but one spells the company "Pvt Ltd" and the other "Private Limited"
- A date arrives as DD/MM in a file that's always been MM/DD
Every one of these stops a rigid pipeline. And because a stopped pipeline needs a human anyway, the person you were trying to free ends up babysitting the automation and doing the exceptions. That's a worse job than before, which is why these projects get quietly abandoned.
Exceptions aren't rare edge cases. In real business data they're 5–20% of volume, and they're where all the time goes.
What agents change
An agent can reason about the exception instead of stopping at it.
"Private Limited" and "Pvt Ltd" are the same company. A column called inv_dt is probably the invoice date. This scanned image is an invoice and here are the fields. This ₹2 discrepancy is a rounding difference; this ₹2,000 one is not.
That's the whole value. Not replacing the pipeline — handling what the pipeline can't.
The right architecture is both, and this matters:
- Deterministic code does the deterministic work. Reading files, calling APIs, writing records, arithmetic. Never hand this to a model. It's slower, more expensive, and occasionally wrong at things code is never wrong at.
- The agent handles judgement. Fuzzy matching, unfamiliar formats, deciding whether a discrepancy is material, classifying something that doesn't fit.
- Humans handle what the agent flags. Low-confidence matches and anything above a value threshold.
Teams that put the model in charge of the whole pipeline get something slow, expensive and unreliable. Teams that use it only where judgement is needed get something that runs.
Where this pays, concretely
Invoice and PO matching. Match incoming invoices against purchase orders and receipts. Exact matches post automatically; near-matches with explainable differences go to the agent; genuine discrepancies go to a person. This is the single most common high-value case we see in Indian businesses.
Bank and payment reconciliation. Settlement files against your own order records. Fees, partial settlements, refunds and timing differences create mismatches that are tedious but usually resolvable with context.
Master data cleanup. The same customer entered four ways across three systems. Agents are good at proposing merges with reasoning attached; a human confirms.
Vendor onboarding. Documents arrive in whatever format the vendor had. Extract, validate against registries, flag what's missing, chase it.
Inter-system sync with drift. Orders in one system, inventory in another, accounting in a third. An agent that reconciles nightly and explains the differences beats a report nobody reads.
Report assembly. Pulling from five sources into one monthly pack, with the anomalies called out.
The common shape: high volume, several systems, a meaningful exception rate, and a person currently absorbing it.
The rules that keep this safe
Idempotency, non-negotiable. Agents retry. Networks fail mid-run. If running twice can double-post a payment or duplicate a record, you have a serious problem waiting. Every write needs a natural key or a deduplication check. This is the failure that costs real money.
Value thresholds. Auto-resolve below a rupee amount you're comfortable with, escalate above it. Simple, and it caps your worst case.
Dry-run mode. Run it in shadow for two weeks: it decides, it writes nothing, and you compare its decisions against what your team actually did. This is how you find out whether it's right before it can be wrong expensively — and it's the step people skip.
Reversibility. Every write should be undoable, and you should have tested the undo.
A full audit trail. What it did, why, which records, on whose authority. For anything touching financial records this isn't optional — your auditors will ask.
Alert on silence. If the agent processes nothing for a day, someone must be told. Silent failure is the most common way these die: everyone assumes it's running, and three weeks of reconciliation quietly didn't happen.
What to measure
Auto-resolution rate. Share handled without a human. This is the ROI, and it should climb as you feed corrections back.
Accuracy on auto-resolved items. Sample and check. The number that matters most, and the one usually not measured — because by definition nobody looked at those.
Escalation quality. When it escalates, does the human agree it was right to? Too many unnecessary escalations and you've built a queue instead of an automation.
Time to close. How long the process takes end to end, versus before. The number your finance lead cares about.
Exception patterns. Which exceptions recur? Frequent ones should graduate into deterministic rules. The agent's job is the long tail, not the same five cases forever.
That last point is important: a good workflow agent gets simpler over time, because recurring exceptions become code. If yours isn't, nobody is looking at the patterns.
Where it doesn't pay
- Low volume. Under a few hundred items a month, a person with a good spreadsheet wins.
- A clean, stable API on both sides. If the systems genuinely integrate well, write the integration. No judgement needed, no agent needed.
- Exception rate near zero. If your pipeline rarely breaks, you don't have the problem this solves.
- No system of record. If the truth lives in someone's head, there's nothing to reconcile against. Fix that first.
- Nobody owns the outcome. Same as every agent project. If no one acts on escalations, the queue just grows.
How to start
1. Find the person. Ask which team member spends the most time moving data between systems. They'll tell you immediately, and they'll usually be relieved someone asked.
2. Watch the process for a week. Log every exception and how it was resolved. This becomes both your requirements document and your evaluation set.
3. Automate the happy path in plain code. No agent yet. This alone often covers 80% of volume.
4. Add the agent for exceptions only, in dry-run mode, for two weeks.
5. Go live with a low value threshold, then raise it as accuracy holds.
Six to ten weeks for a first workflow, and most of the value shows up at step three.
The honest summary
Workflow agents are the least exciting and most reliably profitable agent use case. Nobody demos invoice reconciliation on stage. But it's real work, currently done by people who'd rather be doing something else, and the ROI is arithmetic rather than aspiration.
Keep the deterministic parts deterministic. Use the agent only where judgement is genuinely required. Run it in shadow before it can act. Make every write idempotent and reversible.
Do that and it runs for years. Skip the shadow run or the idempotency and you'll find out why in a way you won't enjoy.
The human-in-the-loop pattern covers the escalation design in more depth, and the four filters will tell you quickly whether your volume justifies it.
Someone on your team doing this by hand?
We build workflow and reconciliation agents for Indian businesses — invoice matching, settlement reconciliation, master data cleanup, inter-system sync. Including the dry-run period that proves it works before it can touch anything.
Bengaluru-based, working with clients across India and globally.
Get in touch · See our agentic AI work · WhatsApp: +91 9677749648