Legal AI is separating into a reasoning layer and a context layer
Harvey, Legora, and DeepJudge point to an emerging legal-AI architecture: specialized reasoning tools connected to governed institutional context.
- Author
- Context Systems
- Published
- 19 Aug 2026
- Reading time
- 12 min read
- Tags
- Legal AI · Context systems · Institutional knowledge
Legal AI has spent the past several years getting better at the task in front of it.
Models can draft, summarize, compare, research, extract, and analyze. Workflow products are turning those capabilities into tools designed for legal work.
But a capable reasoning system can still begin with incomplete context.
It may not know which instruction governs, why a clause changed, what the client accepted last time, which version is current, or what remains open across the matter. It can only reason from the information available to it.
Recent activity across the legal-AI market suggests that vendors increasingly see this as a separate architectural problem.
In May 2026, Harvey and DeepJudge announced a partnership intended to bring a legal organization’s prior work, decisions, and institutional knowledge into Harvey’s workflows.
In August, Legora and DeepJudge announced a bidirectional integration: prior work and precedent can inform work in Legora, while new work product can flow back into the organization’s knowledge layer.
DeepJudge also introduced an Agent Handoff Protocol, with Harvey and Thomson Reuters among the early adopters. As LawNext reports, the protocol is designed to let a user move between specialized AI applications without rebuilding the objective, selected conversation context, and supporting resources from scratch.
These announcements are vendor claims, not independent proof of outcomes. But together they are a meaningful market signal.
Legal AI is beginning to separate into complementary layers:
- a reasoning layer that drafts, analyzes, and acts; and
- a context layer that maintains the governed, matter-specific record from which useful legal work can begin.
Search remains essential inside that architecture. So do document systems, workflow products, and professional judgment. The shift is the recognition that none of them alone preserves the full working state of a matter.
Reasoning and context are different capabilities
A reasoning system transforms inputs into an output.
It might review a contract, draft a response, compare clauses, answer a research question, or recommend a next step. Its value depends partly on the quality of the model and partly on the design of the workflow around it.
A context system has a different job.
It organizes the relevant history around clients and matters: communications, documents, people, decisions, prior work, permissions, and chronology. It helps determine what information should be available when the reasoning begins.
The distinction matters because legal work is rarely contained in one prompt.
A lawyer revising an agreement may need the client’s original instruction, the reason a position changed, an earlier negotiation, a current form, the partner’s preferred approach, and an understanding of what has already been promised.
The model can reason over that material. It does not necessarily know how to find, organize, govern, and maintain it over time.
This does not make the reasoning layer less important. It means legal AI has at least two hard problems rather than one.
Where search stops
Search is the foundation of most approaches to grounding AI in firm information.
It retrieves candidate documents, messages, and records in response to a query. Modern systems can use semantics, metadata, entities, permissions, and matter information to improve the result.
But retrieval is not the same as maintaining state.
Three real-world patterns illustrate the difference.
The missing email
A lawyer knows that a recent email is relevant to an AI task. The message exists and can be found through search, but it has not been associated with the correct client, matter, or working context.
Search solves access to the message. It does not solve whether the system knows that this message belongs in the task’s context before the lawyer intervenes.
The outdated form
A team searches for a standard form and receives several plausible versions. The retrieval system has found matching documents.
The operational question remains unanswered: which version is current, approved, and appropriate for this matter?
Relevance and governing status are different properties.
The partner returning from holiday
A partner returns after time away to find that several matters have continued moving. Client requests arrived, documents changed, colleagues made decisions, and new commitments accumulated across multiple inbox threads.
Search can help the partner find individual messages and files. It does not necessarily provide a reliable account of what changed, which decisions now govern, what still needs attention, or how each matter reached its current state.
The problem is not access to information. It is recovering orientation across a large volume of activity without manually rebuilding every thread.
In each example, search is useful. The gap appears after retrieval.
The system must connect the item to the right entity, establish how it relates to earlier and later events, respect permissions, and make clear whether the information is current enough to guide the work.
A search index is not a matter model
Search usually begins when someone asks a question.
That is enough when the user knows what they need: a defined document, phrase, sender, authority, or precedent.
Matter context also includes information the user may not know to request:
- a later instruction that superseded the one they found;
- a commitment made in a separate thread;
- a related decision under a different project name;
- a client restriction that changes what can be used;
- an unresolved action that never entered a formal task system; or
- prior work whose relevance depends on relationships rather than matching language.
The problem is not that search is weak. It is that search and state are different abstractions.
Search asks: Which items may be relevant to this query?
A matter model asks: What is the current, permissioned working picture of this matter, and how did it get here?
A context layer still depends on strong retrieval. If the underlying search misses important material, persistent organization does not magically repair the omission. But the context layer adds relationships, chronology, status, identity, and continuity between sessions.
Session context is not institutional memory
Protocols and handoffs can preserve more context as a user moves between AI products.
This is a meaningful improvement. A lawyer should not need to recreate the objective, upload the same documents, or repeat prior analysis every time a specialized task moves into another application.
But carrying one task’s context is not the same as maintaining the firm’s institutional memory.
A handoff may transfer:
- the current objective;
- selected messages from a conversation;
- documents chosen for the task;
- prior analysis; and
- continuity identifiers.
Institutional context is broader and longer-lived. It includes:
- client and matter histories;
- prior decisions and accepted positions;
- relationships among people, entities, and work;
- current and superseded instructions;
- evolving permissions and exclusions;
- open commitments; and
- knowledge accumulated across future matters and teams.
The first preserves continuity within a piece of work. The second preserves continuity across the organization.
Legal teams need both.
The emerging legal-AI stack
The market does not yet use one consistent vocabulary. Vendors refer to institutional intelligence, matter-aware AI, enterprise search, context, retrieval, memory, and knowledge.
The architecture nevertheless appears to be separating into recognizable layers.
| Layer | Primary job | Examples of what it must handle |
|---|---|---|
| Systems of record | Store the firm’s operational information | Documents, matters, communications, time, client data |
| Search and retrieval | Find candidate information | Keyword search, semantic search, metadata, permissions, citations |
| Institutional context | Maintain the relevant working picture | Chronology, relationships, status, prior decisions, governing instructions |
| Reasoning | Analyze and produce work | Drafting, review, research, comparison, recommendations |
| Workflow | Put capabilities into legal practice | Email, document work, due diligence, task management, professional review |
| Interoperability | Connect systems and move work between them | APIs, connectors, MCP, agent handoffs, write-back |
This is not the only possible model. Some products will combine several layers. Firms may build parts internally. Category boundaries will continue to move.
But the separation is useful because it clarifies what each product is actually being asked to do.
In vendor commentary, Clio’s explanation of the legal-AI technology stack similarly separates legal data, AI reasoning, retrieval and citation, and workflow integration. Its terminology differs, but the underlying idea is consistent: model capability is only one component of useful legal AI.
Why bidirectional integrations matter
A one-way integration lets an AI product retrieve institutional knowledge for the current task.
A bidirectional integration creates the possibility of a loop:
- Prior work and firm knowledge inform a new task.
- A lawyer uses a specialized reasoning or workflow product.
- The resulting work is reviewed and finalized.
- That new work becomes available to inform future matters.
This is the most important part of the Legora–DeepJudge announcement.
The value is not simply that one product can search another. It is that the organization’s knowledge can, in principle, compound as new work is produced.
That loop also creates hard questions.
What gets written back? When does draft work become institutional knowledge? How are versions handled? What happens when the new work is incorrect, confidential, or matter-specific? Which permissions follow it? Can lawyers correct how the system has interpreted the matter?
Institutional memory is valuable because it persists. Persistence also raises the cost of getting the record wrong.
Context must remain governed
A context layer with access to firm communications and prior work cannot be evaluated only by retrieval quality.
It must also address:
- which clients, matters, users, and sources are included;
- how ethical walls and existing permissions are respected;
- whether one client’s information can affect another client’s work;
- which version or instruction is treated as current;
- how source material can be inspected;
- how mistakes in routing or entity resolution are corrected;
- what is retained and for how long; and
- whether firm information is used to train models.
More context is not automatically better context.
The goal is relevant, current, permissioned, and reviewable context—not unrestricted access to everything the firm has ever produced.
This is also why “complete context” and “perfect memory” are not useful promises. Information may be missing, delayed, misrouted, superseded, or intentionally unavailable to a user. A professional system should make those boundaries visible rather than pretend they do not exist.
Connected specialists may be more realistic than one universal platform
Legal teams already use specialist systems for research, document management, drafting, review, transactions, communications, and matters.
They may continue to prefer different products for different jobs.
The recent partnerships suggest that the market is accommodating that reality. Harvey, Legora, Thomson Reuters, and DeepJudge are not converging into one universal interface. They are exploring ways for specialized products to share or preserve context.
An Activant Capital analysis of the legal-AI market describes institutional memory as one of the durable assets a model cannot manufacture by itself. The source is an investment thesis, not neutral product research, but the distinction is useful: model interfaces can change quickly; firm-specific knowledge accumulates slowly.
For law firms, the procurement question may therefore become less about selecting one AI product and more about deciding:
- where institutional context should live;
- which reasoning and workflow products may use it;
- how context moves between systems;
- who controls the permissions and audit trail;
- whether new work flows back into firm memory; and
- how easily the firm can change models or applications later.
The architecture matters because it determines where the firm’s most durable intelligence accumulates.
What firms should ask vendors now
As the layers become more connected, legal teams should ask:
- What context does the product use? Documents alone, or also communications, decisions, people, tasks, and matter state?
- How is current information distinguished from superseded information?
- Which permissions and exclusions govern retrieval?
- Can the lawyer inspect the sources behind the context?
- What happens when information is associated with the wrong client or matter?
- Does context persist beyond one session or task?
- Can context move into another reasoning or workflow product?
- Does new, reviewed work flow back into institutional knowledge?
- Who owns and controls the accumulated context?
- Can the firm change models or workflow tools without rebuilding its memory layer?
These questions are more durable than a feature comparison between the current generation of products.
The model is only as situated as its starting point
The recent Harvey, Legora, Thomson Reuters, and DeepJudge activity is drawing attention to a problem law firms already experience.
Legal work is shaped by history: client relationships, prior decisions, accepted positions, negotiated language, matter chronology, and professional judgment.
A reasoning system can be extremely capable and still begin from an incomplete picture. Search can retrieve highly relevant material and still leave open which instruction governs, what changed, what remains outstanding, or whether the material is appropriate for the user and matter.
The emerging context layer addresses that gap.
Its job is not to replace reasoning, search, document systems, or lawyers. Its job is to maintain a governed working picture from which those systems—and the professionals using them—can begin.
The future legal-AI stack is unlikely to be one model in one interface. It is more likely to be a connected system in which reasoning tools become more useful because they no longer have to start from zero.
Frequently asked questions
What is a reasoning layer in legal AI?
The reasoning layer is the model or agent that analyzes information and produces work, such as drafting, review, research support, comparison, or recommendations.
What is a context layer in legal AI?
A context layer organizes the permissioned, matter-specific history needed to inform legal work. It may include communications, documents, people, chronology, decisions, prior work, and current state.
Is a context layer the same as RAG or enterprise search?
No. Retrieval-augmented generation and enterprise search help find relevant information. A persistent context layer also seeks to maintain relationships, chronology, governing status, and continuity across sessions and tasks. It still depends on strong retrieval.
Does MCP create institutional memory?
Not by itself. MCP standardizes how an AI application can access external tools and resources. The connected systems still determine what information is available, how it is governed, and whether it represents durable institutional context.
Is an agent handoff the same as persistent context?
No. A handoff can preserve the objective and selected context for a task moving between applications. Persistent institutional context is accumulated across clients, matters, people, decisions, and time.
Do law firms need one universal legal-AI platform?
Not necessarily. Firms may use specialized products for reasoning, research, documents, and workflows while relying on interoperability and a governed context source to connect them.
Related reading
Context Systems · getcounsel.co