How to Design an Agentic Legal Operating System

Why isn't a foundation model enough to build on?

The framework's sharpest architectural principle is 'the engine is not a car.' Foundation models (LLMs) are necessary but insufficient for legal work. A platform built for everyone is built for no one, and horizontal AI with legal plugins is not the same as a deep vertical legal system. If you're building on a raw LLM alone, you have a stateless component with no memory, guardrails, or context — it can't carry a multi-step legal task to completion.

Legal work requires a full stack: domain-specific data, task management, interfaces, governance, security, workflows, integrations, and human partnership. That full stack is the Agentic Operating System (AOS).

How are the six AOS layers structured?

Design your architecture against these six layers, in dependency order:

1. Foundation Models — the LLMs. Decide whether they're horizontal or legal-specific.

2. Agentic Harness — the spine: memory, guardrails, tool routing, and multi-step execution (retrieval, checking, flagging, drafting, reviewing). Without this, nothing above it works.

3. Data and Integrations — document management, signing platforms, data sources, third-party publishers, unified rather than siloed.

4. Context and Knowledge — precedents, clause libraries, playbooks, matter history, all accessible to the AI.

5. Legal Skills and Capabilities — domain-specific workflows, instructions, and long-context handling.

6. Enterprise Security and Governance — ethical walls, matter-centricity, audit trails, permissions.

Audit your current build against each layer and flag what's missing, weak, or disconnected before adding features.

How do you make legal work executable with Skills and Lists?

Two primitives turn the AOS from a model into a working system:

- Skills are custom plain-English instructions that encode a team's knowledge, processes, and standards — like briefing a new team member. The agent proactively loads the right Skill for a task. Offer a library of out-of-the-box Skills, then let teams customise. Lawyers author them; they're the best prompt engineers because they know the work.

- Lists are the connective tissue between agents, lawyers, and stakeholders. Each list item is an atomic object with metadata — status, assignee, parties, jurisdiction, source citation, dates. The agent populates, updates, and flags items; humans review and reassign. When the agent completes a task inside a List, work product returns to the List for review and the relevant lawyer is notified.

Add Monitors for proactive regulatory horizon scanning and sub-agents for parallel execution of complex, multi-workstream tasks.

How do you design safe human-agent collaboration?

Human oversight must be integrated throughout, not bolted on at the end. For every long-running task, enforce a Plan Approval checkpoint: the agent sets the objective, produces a plan, and waits for human review and explicit approval before executing. Mid-task, the agent flags uncertainty and asks clarifying questions rather than guessing, then returns completed work for review. The framework is explicit that you can't send off a task and expect a finished sausage — and that failing to set intent at the start is a top cause of poor outcomes.

Finally, plan for the Legal Engineer role from the start. These are former lawyers who are deep AI experts and understand legal workflows, risk tolerance, and culture of change. They deploy, tailor, and partner to bring the AOS to life. Deploy as many Legal Engineers as software engineers — change management is as important as the technology.

Next step

Audit your current product against all six AOS layers and identify whether you have a genuine Agentic Harness or just stateless prompting. Then prioritise building Skills and Lists over new point features, and design a mandatory Plan Approval checkpoint into every long-running workflow before you ship.