The two kinds of AI a plaintiff firm needs

Firms shop for “legal AI” as though it were one category. It is two, they fail in opposite ways, and buying one expecting it to solve the other is the most common expensive mistake in this market.

A managing partner asks for a demo of “legal AI” and means one of two completely different things, usually without realising there is a choice. The confusion is understandable — everything in this market is sold under the same two words — and it is expensive, because the two categories fail in opposite directions and no single product is good at both.

The first kind: the work around the case

This is everything that happens before a matter is a matter, and everything that happens alongside it that is not legal work. A prospective client calls at 7pm and gets voicemail. A signed-up client rings for the fourth time this month asking whether anything has happened. Records requests go out and nobody follows up for three weeks. Someone retypes the same intake details into the case management system, the calendar and the billing tool.

None of that requires legal judgement. All of it costs money — the after-hours caller signs with whoever picks up, and the status-update calls eat the day of the person least able to spare it.

The tooling here is voice agents, intake automation, client portals, reminder sequences and integrations between systems that should already talk to each other. It is closer to operations engineering than to law, which is why it is usually built by automation shops that specialise in professional practices rather than by legal software vendors.

The measure of success is throughput and response time. Did every call get answered. How fast did a new lead hear back. How many “any update?” calls stopped happening.

The second kind: the work inside the case

This is reading the three thousand pages of medical records, working out that the treatment gap is four months rather than the two the intake form claimed, noticing that the termination letter says restructuring while a recording says the role was refilled, and drafting a demand that survives contact with the other side.

This is legal judgement supported by evidence. The tooling is document reading, fact extraction with citations, chronology building and drafting that can be traced back to the record.

The measure of success is not speed. It is whether every assertion in the output can be traced to a page in the file.

Why they fail in opposite directions

This is the part worth internalising, because it explains why one product cannot sensibly be both.

• Front-office AI fails by being slow or absent. A voice agent that misses a call costs you a case you never had. Nobody is harmed by an enthusiastic scheduling confirmation.
• Case-work AI fails by being confidently wrong. A demand letter asserting a date the record does not support costs you credibility in a case you already have, in front of someone paid to find exactly that.

Those failure modes pull the engineering in opposite directions. A system optimised for never missing a caller is tuned to always produce an answer. A system that always produces an answer is precisely what you do not want reading a medical file, because when the record is silent it will fill the gap with something plausible.

A tool built to be responsive and a tool built to be checkable are making opposite bets about what to do when they are uncertain. That is a design decision taken early and it runs through everything after it.

Which one to buy first

A rough test, and it is about where your firm is leaking rather than which technology is more interesting:

• If you are losing cases you never signed — missed calls, slow callbacks, intake that takes three days — the front office is the bottleneck. Nothing that happens to a case file matters if the client signed with someone else on Tuesday.
• If you are signing plenty and the backlog is in the work — demands taking weeks, records nobody has read, associates buried in files — the constraint is inside the case.

Most firms know which one they are without needing a consultant to tell them. The failure is buying the wrong one because it demoed well, then concluding that AI does not work for law firms.

A note on vendors who claim both

Some will tell you they do the whole picture. Ask a specific question: when your system cannot find something in the record, what does it output? If the answer involves the word “seamless”, you are talking to the front-office product. The case-work answer is unglamorous — it says the record is silent and shows you where it looked.

There is nothing wrong with running both. There is something wrong with buying one and expecting it to cover the other, which is how firms end up with an automated intake system drafting demand letters nobody checked.

Where we sit

Luma is squarely the second kind. We read the file, extract facts with a citation to the page, and draft from those facts — and when the record does not say something, we say so rather than filling the gap. We do not answer your phones, and a vendor who does that well is not our competitor.