Beyond chat, towards a legal workforce.
For most of the last two decades, software has been built by adding features. A team of engineers identifies a need, designs a feature to address it, ships it, gathers feedback, refines it, and adds it to the product. The product, over time, becomes the sum of its features. This way of building has produced extraordinary improvements in many fields. It has also, in the field of legal technology, reached a point of diminishing returns that is worth examining honestly.
The diminishing returns are visible in the landscape of legal software. A research tool. A drafting tool. A contract management tool. A litigation tracker. A docket system. A timekeeper. A bundle preparer. A clause library. Each is a feature of legal practice that has been turned into a product. Each does what it does, often well. None of them does what the practising lawyer actually wants done, which is the matter, end to end, with the friction between the tools removed.
The friction is not incidental. It is the structural cost of organising software by feature when the work is organised by purpose. A lawyer drafting a memo on a tax matter does not, in her own mind, switch between research and drafting and citation checking. She does the work in a single integrated sweep, switching contexts only because the tools require it. The tools that require it do so because they were designed by feature, not by purpose. The integration cost has been pushed onto the user, who absorbs it as a kind of background tax on the working day.
For a long time this was the only way. Software was not capable of doing what would be required to remove the integration cost. The cost remained, and lawyers, like all professionals working with imperfect tools, learned to live with it. The recent improvement in artificial intelligence, particularly in language understanding, has changed the underlying calculus. The integration cost is, for the first time, reducible. The question is whether the next generation of legal software will reduce it.
This essay argues that the reduction will not come from adding more features. It will come from changing the unit of design. The unit must no longer be the feature. It must be the skill. A skill, as we use the term, is a self-contained unit of legal work, defined by its inputs, its outputs, the authorities it consults, and the standards by which it is evaluated. A system organised by skill, rather than by feature, can be assembled and reassembled to fit the work, rather than the other way around. The implications, taken seriously, are large enough to suggest a different way of thinking about the relationship between legal professionals and the tools they use.
What, precisely, is a skill? The answer matters, because the strength of the abstraction depends on its precision. A skill, in our use, is a structured object with several defined properties.
This definition is more demanding than it appears. Most software features do not satisfy it. A feature, in conventional software, is described by what it does. A skill is described by what it produces, against which inputs, under which constraints, to which standard. The definition imposes a discipline on the design of the software that is closer to the design of a job than to the design of a tool.
The decision to design by skill rather than by feature is, accordingly, a decision to think about software as a kind of work to be done rather than as a kind of capability to be exposed. The shift is small in vocabulary and large in consequence.
A single skill, on its own, is useful but limited. The leverage of the abstraction comes from composition. Multiple skills, assembled into a coherent sequence, perform work of arbitrary complexity. The composition is not a rigid pipeline. It is a configurable arrangement, in which skills are connected through their inputs and outputs, with intermediate decisions made by the user or by another skill.
Composition is the operation that transforms a list of skills into a workforce. Consider a litigation engagement. The matter requires research on the controlling authorities, drafting of pleadings, preparation of a chronology, building of a bundle of documents, and the maintenance of a deadline calendar. Each of these is a skill, or a small cluster of skills. Assembled together, they constitute the work product of a litigation team. A user, instead of running each skill separately, configures the composition once and invokes it for each matter that requires it.
The compositions can be saved, shared, and refined. A senior lawyer who has learned, over years, the right sequence of operations for a particular kind of matter can encode that sequence as a composition. Junior lawyers can use the composition. The senior's tacit knowledge becomes explicit and reusable. The composition is, in effect, the firm's institutional memory, made executable.
Compositions also support branching. A skill that produces a multi-issue analysis can route each issue to a different downstream skill. A skill that detects a high-risk clause can trigger a review by a more thorough skill before the document moves forward. A skill that fails to find supporting authority can pause the composition and request human review rather than producing a confident answer that the underlying authority does not support. The branching makes the composition adaptive without making it opaque.
The architecture of composition, taken to its conclusion, is the architecture of a configurable team. The team can be built, scaled, reassigned, and retired through configuration, rather than through hiring and firing. The unit of configuration is the skill. The unit of operation is the composition. The unit of supervision remains, as it must, the human professional.
It is easy, when reading about artificial intelligence in legal work, to assume that the dominant interface will be conversational. The user types a question; the system answers. The interaction is symmetric. Each side is a turn-taker. The metaphor is the conversation, and the architecture follows the metaphor.
The conversational architecture has its place. For exploratory queries, for research that does not yet have a defined output, for the kinds of question whose answer the user is still in the process of forming, the conversation is a productive medium. It is also, however, a medium with structural limits. The conversation does not produce reusable artefacts. It does not compose. It does not enforce standards across multiple invocations. It does not remember, across matters, what the user has said about how she likes her work done. It optimises for the immediate response, not for the durable system.
The skill-configurable architecture is a different proposition. It is not an alternative interface for the same underlying technology. It is a different commitment about what the technology is for. A conversational system is an answering machine, however sophisticated. A skill-configurable system is a workforce, however constrained. The choice between them is not a choice of interface. It is a choice of how the work will be organised.
This choice has practical consequences. A system organised as a workforce can take on work that has the shape of a job, not just the shape of a question. It can be assigned a matter, given access to the materials, configured with the appropriate skills, and asked to produce an end-to-end deliverable. The conversation, where it occurs, is the supervision: the senior reviewing the junior's draft, asking for revisions, approving the result. The conversation is not the work. The work has been done by the composition.
The shift from chat to workforce is, in our experience, the shift that customers most often request once they have understood what is possible. The first instinct is to ask the conversational system more sophisticated questions. The second instinct, after some time using it, is to ask whether the system can be configured to do the work itself, supervised rather than queried. The architecture should be ready for the second instinct, not stuck at the first.
Software has long supported configuration. The configuration of conventional software, however, tends to be at the level of feature flags, preferences, and integrations. A user enables a feature she wants. She disables a feature she does not. She sets a default value for a parameter. The configuration is a personalisation of a system whose underlying capabilities are fixed.
Skill configuration is different. The configuration is not personalisation; it is composition. The user is not selecting from a menu of available behaviours. She is assembling a team. The skills she selects, the order in which she arranges them, the inputs she supplies, and the standards she sets jointly determine the system's behaviour for the duration of the work. The same user, on the same day, may configure the system one way for a tax matter and another way for a litigation matter. The system is not switching modes; it is being assembled differently.
This difference matters for several reasons. It matters because the configuration is a meaningful artefact. A composition for a particular kind of matter, once built and refined, is itself work product. It can be saved, named, audited, and reused. A team of lawyers in a single firm can converge on shared compositions, which become the firm's standard operating procedures, encoded.
It also matters because the configuration is honest about its scope. A configured composition does not pretend to be more than it is. It does not claim to be a general legal assistant. It is the assembly that the user has configured, and its behaviour is constrained to the skills it includes. If the user wishes to extend the work into a new area, she must extend the composition. The system does not silently absorb the new work into a pre-existing model. The honesty of configuration is, in this sense, a safety property.
It matters, finally, because the configuration is portable. A composition that has been refined in one environment can be moved to another. A firm that has built a composition in its private cloud can deploy the same composition on its on-premise installation. A senior lawyer who has built a composition for her practice can share it with a colleague, who adapts it for hers. The portability is what makes the configuration durable. It is not locked into a single deployment, a single user, or a single moment.
Behind the configurable surface lies a catalogue of skills. The catalogue is, in some sense, the heart of the system. Each skill in the catalogue has been designed, tested, evaluated, and documented. Each carries its own contract: what it requires, what it produces, what it consults, how it is evaluated. The discipline of building and maintaining the catalogue is the discipline that determines the quality of the system.
Several principles govern the catalogue.
The discipline of the catalogue is, in many ways, the most demanding part of the system to maintain. A casual approach produces a catalogue that grows fast and degrades fast. A careful approach produces a catalogue that grows slower and ages well. We have chosen the careful approach, and accept its cost in slower expansion as the price of long-term coherence.
One feature of the skill architecture deserves separate attention. Above the operational skills sits a layer of meta-reasoning skills, whose function is not to perform legal work but to supervise the performance of legal work by other skills. Citation verification is a meta-reasoning skill. Adversarial review is a meta-reasoning skill. Cross-validation across multiple authorities is a meta-reasoning skill. Evidence mapping, in which assertions are traced back to their underlying sources, is a meta-reasoning skill.
The meta-reasoning layer is not optional. It is invoked, in our standard configurations, on the output of every operational skill that produces legal work product. The output of a drafting skill is checked by a citation verification skill before being delivered. The output of an analysis skill is challenged by an adversarial review skill before being relied on. The output of a research skill is cross-validated against multiple sources before being treated as settled.
The meta-reasoning layer is what allows the rest of the catalogue to be trusted. Without it, a skill is only as reliable as its own internal discipline, and internal discipline alone is insufficient against the failure modes of language models. With it, every operational skill operates inside a frame of supervision, in the same way that a junior associate's work operates inside the frame of senior review.
The meta-reasoning layer also supports a useful asymmetry. Operational skills can be optimised for the kind of work they do; meta-reasoning skills can be optimised for the kind of error they detect. The two optimisations do not need to be compromised against each other. The architecture allows each to specialise, while the composition ensures that both are present in the same delivery.
The skill architecture is, in the end, the technical foundation for a different commercial proposition. A skill-configurable system is not sold as a product on a per-seat basis. It is leased as capacity, on a per-agent basis, with the user choosing the skills with which the agent is configured. The pricing follows the architecture: capacity is what the user is buying, and capacity is what the user pays for.
This proposition has consequences for the buyer. The buyer of conventional legal software thinks about it as a tool that her existing team will use. The buyer of a skill-configurable system thinks about it as additional capacity that her existing team will supervise. The unit of decision shifts. The question is not whether to add a feature to the lawyer's day. The question is whether to add an agent to the team.
The shift to capacity-based thinking is, for many institutions, the most important shift the architecture supports. It changes the conversation about scale. A firm with twenty lawyers and ten configured agents is not a twenty-person firm with software. It is a thirty-unit firm in which ten of the units happen to be configurable. The supervision overhead is real and must be planned for; the capacity is also real, and so are its outputs. Pricing, scaling, and growth planning all become different exercises when the unit is the agent rather than the seat.
This is the proposition that, in our experience, most rewards careful adoption. Institutions that adopt the system as a feature add to existing tools see modest improvements in productivity. Institutions that adopt the system as configurable capacity, integrated into their workflow with explicit agent supervision, see structural changes in what their teams can take on. The same software, used differently, produces different outcomes. The architecture supports both. The greater rewards are at the further end of the adoption curve.
A workforce, configurable or otherwise, requires supervision. The skill architecture does not change this. It only changes the form of the supervision.
Supervision in a conventional team is conducted at the level of the lawyer. Senior associates supervise juniors. Partners supervise associates. The supervision is review of work product, conversation about approach, and ongoing correction of errors. Supervision in a skill-configurable system is conducted at multiple levels. The composition is supervised at the level of the configuration: which skills are in it, how they are arranged, what standards they enforce. The output of the composition is supervised at the level of the work product: the same review the senior would perform on a junior's draft. The behaviour of individual skills is supervised at the level of the catalogue: skills that produce poor output are flagged, evaluated, and corrected.
Each of these levels is necessary. A composition that is well-configured but produces poor output is improved at the work-product level. A composition that produces good output but is mis-configured for the matter is improved at the configuration level. A skill that consistently underperforms across compositions is improved at the catalogue level. The architecture supports each kind of correction without conflating them.
The lawyer's role, in this architecture, is not diminished. It is shifted. The work that was done by the lawyer's hand is now done by the composition the lawyer supervises. The lawyer's contribution is the configuration, the supervision, and the judgement that determines what the composition is asked to do and whether its output meets the standard. The judgement is not delegable. The system is not a replacement for it. The system is a force multiplier on the lawyer's ability to deploy it across more matters than would otherwise be possible.
The shift from chat to workforce, from feature to skill, from product to capacity, is not an abstract reorganisation. It is the shape of the next decade of legal software. Some firms will resist it, preferring the familiarity of feature-organised tools. Others will embrace it, preferring the leverage of capacity-organised teams. The systems will continue to be designed, with most current designs at the conversational end of the spectrum and a smaller number at the configurable-workforce end.
We have committed to the configurable-workforce end. The commitment is not because the conversational end is uninteresting; it is because the configurable end is where the structural changes in legal practice will be felt. The firm that uses a configurable system well will be doing different work, in different volume, with different supervision, than the firm that uses a conversational system. The difference will accumulate. Over time, the architectures will diverge in what they make possible.
This essay has set out the abstraction that supports the divergence. The skill, defined precisely. The composition, made of skills. The catalogue, curated. The meta-reasoning layer, supervisory. The configuration, portable. The workforce, supervised. None of these is a feature. Each is a structural commitment about how legal AI is to be organised. The system that holds the commitments produces, eventually, a different kind of practice. That is what we are building. That is what beyond chat, towards a workforce, finally means.
— Product