UiPath agentic automation: 100,000 cases a week

At a vendor event in Las Vegas, Coronis Health CTO Doug Marcey gave a number that does not sound like marketing: after IDP went live, the average time to process a medical record fell by about 30 seconds. On that figure alone the investment does not look like it pays. The second half of the same answer is the part worth keeping — the standard deviation tightened sharply, and the cases that used to run ten times the average disappeared.

The company processes roughly 100,000 billing cases a week, about 60,000 documents of them on the anesthesia line. Unpacking how it works yields three things worth moving: tiered routing by input complexity, acceptance on variance instead of mean, and a cost decision that runs against the cloud narrative. All three circle one question — what belongs in the denominator of unit cost.

1. The real constraint: 154 EMRs and no shared format

Start with scale. The company serves 700 clients and connects to 154 EMR systems and more than 25 practice management systems, at roughly 100,000 cases a week. Anesthesia is both the hardest and the most valuable line at about 60,000 documents a week.

Now the constraint. By the CTO’s account, 50% to 75% of medical billing should be straight-through work, and the hard part sits with the payer rather than the data entry. At the same time, 14% to 20% of anesthesia records are still handwritten, which IDP cannot process at all.

Together those numbers mean this is less a volume story than a distribution story. A hundred and fifty-four EMRs means no shared data structure: the same clinical record carries different fields, codes and layouts depending on which system produced it. Any plan built on one model handling everything hits the same wall here. Whether the model is good enough is the secondary question; the variance of how dirty the input is comes first.

2. Four tiers: deterministic paths first, tokens only at the hard end

The approach runs a self-trained classification model over each record first, then routes it by complexity and mess into one of four tiers. Tier one is Apple’s built-in OCR running on Mac Studio hardware, which the company measured at about 30 pages per second against roughly 3 pages per second for Poppler. Tier two is standard IDP plus Tesseract. Tier three uses open-source OCR models. Only tier four hands the hardest records to a commercial vision-language model running on the company’s own hardware. The whole chain uses UiPath IDP and Action Center for human correction.

The mechanism is worth stating on its own. The cost function is tiered. The first three tiers run on fixed-cost hardware, priced per page and consuming no tokens; only the fourth enters metered pricing. Keeping most records off the token meter is what actually changes the slope of the bill. Optimising the price per token without changing the distribution of the traffic leaves you with the same slope on a cheaper unit.

That also explains why tier four runs on hardware the company owns. Once unit cost is predictable, floating metered pricing loses most of its appeal. The inverse is the boundary condition: if the hardest tier carries a large share of the volume, tiered routing gives up much of its return.

Provenance belongs here. These figures are a customer account delivered at a vendor event, and diginomica discloses in the piece that UiPath and Oracle are its premier partners and that UiPath covered the reporter’s travel and accommodation for the event. Anything phrased as “the platform delivers X” should therefore be read as a customer self-report inside a sponsorship relationship, not a third-party evaluation. The 30 versus 3 pages per second comparison is the company’s own test with no disclosed conditions, and it is not a benchmark.

3. Why “30 seconds faster on average” misreads the case

The mean answers one question: how much faster the average record became. Rostering, SLAs and customer quotes consume something else — how many people you have to put on next month. What decides that is the distribution, not the mean.

This is the easiest place to read the case backwards. Quote only the 30 seconds and the conclusion is that IDP barely did anything. Add the second half — the deviation tightening, the extreme cases gone — and the conclusion flips to capacity that can be promised for the first time. The two halves have to travel together; either one alone turns the case into an advertisement or a cautionary tale.

The transferable rule is one sentence long. Write automation acceptance as a pair: mean plus standard deviation, or put P95 in the contract. It costs almost nothing to add, and it decides whether the project survives its second budget: operations needs a number it can roster against, not a flattering average.

The boundary: this is a single case with self-reported metrics, and it does not cover automation whose value shows up mainly as headcount reduction, where the language of acceptance is different from the start.

4. “AI pulled us back to colocation”

To escape floating per-token cost, the company made a decision that runs against the industry narrative: it moved from full cloud back to colocation, bought hardware, and turned unit cost into a fixed cost. The CTO’s phrasing was that AI pulled them back to colocation.

From first principles, this is not a cloud-versus-own-hardware price question. It is a question about who carries volatility. Per-token pricing leaves the risk of traffic swings with the buyer: more usage costs more, and the unit price is not yours to set. Owning hardware moves the risk to the other side; idle capacity is a cost, and scaling beyond forecast is slower.

Which is better depends on how predictable the load is. A steady load of 100,000 cases a week with a known distribution suits fixed cost, because its swings can be planned for. A small, fast-growing load with unpredictable spikes turns fixed cost into sunk cost. So the value of this piece of first-hand evidence is not that owning hardware is cheaper. It is that the default assumption of AI being inherently cheaper does not survive contact with a metered bill — and that most contracts never state who carries the volatility.

5. The under-rated gain: labour that moves between 154 systems

Before the integration layer, staff were bound to specific EMR systems and could not be scheduled across teams. After the common adaptation layer went live, labour could move between systems, and the CTO called that the single biggest operational gain from the platform.

That gain deserves its own line because it does not appear in the usual acceptance arithmetic. Measured in hours saved, labour mobility scores zero. Yet labour locked inside heterogeneous systems is a hidden cost item: one team queues while another idles, and you cannot move anyone across.

This is also why building the adaptation layer first beats adding agents. Without a common connector layer, every new agent maintains its own connection, and the estate gets stiffer with each addition. With the layer in place, adding automation means adding one more worker to the same pool.

The boundary again: this ranking is the CTO’s, not our measurement, and we have no independent quantification of the scheduling gain.

6. Our position

First, pick the denominator before the tool. Per-token accounting rewards using less model. Per-closed-case accounting pushes you toward routing. The first is cost cutting, the second is capacity, and on a budget sheet the two look identical while behaving nothing alike.

Second, acceptance has to carry variance. A mean-only improvement still leaves operations unable to forecast, and unstable is the word that gets the project cancelled in year two. Mean plus standard deviation is the language that can be promised.

Third, build the adaptation layer before counting agents. Spreading agents across heterogeneous systems makes each one maintain its own connector and reduces scheduling flexibility. Put them behind one adaptation layer and each new automation becomes incremental.

Fourth, fixed versus floating cost is an architecture decision, not a finance footnote. Where load is predictable and large enough, owned hardware flattens unit cost; where load is unpredictable, it becomes sunk cost. Acting on that requires answering one question first: can you draw next year’s load distribution in advance?

7. Limits and uncertainty

• Every figure in the case comes from the Coronis Health CTO speaking at UiPath Fusion 2026, reported by diginomica, which disclosed its sponsorship relationship with UiPath.
• The 30 versus 3 pages per second comparison is the company’s own test with undisclosed conditions and is not an OCR benchmark.
• The article contains no dollar-denominated return and cannot substitute for the company’s financials.
• A single case does not generalise into an industry baseline; tier thresholds have to be recalibrated against your own input distribution.
• The ranking of the labour-mobility gain is the interviewee’s, not our own measurement.

8. Three steps you can copy

One: list your deterministic paths. Which steps need no cognition, such as format conversion, field extraction and rule validation. Pin those to fixed-cost hardware rather than sending them to a metered model.

Two: define the criteria for the hardest tier. Run a discriminator over inputs first and only let the high-complexity tier reach the token-metered path. The criteria should be a reproducible rule, not an operator’s judgement call.

Three: write acceptance as a pair — mean plus standard deviation, or P95 — into the pilot contract. It costs next to nothing and it decides whether you can produce a rosterable number next year.

All three replace how much did we save with what does each closed record cost and how much does that wobble. The first is a feeling. The second is a quantity that can enter a budget process.

References: diginomica, “Accountable intelligence: how a UiPath customer is using agentic automation to process 100,000 medical cases a week” (2026-09-25; Mark Chillingworth interviewing Coronis Health CTO Doug Marcey at UiPath Fusion 2026; the piece discloses the outlet’s premier partner relationship with UiPath) diginomica.com/accountable-intelligence-how-uipath-customer-using-agentic-automation-process-100000-medical