Foundation models are available to everyone. Developer tools are better than ever. So why would an enterprise legal team buy an agentic legal service when they could, in theory, build one themselves?
The argument for building in-house has never been stronger on the surface. Foundation models from OpenAI, Anthropic, and Google are commercially available via API. Agent frameworks like LangChain, CrewAI, and AutoGen lower the barrier to prototyping. Your engineering team can have a working demo in a week.
And the instinct is understandable. If the core technology is commoditised, why pay a vendor margin? If your legal team's playbooks are proprietary, who better to encode them than your own engineers? If data sovereignty matters, why send contracts to a third party when you could keep everything on your own infrastructure?
These are reasonable questions. The answers are more nuanced than either side of the buy-vs-build debate typically admits. Some organisations should build. Most should not, and for reasons that are not obvious until you have tried.
This piece is not a sales argument. It is an honest accounting of what building an agentic legal system actually requires, drawn from what we have observed in the market over the past two years. The goal is to help enterprise legal leaders make the decision with clear eyes, whichever way they land.
The most dangerous moment in any build-vs-buy evaluation is the internal demo. An engineer spends a week connecting a foundation model to a document parser, adds some prompt templates, and shows the GC a working NDA review. It looks impressive. The GC thinks: we are 80% of the way there.
They are not. They are perhaps 10% of the way there, and the remaining 90% is where every internal build project either stalls or quietly becomes a full-time engineering commitment that nobody budgeted for.
The gap between demo and production is not a matter of polish. It is a fundamentally different category of work. The demo asks "can AI do this task?" The product asks "can AI do this task reliably, at scale, on every document format, with appropriate supervision, in a way that your legal team trusts enough to let it interact with the business unsupervised?"
An agentic legal system is not one thing. It is at least seven distinct engineering challenges, each of which requires specialist knowledge that most enterprise engineering teams do not have in-house.
Most enterprise legal teams that attempt to build estimate the initial project at 2 to 3 engineers for 3 to 6 months. The reality, based on what we have observed in the market, is closer to 4 to 6 engineers for 12 to 18 months to reach production quality, followed by 2 to 3 engineers permanently for maintenance and iteration. At fully loaded costs of £120 to 180K per engineer, the annual commitment is £500K to £1M before the system processes a single contract.
The conversation about build-vs-buy tends to focus on engineering capability. Can our team build it? Do we have the right skills? These are the wrong questions. The harder problem is not building the technology. It is encoding the legal expertise.
An agentic legal system does not run on code alone. It runs on playbooks: the institutional knowledge of how your legal team handles each type of work. What your preferred NDA terms are. When to accept a counterparty's liability cap and when to push back. Which jurisdictions require specific clauses. How to triage a request that falls between two categories.
This knowledge typically lives in the heads of your most experienced lawyers. Getting it out of their heads and into a format that an AI system can use is a translation exercise that requires someone who speaks both languages. The lawyers know the rules but cannot express them as structured logic. The engineers can build the structure but do not understand the legal nuance.
Vendors who have built agentic legal systems have spent years developing this translation capability. They have legal engineers, supervision teams, and playbook frameworks that have been refined across dozens of enterprise deployments. An internal build starts from zero on this dimension, and it is the dimension that determines whether the system's output is trustworthy.
Despite everything above, there are situations where building internally is the right decision. It is worth being honest about when that is the case.
If all four of these conditions are met, building internally may be the right path. If any are missing, the probability of a successful build drops significantly. The most common failure mode is having conditions one and two but not three: an engineering team that can build a prototype, a narrow initial scope, but no long-term commitment to maintaining and expanding the system. The prototype ships, works for six months, and then slowly degrades as models change and nobody is assigned to keep it current.
| Dimension | Build internally | Buy from a vendor |
|---|---|---|
| Time to production | 12 to 18 months (typical) | 2 to 6 weeks |
| Upfront cost | £500K to £1M+ (engineering team) | Variable, per-unit or subscription |
| Ongoing cost | £300K to £600K/year (maintenance team) | Included in service fee |
| Legal expertise | Must build internally or hire | Included (supervision, playbook frameworks) |
| Model management | Your team manages updates, drift, fallbacks | Vendor manages model layer |
| Security posture | You control everything | Depends on vendor (look for single-tenant, SOC 2 Type II) |
| Customisation | Unlimited (you built it) | Varies by vendor (playbook-configurable vs. generic) |
| Opportunity cost | Engineering team not working on core product | None (no internal engineering required) |
| Risk if it fails | Sunk cost, team reallocation | Cancel the contract |
If you are a GC or Head of Legal Ops weighing this decision, here is a framework that cuts through the theoretical arguments.
1. Do we have engineers with production LLM experience who are available for 18+ months? If no, buy. Internal builds without experienced LLM engineers fail predictably.
2. Is our CTO willing to own this system permanently? If the answer is "we'll build it and hand it to legal ops," buy. Systems without engineering ownership degrade.
3. Can we wait 12 to 18 months for production quality? If the backlog is urgent and growing, the opportunity cost of waiting for an internal build may exceed the cost of buying.
These questions are deliberately practical. They do not ask about vision or strategy. They ask about resources, ownership, and urgency. The answers tend to be clarifying.
For most enterprise legal teams, the honest answers are: no dedicated LLM engineers, no CTO commitment to permanent ownership, and an urgent capacity problem that cannot wait 18 months. In that case, the buy decision is not about capability. It is about pragmatism.
For the smaller number of organisations with genuine engineering depth, strategic commitment, and patience, building is a legitimate path. The key is entering that path with realistic expectations about what it costs, how long it takes, and what it requires to maintain.