The most common way AI enters a law firm is not a procurement decision. It is a smart associate or a curious partner who spends a weekend with Claude or Codex, wires together something that automates a piece of their week, and demos it on Monday. The demo is genuinely impressive. It reads a document, fills a form, drafts an email, moves a record. For a moment it feels like the firm just got a free employee. And then, almost on a schedule, it falls apart. Not because the idea was wrong, but because the three things a firm-wide rollout actually depends on were never there.
The demo was never the hard part
A demo has to work once, for the person who built it, on the example they chose. A firm-wide system has to work a thousand times, for people who did not build it, on the inputs nobody chose. Everything that makes the first easy makes the second hard, and the gap between them is where these projects go to die. Getting a coding agent to do the task in a controlled moment is the fun part and, increasingly, the cheap part. The expensive part is everything after: what it costs to run at volume, whether it holds up on real work, and who keeps it alive.
What usually happens
The life of a lawyer-built automation
The build
A partner or associate wires something clever together with Claude or Codex over a weekend. The demo works. Everyone is excited.
The bill lands
A run that cost pennies in the demo now runs hundreds of times a day. The token and credit charges are large, variable, and impossible to forecast.
It breaks
A client PDF is laid out differently, a portal adds a login step, the model updates. It fails on the messy edge cases a real caseload is made of.
No one owns it
The person who built it bills hours for a living, not maintenance. When it breaks again, it is nobody's job to go find out why.
It quietly dies
The automation gets switched off. The work goes back to the people it was supposed to free. The time and the money are gone.
With Caddi: the same workflow is recorded once and run as deterministic code over APIs. Cost is flat and predictable, there is no UI to break, and Caddi maintains it. There is no owner to assign and nothing to switch off.
Three questions decide whether it survives
Before any automation is worth pushing across a firm, it has to answer three questions, and the honest answer for most weekend builds is a shrug. They are not exotic questions. They are the same ones you would ask before relying on a new hire or a new vendor for anything that touches a client.
1. What does it actually cost to run?
This is the frustration people hit first, and it is visceral. Building with a coding agent is priced by token and by credit, and the meter runs on every step the model takes. In a demo, a run costs pennies and nobody notices. Rolled out, that same run happens hundreds of times a day across matters, and the bill is not just large, it is unpredictable. The cost of a task changes with the size of the document, the number of retries, the model version, and how chatty the agent decides to be that day. You cannot put a variable, five-figure line item that nobody can forecast in front of a management committee and call it a plan.
2. Is it reliable enough to bet the firm on?
A tool that works 95% of the time sounds excellent until you remember what the other 5% is. In a law firm, the failure is not a broken pixel. It is a missed conflict, a wrong number on an invoice, a client email that never went out, a deadline that quietly slipped. Weekend builds are brittle in two compounding ways: the model itself is non-deterministic, so the same input can produce different output, and anything that drives a screen or scrapes a page breaks the moment a vendor moves a button or adds a login step. Neither shows up in the demo. Both show up in production, silently, on exactly the messy inputs a real caseload is made of.
Every bot replays clicks on a screen, so a moved button or new login screen silently breaks it — and someone has to find and fix each one.
One automation, maintained for you
Runs as deterministic code over APIs — no UI to break — and Caddi handles upkeep.
Nothing to triage on your side when an app changes.
3. Who makes sure it gets fixed?
This is the question no one asks at the demo, and it is the one that actually kills the project. The person who built it is a lawyer. Their job is to bill hours, not to babysit a script, monitor a queue, or debug an integration at 9pm because a portal changed overnight. There is no on-call, no owner, no runbook. So the first time it breaks and it is genuinely no one's job to fix it, it stays broken. The firm goes back to doing the work by hand, now with less trust in the whole idea than before it started.
So it dies, and it takes the appetite with it
Put the three together and the ending is predictable. You spend real money on tokens and real hours on the build. It works long enough to raise expectations, breaks often enough to erode them, and belongs to no one long enough to rot. Eventually it is switched off. The worst part is not the wasted spend. It is that the firm concludes “we tried AI and it did not work,” when what actually failed was a weekend build asked to do an operations job it was never structured to hold.
What a firm-wide rollout actually requires
The fix is not to try harder with the same tools. It is to change what you are relying on in production. Cost has to be flat and predictable, not metered per token, so finance can plan around it. Execution has to be deterministic and run over APIs rather than by replaying clicks on a screen, so it produces the same result every time and does not shatter when a UI changes. And maintenance has to be someone's actual job, a vendor's, not a favor an associate does between matters.
That is the entire premise of Caddi. You record a workflow once, the way you would show a new hire, and Caddi turns it into deterministic, API-driven automation with flat pricing that it maintains for you. The demo is not the deliverable. Something that survives the firm is. For the economic case behind starting with operational work rather than legal judgment, see why the business of law is where AI pays off.
Skip the death spiral
See automation built to survive a firm-wide rollout
Tell us where to reach you and the calendar opens right here. In 30 minutes we'll show you how Caddi turns a workflow you record once into deterministic, API-driven automation with flat, predictable cost, maintained for you, so it doesn't quietly die three months in.
Frequently asked questions
Why do the token and credit costs of building with Claude or Codex feel unpredictable?
Because coding agents are priced per token and per credit, and the meter runs on every step the model takes. The cost of a single task moves with the size of the input, the number of retries, the model version, and how much reasoning the agent does. In a one-off demo that variance is invisible because a run costs pennies. Rolled out across a firm, the same task runs hundreds of times a day, so a small per-run swing becomes a large, variable monthly bill no one can forecast. Predictable, flat pricing is what makes a rollout something finance can plan around.
Why isn't a tool built with a coding agent reliable enough to roll out firm-wide?
Two reasons compound. First, large language models are non-deterministic, so the same input can produce different output from one run to the next. Second, anything that drives a screen or scrapes a page breaks the moment a vendor moves a button, changes a layout, or adds a login step. Neither failure shows up in a controlled demo; both show up in production on the messy, real-world inputs that make up an actual caseload. A tool that works 95% of the time is fine for a personal experiment and unacceptable for work where the 5% is a missed conflict, a wrong invoice, or a slipped deadline.
Who maintains AI automation that a lawyer builds in-house?
Usually no one, and that is what kills most in-house builds. The person who built it is a lawyer whose job is to bill hours, not to monitor a queue, watch for failures, or debug an integration when a system changes overnight. There is no on-call, no owner, and no runbook. So the first time it breaks and it is genuinely nobody's job to fix it, it stays broken and the work goes back to being done by hand. For a firm-wide rollout, ongoing maintenance has to be someone's actual responsibility, which in practice means a vendor's, not a favor squeezed between matters.
What does a firm-wide AI rollout actually require?
Three things a weekend build rarely has: cost that is flat and predictable rather than metered per token, so it can be budgeted; execution that is deterministic and runs over APIs rather than by replaying clicks on a screen, so it produces the same result every time and survives UI changes; and maintenance that is a defined responsibility rather than an afterthought. This is the model Caddi is built on: you record a workflow once, Caddi turns it into deterministic API-driven automation with flat pricing, and Caddi maintains it, so the automation survives past the demo.