Product
An Unintegrated Tool Is a Forgotten Tool
There is an adoption rule known to anyone who has deployed enterprise software. Most legal AI vendors underestimate it, and pay for it at scale.
Anyone who has deployed enterprise software knows this rule from experience, to the point of no longer articulating it: a tool that is used is an integrated tool, a tool that is not integrated is a forgotten tool. It owes not to product quality, but to human nature and to that of organizations. People use what is within reach; organizations adopt what fits into what they already do. Everything else ends up, past the initial enthusiasm, on the silent shelf of subscriptions that renew by inertia, paid for and unused.
Legal AI is fully subject to this rule, and most current vendors underestimate it, because they reason in product quality where adoption plays out in displacement cost. They perfect what the tool does once you are inside it, and neglect the only thing that decides whether you go: the fact that you have to go. It is a framing error, and it is paid all the more dearly for being invisible at design time, where the product is judged on its screens, and not on the distance separating the user from those screens.
Why the rule owes to human nature
Before looking at its consequences, one must understand why this rule is so stable, for its stability is what makes it decisive. It does not describe a passing flaw in users that better training would fix; it describes a constant in the way people work under time pressure. Faced with a task, a professional does not choose the objectively superior tool; they choose the nearest one, the one whose use does not force them to interrupt what they are doing.
This preference for the near is not laziness, it is economy. Each move to another tool has an attention cost: you must leave a mental context, load another, then come back. On an isolated task, that cost is bearable; over a whole day made of dozens of micro-tasks, it becomes prohibitive, and the mind, spontaneously, avoids it. This is why the tool that is already there, in the environment where the work happens, almost always wins against the tool that requires a detour, regardless of what each can do.
At the scale of an organization, this individual constant becomes a statistical law. What a motivated user overcomes by discipline, two hundred users under pressure do not overcome on average. A tool’s adoption at scale is not the sum of individual usage decisions; it is the result of a physics of attention, where the near prevails over the far with a regularity nothing contradicts. To ignore this physics is to build a product for an ideal user who exists only in demonstration.
The temptation to be a destination
Many tools have nonetheless chosen to be destinations. They offer a strong interface, a polished experience, specific features, and invite the user to come to them to benefit. This strategy is not absurd: it can work for individual, exploratory use, the curious professional who tests, discovers, has fun, and for whom the displacement is part of the pleasure of discovery. It does not hold at the scale of an organization, because at that scale, the cost is not in the product but in the displacement of attention it requires, multiplied by the number of users and by the number of daily interactions.
This rule has a particular cruelty: it is indifferent to merit. A tool can be objectively better than its competitors, more precise, better designed, and lose anyway, simply because it forces a detour the others do not impose. Conversely, a less brilliant tool perfectly lodged in the workflow will settle in durably. The history of enterprise software is full of superior products beaten by integrated ones. The market does not reward quality in the absolute; it rewards quality accessible without effort.
The best tool you do not open loses to the decent tool already there.
One underestimates how much this observation overturns designers’ usual intuition. One spontaneously builds thinking: if the product is good enough, people will come. The rule says the opposite: however good the product, if you have to come, almost no one will come durably. Merit does not create usage; proximity creates usage, and merit plays only afterward, once proximity is acquired, to decide between equally accessible tools.
To be a destination is to ask every user to come. At scale, almost no one comes durably.
What this rule imposes on the designer
If proximity prevails over merit, then the designer’s work changes nature. It is no longer only about building the best possible product, but about building the product closest to real work, which is a different and often contrary requirement. A product designed to be the best seeks to distinguish itself; a product designed to be the closest seeks to blend in. The two ambitions do not lead to the same decisions, and the second is the only one that holds at scale.
This requirement has a consequence few vendors accept: it forbids reasoning in visible features. A visible feature shows itself, demonstrates itself, sells itself; it flatters the buyer and impresses the committee. A deep integration does not show itself: its success is measured by the fact that nothing is noticed, that the tool seems to have always been there. Building for proximity therefore means accepting to give up part of what makes a fine demonstration, in favor of what makes real adoption. It is a hard trade-off, because it sacrifices the visible to the durable, and the visible is what wins the sale.
One then understands why so many tools nonetheless choose to be destinations: it is easier, faster, more demonstrable. Putting up your own interface costs less than integrating into ten different environments, and it yields a product you can show proudly. The trap is that this design ease is paid in adoption difficulty, and the latter arrives after the sale, when it is too late to fix. The designer saves at build time what the organization will pay at deployment.
The hidden cost of integration
It is this observation that drove a structuring philosophical choice at MAX: not to be a destination. The Legal Semantic Layer lives inside the tools where legal work already happens. In the inbox, because that is where client and opposing solicitations arrive. In the editor, because that is where drafting happens. In the matter system, because that is where work structures itself. In the DMS, because that is where documentary memory lives. The AI has no place of its own; it lodges in the places of real work, and operates from within each.
This choice demands far more engineering effort than a product with its own interface. Building inside others’ tools, embracing their constraints, following their evolutions, handling their particularities, is infinitely costlier than putting up your own window and bringing the user to it. But it is precisely this effort that makes the layer usable at scale. Because at scale, what is integrated is used, and what is used becomes the organization’s real infrastructure. The rest stays at the margin, whatever its intrinsic quality.
This engineering cost is also a barrier, and so much the better. Building a layer that truly integrates into an organization’s inbox, editor, DMS and matter system requires patient, unspectacular work, rarely valued in demonstration. It is precisely the kind of work that products designed to charm quickly avoid, and precisely the one that creates a defensible position. Ease of use at scale is not simulated; it is built, brick by brick, in integration, and it is not caught up by a last-minute effort.
Lodging inside others’ tools is costly to build. It is exactly this cost that separates a product from an infrastructure.
This choice says what we think of legal adoption: it is not won by convincing users to change their habits, but by respecting those habits to the point that the new layer becomes invisible. It is a difference of philosophy, and it is also a difference of future. Legal AI that lives inside existing tools has an adoption horizon without ceiling, where AI that requires a detour always hits the same limit, the day users’ discipline runs out.
There is here a reversal of perspective worth owning. Most legal AI projects ask the organization for an effort of adaptation: train the teams, change the habits, adopt new reflexes. MAX takes the opposite bet, more demanding for the designer and gentler for the user: it is for the layer to adapt to the organization, not the reverse. This bet is not a posture of comfort; it is the only known way to have a technology adopted at scale without paying its price in resistance.
Adoption is not won by changing habits. It is won by respecting them until you disappear into them.
