In-house legal department, mid-sized manufacturing group

The challenge

The department received requests by email, by Microsoft Teams message, through a ticketing system two business units used and nine ignored, in meeting invitations, and in corridor conversations at the head office. No two lawyers received work through the same channel with the same information, and nothing was measured - the general counsel could not tell the CFO how many requests the department actually handled in a quarter, let alone how long each took. Roughly forty per cent of inbound volume, once logged, turned out to be one of a small number of recurring question types the department had answered many times before. The department could not select its own software; anything new required security review, data-residency sign-off, and procurement, each measured in months, not weeks.

How we diagnosed it

Primitives most affected

The transformation, phase by phase

1. 01

   Name

   Two weeks of request logging across all channels ran in parallel with opening the security and data-residency conversation immediately - not sequentially - since that review track alone would take nine weeks regardless of when it started. The department's six request types were named, and the recurring-question set was identified and quantified for the first time.

   • Week 1: Request logging began across all five channels and the security and data-residency conversation was opened the same week, in parallel, given its nine-week minimum.
   • Week 2: Logging closed, the six recurring request types were named and quantified, and the bottleneck brief identified intake as the constraint ahead of drafting.

2. 02

   Systematise

   One front door replaced five channels: a structured intake form routing by request type and capturing what a lawyer would otherwise have to chase. A written risk tier defined which requests could be handled by the deflection layer, which needed a lawyer within a day, and which needed immediate senior attention. The recurring-question answers moved into a searchable stock, and the standard NDA review became a single named checklist instead of six lawyers' six private versions of the same review.

   • Week 3: Built the structured intake form and the written risk tier defining which requests the deflection layer could handle, which needed a lawyer within a day, and which needed immediate senior attention.
   • Week 4: Migrated the recurring-question answers into a searchable stock and wrote the single named NDA-review checklist, replacing six lawyers' six private versions.
   • Week 5: Piloted the single front door with two of the eleven business units before rolling it out company-wide, using their feedback to adjust the intake form's fields.

3. 03

   Automate

   The intake layer surfaces the existing answer for any of the six recurring question types at the point of submission, resolving a meaningful share of volume before a lawyer ever sees it. A contract-review agent runs the standard NDA checklist as a first pass, inside the company's existing enterprise AI tooling - the only option the nine-week-minimum security review would clear in time - with a named lawyer reviewing every output before it returns to the business.

   • Week 6: The intake layer went live company-wide, surfacing the existing answer for any of the six recurring question types at the point of submission.
   • Week 7: The contract-review agent went live inside the company's existing enterprise AI tooling once security clearance came through, running the standard NDA checklist as a first pass with a named lawyer reviewing every output.
   • Week 8: Reviewed the first full week of combined intake and contract-review data with the general counsel and confirmed the escalation rule was catching the deviations it was meant to catch.

How we created value

AI education and training

Every deployment on this engagement was preceded by training - on what the models actually do, on OpenAI and Anthropic's behaviour on this organisation's own documents, and on the anchoring discipline required before automation, not after.

• A department-wide session on what the enterprise AI tool can and cannot be trusted for

  Because procurement constraints meant the department had to work inside an existing enterprise AI deployment rather than choosing a specialist legal tool, the six lawyers were trained specifically on that tool's actual behaviour on the department's own contract language - its failure modes on this specific document type, not a generic capability briefing.

• Prompt patterns built for non-lawyers on the business side

  Because a meaningful share of intake now happens through a self-service layer that business stakeholders interact with directly, the training extended past the legal team to a short session for business-unit points of contact on how to describe a request precisely enough for the routing and deflection logic to work - the first time those stakeholders had received any structured guidance on how to bring legal a well-formed request.

• A written escalation rule for when the AI-assisted first pass should stop

  The department adopted an explicit, written rule for when a contract deviates from the standard template enough that the first-pass review must stop and go to a named lawyer immediately rather than continuing - trained into every lawyer before the agent went live, not discovered as a gap afterward.

• A short session on reading the department's own workload data

  Once request logging produced an actual dataset, the six lawyers and the general counsel were trained specifically on how to read and act on it - which request types were growing, which business units generated disproportionate volume - so the data collection effort translated into an ongoing habit rather than a one-time diagnostic exercise.

Smart solutions we built

Agent solutions deployed

How MatterOS, LexOS, and the rest fit together

Existing enterprise AI deployment

The department's automation layer runs inside the company's already-approved enterprise AI tooling rather than a new specialist product, because that was the only option the nine-week security-review floor would clear inside the engagement timeline - a deliberate choice, not a compromise nobody noticed.

MatterOS (request-management configuration)

Configured to run the Matter and Actions primitives for the department's request taxonomy and routing rules, deployed within the company's own data environment to satisfy residency requirements.

Structured intake form

The single front door replacing five uncontrolled channels, built to capture the fields the routing and deflection logic actually need at the point of submission.

The department's existing spreadsheet-based reporting (retired)

The three separate informal tracking spreadsheets were retired once the workload dashboard went live, deliberately rather than left running in parallel, so there was only ever one source of truth for the department's own volume.

The shift to AI-native

This is AI Adoption exactly as the thesis describes it, not as a lesser outcome but as the honest one. The department could not re-architect its own technology stack, could not select tools outside enterprise procurement, and could not change the nine-week security-review floor - a full AI-native rebuild was never realistically on the table, and adnah said so in week one rather than after two quarters had been lost pretending otherwise. What was fully available was every one of the six primitives, named and systematised, with automation installed inside the exact constraints that already existed rather than around them. The decision that mattered most was refusing to start with contract drafting, where the visible volume sat, in favour of intake - because the department's actual bottleneck was upstream of any drafting tool, and no amount of AI applied to the wrong end of the workflow would have recovered the capacity that a properly designed front door did.

Outcome

Requests resolved without a lawyer

0% → 31%

Standard NDA review time

−58%

Request channels

5 → 1