Part one of two: the case.
Once upon a time, in a pub, a wise man told me he had an idea for a business. What if a few clients, a handful of large enterprises, came together and built a law firm of their own? It struck me as intriguing, and in many industries almost certainly unworkable. But there was something in it.
There is a problem with big legal tech. Subscribe to Legora or Harvey and you have taken on yet another software vendor, the sort that venture capital loves for its ARR and that parts of the internet write off as a mere wrapper. Both views are true at once. And yet the products are genuinely useful. Whatever one makes of the economics, what you are buying is a good set of tools and an enterprise-grade promise that it will all simply work: you click a button, you log in, and the system runs. You are paying for the wrapper, and for the peace of mind that comes with it. What's not to like?
The story of wrappers
Imagine that the engine of a car can only be built by a handful of manufacturers, and that everyone, in the end, buys their engine from one of them. Before long those same manufacturers start building cars of their own, and the cars are good: versatile, capable, happy to turn their hand to almost anything. Alongside them sit the specialists who build something closer to a race car. Those machines are quick and beautifully engineered, though never quite Formula One, and they cost a great deal. The trouble for the specialists is that the big manufacturers keep refining their ordinary cars until they can hold their own on the same track, especially once you add the right extra, and the extras, as it turns out, increasingly come free.
The specialists are also building on someone else's engine. There is nothing sinister in that, but it leaves a gap, and into the gap step the enthusiasts, who modify their cars to do exactly what they need. It begins modestly, a spoiler here, a remap there, and grows into something far more serious, until a whole community is quietly building machines made for their own particular road.
Beyond the enthusiasts, though, sit businesses with rather deeper pockets, and they are building machines of their own. Kirkland & Ellis, the highest-grossing law firm in the world, has committed half a billion dollars to building its own AI and brought in Palantir to build part of it. Underneath, it is still the same engine, tweaked here and there, perhaps even fine-tuned. Probably. What sets it apart is that it is built around Kirkland's own knowledge, rather than bought off the shelf. But Kirkland is building it for Kirkland. That machine serves its work and its clients, not yours.
Let us go back to our wise man. What about everyone else, the in-house legal teams that need these machines too but will never have Kirkland's budget? This is where the opportunity takes shape. He was right about the part that matters: there is a good business here. He was only wrong about its shape, and about who would come together to build it. Law firms compete with one another, and each wants something different, so they could never share one platform. The enterprises are another matter. Their in-house legal teams are not rivals in the same way, and pooling is something they can actually do.
What a community can and can't do
So what is wrong with the community option? Plenty, if you listen to the objections. It is vibe-coded AI slop. What about security? Who is going to maintain it? Most of this answers itself. The parts that genuinely bite are not an open-source problem at all. Confidentiality, privilege, ethical walls, where the data lives, a security review: these land on anyone who ships to lawyers, open or closed. What is genuinely harder in the open is maintenance, because someone still has to look after the software. So how about a business that does precisely that for you?
So picture two things, not one. First, a shared, open core that can move quickly on features, precisely because it is not trying to serve a thousand tenants at once. Second, a business funded by the enterprises that use it. Pooling their demand does two useful things. It gives the open project the backing it needs to become real and credible before it is fully built. And it does something concrete about cost: a single in-house team, however large, is far too small on its own to win a real discount from a model provider, but a business buying for many such teams at once is large enough to negotiate. That coming together is exactly what the wise man was reaching for.
The company's job would be the unglamorous half. It keeps the code to a defined standard, the kind a serious buyer signs off on: recognised security and AI-management certifications, a full audit trail, and real control over what gets merged in. And it runs each enterprise's deployment, with someone standing behind it. The community ships features; the company ships assurance. Speed comes from the one, accountability from the other.
None of this is new. It is how Red Hat built the largest open-source software business in the world. Red Hat did not write Linux. It took something that already existed, open and free, and made it safe to run in a business: packaged, hardened, certified, patched, and backed by real support at 2am. The Linux itself stays free. What you pay for is the assurance, not the code. IBM bought the company for $34 billion.
The parallel is not perfect, in two ways worth naming. Red Hat inherited a mature open project. Here, the underlying legal material exists, but the tools built on top of it for lawyers are still young, so someone has to fund them into being before any network effect can take hold. And Red Hat's assurance, in plain terms, is indemnity and support. It is not a warranty that the software is correct. In law, of all places, that distinction matters.
Which raises the fair objection that in a regulated profession a wrong clause or a leak of privileged data is not a bug, it is negligence, and a richly valued vendor with a contract feels like a safer place to put that risk. The comfort is thinner than it looks. A high valuation is not a balance sheet that pays your claims, and the contract gives the game away: the vendor caps its liability low, often at little more than the fees you have paid, and it will not stand behind the legal outcome. You may have the leverage to push that cap up a little. You will not get any vendor, however large, to take on the risk of a wrong clause. So the risk sits with you either way, rented or funded, and the honest answer is the one the profession has always used for it: insure it, with professional indemnity, technology errors and omissions, and cyber cover. A tool you can see inside, with a full audit trail, is something an insurer can actually price, which is more than can be said for a black box.
The slowest common denominator
The advantage was never only about price. A closed platform serves everyone at once, so on its hardest features it can only move as fast as its most cautious customer will allow. Memory is the clearest example. As of the middle of 2026, neither Harvey nor Legora has shipped general, persistent memory that carries across matters, and both are open about why. The hard part is not remembering things. It is permissioning: keeping the right people in front of the right data, across thousands of organisations, each with its own ethical walls, all at the same time. Building for a single enterprise changes the shape of that problem, not how hard it is. Privilege boundaries and retention rules are just as difficult for an in-house build. That is precisely why a funded business has to solve the governance once and spread the cost, rather than have every in-house team work out confidentiality by hand, under a level of liability that an ordinary software bug never carries. So the open advantage on memory is fit and control. It is not getting the incumbents' hardest problem for free.
Picture the system organised the way a general counsel thinks. Everything sits under a practice area. Each matter is its own unit of memory, with its own tools around it: the playbooks, the redlining, the tabular review, and agents that can fan out into sub-agents to read a data room. All of it runs under a hard cost cap, and hands back a receipt at the end of each session showing exactly what it spent. The same shape extends to litigation, to M&A, and beyond.
And where it runs is a real choice. If your data is allowed to leave the building, you run in the cloud with your own model keys, pointed at a frontier engine, and billed straight through at cost. If it is not allowed to leave, you self-host and air-gap, but it is worth being honest about the trade. The frontier engines cannot be air-gapped, because their weights are not released. So you run open-weight models on your own hardware instead, and those sit a few months behind the frontier on the hardest reasoning. You also need real GPUs and people to run them, which is low to mid five figures a year, not a box in a cupboard.
What you are buying, in the end, is sovereignty on your own terms. That includes setting a floor: a minimum model quality for privileged work, below which the system simply refuses to route. The funded operator handles the hard parts, because even a large in-house team has no business running GPU infrastructure itself. That is what lets the model work across the size range, from leaner teams that could never staff this alone to the largest enterprises, which set the highest bar on security and clear it through a single operator standing behind many of them at once rather than each building alone. The one thing you cannot have is all three at once: frontier quality, pay-as-you-go economics, and cheap sovereignty you own outright. Choosing your tier with your eyes open is part of the pitch.
So what does this cost?
The closed option is not cheap. Legora is reported at around $3,000 per lawyer a year. Across a large team that runs into six and seven figures a year, every year, for software you cannot see inside and do not own. A single Legora seat can cost as much as ten times the most expensive Claude subscription on the market.
The open model changes the shape of the bill, not only its size. The software is free, and because the keys are the firm's own, model usage is billed straight from the provider with no reseller's margin on top. Ordinary work runs perhaps $50 to $100 per lawyer a month. Truly agentic work, the kind that fans out across a data room, burns a good deal more, and there is no sense pretending otherwise.
But this is where the comparison stops being like for like, and it is worth being precise about the word. An agent is not defined by the task it performs. It is defined by the fact that it decides how to perform it. Give it a goal and it plans its own route, picks its own tools, reads what comes back, notices when it has gone wrong and tries again. A routine that runs a fixed sequence over a fixed document type and returns a fixed output is a workflow, however good it is, and putting a new label on it does not change what it does. The number is the tell. Harvey advertises a library of more than five hundred, built and vetted by its own lawyers so that they give consistent results every time, which is a fair description of a template and a poor one of anything that thinks for itself. Nobody has five hundred systems that plan. Anybody can have five hundred templates. Something that genuinely plans needs very few of them, because the entire point of planning is coping with the work nobody wrote a template for.
That is not to say the real thing is absent. Harvey has an agent that takes a stated goal and works out the steps for itself, and Legora has built a whole operating system around one (though I am not clear what a legal OS actually is). The capability is genuine. What it is not is yours. A SaaS agent runs inside the vendor's product: you cannot open it up, change what it does, or run it where your most sensitive data lives, because it runs on their infrastructure and not on yours. An agent that runs on your own stack is a different thing entirely, whether it is built on open frameworks or is a frontier lab's own agent deployed inside your walls. It lives where your systems live, you can wire it into the core, and you can change it at the level of the code. That is not a claim that their agents are fake. It is the difference between renting the use of one and running your own. And because it is yours, every token is visible down to a per-session receipt, so you can see exactly what was spent and send the next job to a cheaper engine. The win is not a magically smaller bill. It is paying cost instead of markup, seeing everything, and running agents that can reach the heart of your systems instead of ones that never will.
On top sits the subscription to the business that maintains the core and runs the deployment. That is where the real cost of production software in a regulated profession lives: security, compliance evidence, support, a human to call, resilience a single server cannot provide. Even for a large team the running cost is a fraction of the closed bill, for something you control and can inspect.
But the seat price was always the wrong yardstick. The number that should frame this is not what you pay Harvey, it is what you pay your outside firms, an eight-figure line on the books for most enterprises of any size. Set against that bill, a platform that brings even a slice of that work back in-house pays for itself many times over. And here is the part the closed vendors can never match: when the spending stops you are not left with a cancelled subscription, you are left with an asset, an investment that keeps working and can grow. As for Kirkland's half a billion, that buys a private knowledge asset at ten-billion-dollar-revenue scale, not a cheaper version of this. The fully-costed numbers, broken down by the kind of enterprise writing the cheque, belong in the playbook.
Single point of failure
The objection that really decides this is not price. It is depending on a single company. Buy the closed product and that is exactly what you have done: you rely, completely, on one vendor that can be acquired, raise its prices, drop the feature you depend on, or fail outright, and you have no way out.
This model removes that, because the code is open and nobody can lock you in. If the company that maintains and runs it stops serving you well, you have choices the closed vendor never offers. The clients fund it, so they can reform it from the inside. Or they can replace it outright and hand the work to another provider, because keeping open-source software running is a mature business in its own right, with no shortage of firms that do it, and the code goes with you.
You are no longer betting everything on one company staying alive, honest, and on your side.
The wrong metric
The whole industry now runs on a metric that tells you almost nothing: active users. The dashboards have grown clever, daily and monthly actives, depth scores, hours saved, benchmarks against a thousand other deployments, but they all answer the same question, which is how many people opened the thing, and that question exists largely to justify the bill at renewal. It also quietly flatters the seller. On a flat per-seat model, a wide base of light users is not a cost, it is the margin: the lawyer who runs a few queries a day pays for a whole seat and uses a sliver of it, and the more shallow-but-active users there are, the better the economics look. A metered model ends that. Light users pay for what they use, and the gap the vendor was banking disappears.
But the deeper problem is that usage was never the thing to measure. The question is whether the work actually got better: faster, more reliable, cheaper to deliver. No dashboard answers that, and neither does a consultant or a course. Harvey and CoCounsel will run training all day, but they cannot sit inside your team and change how it works. McKinsey and Accenture will sell you a transformation, at McKinsey and Accenture prices.
There is a better answer, and it is beginning to form. A community is taking shape of people who can both practise law and build: lawyers who write code, Claude Certified Architects, software engineers and startup founders, some of them inside the best firms, all of them willing to get their hands dirty. The business the enterprises fund can pull that community in and put it to work alongside the legal team. That is how the work actually changes, and it is the one thing neither the vendors nor the consultants can deliver: not a course, not a deck, but practitioners who build, sitting next to the people doing the job.
Advice as code
There is one more layer, and it is the law itself. Maintaining the platform and changing how a team works is one thing, but not every team has deep expertise in every corner of the law, and not everyone can think like the people who build these tools. When something new lands, a directive like NIS2, the new failure-to-prevent-fraud offence, whatever it happens to be, the usual route is to buy advice. You get a memo, and then you are left to build and run the compliance programme yourself.
But if the people giving the advice can also build, the memo need not be the end of it. If you could hand a team working code instead of a written opinion, you would, and now you can: the advice and the compliance programme arrive together, the expertise itself written as something that runs. The same community delivers it, because those people sit in the top firms and carry the expertise as readily as the ability to build it. This is not an exclusive arrangement. You can still take the question to a firm, get a memo, and sit under the umbrella of its professional indemnity, and nothing here stops you. The difference is what you are left holding: a memo, or a working solution. The solution is the heavier thing to own, because a written opinion is bounded and dated, while running code keeps operating and can fall quietly out of step when the law moves. So it is something you maintain and insure, the same answer as before, rather than something you file and forget. Not every task suits this, but a surprising number do, and the ones that do arrive faster and more usable for it.
Murdering SaaS
Once you are funding this, a great deal of the software an in-house team pays for stops making sense. Think about the stack a legal department runs today: a privacy platform, an e-billing and matter-management system, company-secretarial software, each a separate vendor, a separate silo, a separate renewal. Why keep paying for all of it? Plenty of companies genuinely need those platforms in full. But many pay for a heavyweight system and use a sliver of it. A privacy platform bought to do everything, used as a register of processing activities and nothing more. A matter-management system that costs a fortune, used only to log what the outside firms charge, never even filing in the billing standard it was built around. For a job that narrow, why is there no agent doing it for a fraction of the price? With an open platform and lawyers who build, there can be. The point is not to cram ten systems into one for everyone. It is that the funded company can stand up exactly the capability a given client needs, the narrow replacement where a tool is barely used, and the bespoke thing no vendor sells at all: an EU AI Act assessment tool, an LOA tool, whatever that team genuinely needs rather than the generic version every buyer gets. This is not for everyone, and that is the point.
And this is not legal engineering. It is not engineers approximating the law and hoping it holds. It is lawyers who build, which means the legal substance is real, and the person who understands the obligation is the same person who wrote the code that runs it.
Homegrown
Lawyers who build are not, on their own, enough. Left alone, some of them ship slop, and the best of them build something genuinely good that then becomes a nightmare to keep alive. What changes everything is putting a real business around them. Not a side project, but a proper company with the parts that make software last: a startup core, real engineers, disciplined process, and lawyers who know what a pull request is and how to submit one. Fund that, find the right people, and you have a business that serves you instead of selling to you.
This is where everything in this piece comes together. The open core that moves quickly on features because it was never built for a thousand tenants at once. The funded company that holds it to standard and stands behind it at 2am. The community of builders who sit alongside your team and change how the work is done. Memory and tools shaped to the way you actually practise. Your own keys, your own servers, your own choice of where it all runs. No single vendor you cannot walk away from. Expertise delivered as code rather than a memo. And, quietly, a stack of rented software you no longer need. One business, owned by the people it serves.
And here is what makes it more than a very good services firm with an open-source core. The bespoke work, the builders beside your team, the tool built for one client, is the wedge, and it is what funds the company. But it does not stay bespoke. Each piece hardens back into the shared core, so what was a service for one becomes a feature for all, and the headcount-heavy part that pays the bills today compounds into the product tomorrow. That is the flywheel, and it is how Red Hat turned support into something IBM paid $34 billion for.
And once it serves you, it can scale. What began as a handful of enterprises pooling to solve their own problem is something other enterprises will want too. So you do not just end up with cheaper, better tools. You end up owning the business itself, an asset that could be worth billions. A true unicorn. Homegrown.
Which leaves the only question that matters: who goes first, and what do they do on the Monday morning after they decide? That is the next piece, the playbook.