Automating a workflow with agents: where the efficiency actually comes from

Automating a task is not automating a workflow

Most automation projects start by finding a step an agent can do faster. They save a few minutes on that step and discover the workflow takes exactly as long as before, because the time was never in the step. It was in the hand-offs, the queues and the checks around it.

Localization shows it well. AIDA Agents, the multi-agent system whose research team and implementation I led at DATAmundi, now does most of the translation work, with the results published at EAMT and ACL 2026. The efficiency comes from three places, and none of them is raw speed.

Map it before you touch it

Draw the workflow as it actually runs, with every hand-off and every wait. The map is usually embarrassing, which is the point.

The localization workflow before AIDA Agents was a chain of people and queues: a machine translation, a wait for someone to rate it, post-editing, a wait for review, the review, delivery. Each arrow was a person switching context and each queue was a day. The automated version runs translator agents, a rater, a post-editor and a re-rater in a single pass, with the client’s translation memory, terminology and style injected at every stage, and it returns the result into the CAT tool the linguists already use. The people did not disappear from the map. They moved to the one place where judgment is needed: reviewing the segments the rater’s explainable report flagged, instead of everything.

Where the time went

Measure the workflow, not the step. Three published numbers describe what changed for localization.

On an industrial benchmark of six languages, between 70% and 98% of segments were rated publication-ready by professional linguists with no human intervention. The paper estimates that this corresponds to a 50–70% reduction in post-editing effort. And with terminology constraints, the version published at ACL 2026 reached 99.4% terminology accuracy on the WMT25 terminology task, which is the error class that costs reviewers the most time. All three numbers are published and reproducible, and each links to its paper below.

Keep humans on judgment

The goal is not zero humans. It is humans who only see the cases that need a human, with the information to decide quickly.

Two design choices make that real. The rater produces a report a reviewer can read, with the criteria, the scores and the reasons, so review by exception is possible rather than review by suspicion. And the platform comes in three tiers, so the client chooses per job how much quality to buy for how many model calls, and professional human post-editing remains fully integrable where the contract demands it. Automation that removes the human path is a demo; automation that reserves it for exceptions is a product.

Measure before and after

If you did not measure the workflow before you automated it, you cannot know what you saved, and neither can the person paying for it.

1. Baseline first.Count hand-offs, waiting time, hours per unit and error types on the workflow as it is. Do it before the first agent is written, or the baseline will be argued about forever.
2. Define the unit.A segment, an invoice, a ticket. Every number you report afterwards is per unit, so the unit has to be the same before and after.
3. Automate the repeatable, and only that.Steps with a clear input, a clear output and a check that can be automated. Leave judgment where it is.
4. Put the check inside the loop.A rater, a validation, a reconciliation: the automated step that catches the automated error before a person or a customer does.
5. Route exceptions to people, with context.Give the reviewer the report, not the raw output, and make the exception rate itself a metric.
6. Compare like with like, and label the source.The industrial benchmark compared the same segments across systems. Internal numbers are marked internal; published ones link to the paper.

The receipts

The published numbers and the platform behind them.