The architecture of legal work

Legal engineering begins with a question: how does legal work become a system that people can understand, use, and improve?

A useful answer has to connect the substance of the work with the way it is organized and delivered. A research tool can find material. A process model can explain the next step. A delivery method can help a team implement a change. The architecture brings those contributions together and makes their boundaries visible.

One system, three layers

View the relationship model (Mermaid)

flowchart TB
    A["PROCESS AND SYSTEM ARCHITECTURE<br/>Model the work with the lawyer · state each step's need · run the workflow"]
    B["DELIVERY AND COORDINATION<br/>Resolve each need: reuse · wrap · build · test · release"]
    C["DOMAIN CAPABILITIES<br/>Research · cite-check · drafting · review · extraction"]
    A -->|Signed-off design and its needs| B
    B -->|Reuses, wraps or builds capabilities| C
    B -->|Released workflow version| A
    A -->|At run time, invokes through host| C
    subgraph X["ALSO POSSIBLE IN LAYER 1, WITH THANKS"]
      LQ["LegalQuants open-source skills"]
      AL["Anthropic legal plugin"]
    end
    C -.- X

The layers distinguish responsibilities. They are not an order in which every matter must pass through three agents. When a matter runs, process architecture calls a domain capability directly. Delivery decides which capability serves each step and builds what is missing; it does not sit between every research question and its answer.

At the top, the architecture describes the process with the lawyer: what starts it, what information it needs, which decisions change its route, who has authority, what each AI-supported step must produce, and what completion means. In the middle, delivery looks at what the domain layer already offers, reuses or adapts it where it fits, builds the rest, and releases a tested version. At the foundation, domain capabilities describe how particular pieces of legal work should be done: research is one; drafting, review and extraction are others.

Read the architecture in two moments

The work of building a system and the work of using that system on a matter need different records and decisions.

View the relationship model (Mermaid)

flowchart TB
    subgraph Build["BUILD THE SYSTEM"]
      C["Understand the process"] --> M["Agree the design · design sign-off"]
      M --> P["Resolve, build and test capabilities"]
      P --> L["Release sign-off"]
    end
    subgraph Run["USE THE SYSTEM"]
      I["Matter inputs"] --> W["Released workflow"]
      W --> T["Skill and human tasks"]
      T --> R["Reviewed outcome"]
    end
    L --> W
    R -.->|Evidence for improvement| C

A team might spend a fortnight building a reliable research handoff. During that work, it maintains a backlog, reviews prototypes, tests missing-information cases, and agrees acceptance criteria. Later, a lawyer uses the released workflow for a particular request. That run has its own facts, task results, source records, and human decisions.

A successful delivery review does not approve the legal conclusions in a future matter. A completed matter does not prove that the system works reliably across every case. The architecture keeps both kinds of evidence.

Four things the design must keep separate

Responsibility answers who is accountable for the work. Automation describes how much assistance a task receives. Execution identifies what performs the step. Authority determines who may make a consequential decision.

An associate can remain responsible for a review performed with an AI comparison skill. A partner can decide whether a departure from a playbook is acceptable. A software integration can then record the outcome. These are connected activities with different powers, rather than interchangeable agents.

The framework has working components

Three independently maintained components put this architecture into practice, joined by a generated toolkit skill. A process-modeling meta-skill models the process with the lawyer, generates new methods when delivery needs them, and runs the released workflow. A Scrum skill and the toolkit's capability resolver support delivery: they find, adapt or build what each step needs. A Singapore research skill supplies the first domain capability, research and cite-checking; other domain capabilities can join it.

The runner controls task eligibility and state. The active AI host supplies reasoning and connected tools. People retain the decisions assigned to them. This distinction is the basis for making work inspectable without pretending that a model's reasoning is deterministic.

This guide develops a proposed framework rather than a universal professional standard. It presents a method for reasoning about systems and then explains the current implementation. The argument does not require access to Git, a programming background, or installation of the toolkit.

Continue inside the three layers. The next chapter looks at each layer's job and boundary in turn. The disciplines that meet in this work, LegalTech, Legal Operations and Legal Engineering, are compared later, in Building the practice.