There’s a word that’s become common in conversations about legal AI without ever quite getting explained: “wrapper.” It shows up as a criticism, usually leveled at one product by a competitor, or as a worry legal buyers voice without being totally sure what they’re worried about. It’s worth actually defining, because once you understand what a wrapper is — technically, not as a buzzword — the rest of the purpose-built-versus-generic conversation stops being an abstract debate about quality and becomes a straightforward, almost mechanical question about what a piece of software was actually designed to do.
A wrapper, in the plainest possible terms, is an interface built on top of someone else’s general-purpose AI model. The underlying model — the thing actually generating text — is the same foundation model available to any developer, trained on a broad slice of the internet to be reasonably good at everything: emails, code, poetry, contracts, casual conversation. A wrapper doesn’t change that underlying model. It adds a layer on top: a legal-sounding interface, a set of prompts engineered to nudge the model toward legal-style output, maybe some formatting and templates that make the result look like a legal work product. The model underneath is still the same general-purpose engine, doing the same thing it would do if you asked it to write a cover letter or summarize a novel. It’s just been asked, through clever instructions, to produce something that resembles legal writing.
This matters more than it sounds like it should, because it determines where the ceiling is. Prompt engineering — the practice of writing very careful, very specific instructions to get better output from a general model — is a genuinely useful skill, and it can meaningfully improve what comes out of a wrapper. But it operates entirely within the boundaries of what the underlying model already knows and can do. No amount of clever prompting can make a general-purpose model aware of an organization’s actual filing history if that history was never part of what the model was trained on or given access to. No prompt can teach the model jurisdiction-specific procedural nuance it was never exposed to in a structured way — the best a prompt can do is ask the model to try to sound like it’s accounting for that, which produces text that reads as though it accounts for it, whether or not it actually does. This is the core problem with a wrapper: it can shape the style of the output, but it cannot deepen the substance, because the substance was fixed the moment the underlying model finished training.
A purpose-built platform is solving a different problem, starting from a different place. Instead of layering instructions on top of a general model and hoping the output lands close enough to what legal work actually requires, a purpose-built system is built around the structure of legal work itself — trained on and connected to an organization’s own filings, defense history, and jurisdictional patterns, with the workflow itself (intake, analysis, drafting, review) built into the architecture rather than simulated through a prompt. The difference isn’t a matter of degree — a slightly better wrapper versus a slightly worse one. It’s a difference in what kind of problem the software was actually built to solve. A wrapper is trying to make a generalist sound like a specialist. A purpose-built platform is a specialist to begin with.
It’s worth being fair about what wrappers are genuinely good at, because the criticism isn’t that they’re useless — it’s that they’re being used for the wrong category of task. A wrapper built on a strong general-purpose model can be a perfectly reasonable tool for brainstorming, for a first pass at plain-language explanation, for tasks where the value is fluency and speed rather than institutional precision. The problem arises specifically when a wrapper is marketed and sold as a solution to the deeper, more specific problems legal teams actually have — jurisdictional consistency, institutional memory, defensible repeatability across hundreds of similar matters — because those are exactly the problems a thin interface layer was never built to solve, no matter how good the prompts behind it are.
This is also where the “prompt engineering” conversation tends to mislead buyers, often unintentionally. It’s genuinely possible to demo a well-prompted wrapper and have it look impressive — a clean, plausible, legal-sounding draft, produced quickly, in response to a well-chosen example document. What that demo can’t show you is what happens on document four hundred, when the pattern the organization actually needs the tool to recognize isn’t something a prompt can inject on the fly — it’s something the system needs to have been built to hold onto from the start. A wrapper has no persistent, structural memory of the organization’s own history unless someone manually re-supplies it every time, which defeats the entire purpose of automation. A purpose-built platform is designed to carry that institutional knowledge forward automatically, because carrying it forward was part of the actual design brief, not an afterthought bolted on with a clever instruction.
None of this is a reason to distrust AI in legal work broadly — it’s a reason to ask a more specific question before adopting any given tool: was this actually built for what I need it to do, or was it built to do something else and then dressed up to look like it fits? That question doesn’t require a technical background to ask, and it’s the one that actually separates the two categories of product, regardless of how similar their marketing pages look or how similar their outputs seem in a five-minute demo. The wrapper problem isn’t that these tools are dishonest. It’s that a thin layer over a general engine can only ever be as deep as the layer, and legal work — jurisdictionally specific, institutionally grounded, repeated at volume — needs something with actual depth underneath it.
