Product
No One Wants One More Tab
The first obstacle to legal AI adoption is not model quality. It is the gesture, repeated a thousand times, of moving information from one tool to another.
Watch a legal professional for an entire day, in any firm, and you will see the same scene. An inbox open at all times. A document management system. A matter management tool. A text editor. A document comparator. A video platform, a signature platform. And now, on the side, in a separate tab, a copilot. By the end of the day, this person has spent a significant share of their time not practicing law, but transferring information from one environment to another, by hand, copying, pasting, reformulating, carrying back.
This scene is so ordinary that it is no longer seen. It settled in by layers, one tool after another, each solving a real problem, and the sum ended up creating a problem no one chose: the scattering of work across a dozen environments that do not talk to each other. The professional has become, without wanting to, the only link between tools that ignore one another. It is they who carry the context from one place to the next, because no system does it for them.
This friction has become so ordinary that it is no longer even articulated. It is nonetheless the first real obstacle to the serious adoption of legal AI, well before model quality or answer relevance. We debate system performance when the blocking point is elsewhere, upstream, in the simple fact of having to move to solicit them.
The first brake on legal AI is not what it can do. It is the place you must go to ask it.
The tab that piles on instead of replacing
When a tool arrives with its own interface, its own framing, its own vocabulary, it adds a load without removing any. It replaces nothing; it piles on. The user must leave the context of their work, enter the tool’s, translate their need into the tool’s language, wait, evaluate the answer, then carry it back by hand into their real flow. Each of these steps is tiny; their repetition is not.
One must measure the nature of this cost, because it explains why it is so often neglected. It is not a one-off, visible cost, the kind assessed before buying. It is a diffuse cost, made of a few seconds lost at each solicitation, multiplied by the number of solicitations in a day, then by the number of days, then by the number of users. Taken alone, each transfer is negligible; that is precisely why it is not counted. But what goes uncounted ends up deciding.
The most insidious part is that this cost is visible nowhere. It appears on no invoice, enters no metric, compares to nothing. It dissolves into the everyday, in the form of a few seconds lost a thousand times a day, and it is precisely because it is invisible that it ends up deciding the failure or success of a deployment. A tool whose every use costs a small effort of displacement will, at scale, be deserted, whatever the brilliance of what it produces once you are inside it.
A small effort, a thousand times a day, across hundreds of people, does not stay small. It decides everything.
One then sees that manual transfer from one environment to another is no minor, unimportant task. It takes real time, it fragments attention, it interrupts the thread of work at the precise moment it should be held. And above all, it brings nothing: copying information from one tool to another creates no legal value, it is pure loss, an expenditure of energy that intellectual work does not require and that only the architecture of the tools imposes.
Manual transfer from one tool to another is not legal work. It is usage cost disguised as productivity.
Coming where the work already happens
If the cost is born of displacement, then the only way to remove it is not to make the displacement more pleasant, but to remove it altogether. A tool that does not ask you to come to it does not need to be faster to open or simpler to learn: it does not have to be opened, nor learned as a separate place, because it is not a place. It acts where the work already happens, in the inbox, in the editor, in the matter system, without requiring that you leave them.
This reversal changes the adoption question entirely. As long as a tool is a destination, the question is: how do you convince people to go there, and to return, day after day? The moment a tool ceases to be a destination, that question disappears, because there is nowhere left to go. The user does not have to decide to use the AI; it is present in the environment they use anyway. They are not asked to add a gesture to their day; a gesture that should never have been there is removed from it.
This way of proceeding is not a matter of comfort, but of viability at scale. An infrastructure that lives inside existing tools does not hit the adoption ceiling that awaits every destination, because it asks no one to change their habits. It fits into the already installed flows, and precisely because it requires no new gesture, it can transform how work is done without charging the entry cost. The transformation happens underneath, without demanding effort from those it transforms.
An infrastructure does not ask the organization to adapt to it. It fits into what the organization already does.
Why discipline will not save adoption
Faced with this observation, the spontaneous response is to minimize. It will be objected that the user gets used to it, that one more tab is no tragedy, that a little discipline suffices to integrate the new tool into one’s gestures. This argument seems reasonable, and it is, within a certain perimeter: for a motivated user, over a few weeks, discipline does suffice to overcome the friction.
But that perimeter is not that of a real deployment. What is true for a motivated user over a few weeks ceases to be so for two hundred people over two years, under the pressure of the everyday, on the busy days where every second counts and reflex prevails over good resolution. Discipline is a rare resource, unevenly distributed, and above all fluctuating: it is high the first month, it erodes afterward. To ground a tool’s adoption on its users’ discipline is to ground it on what gives way first.
Product, by contrast, is constant. A tool that demands no new gesture does not depend on the motivation of whoever uses it: it works as well on day one as on day one hundred, for the enthusiast as for the reluctant, in the calm day as in the overloaded one. It is this constancy that separates a durably adopted tool from one abandoned after the initial enthusiasm. The difference owes not to the quality of what the tool produces, but to what it requires for access.
This is why the question of the tab is not a surface ergonomics question, but a category question. A tool that asks the organization to come to it and a tool that comes where the organization already works are not two variants of the same product: they are two different species, with two different fates. One has an adoption ceiling set by its users’ patience; the other has none, because it demands no patience.
These are not two variants of the same product. They are two different categories, and only one scales to an entire organization.
