ED
Legal operations agent design

Matter Intelligence Brief

Matter Intelligence Brief keeps a legal matter brief current as new material arrives. Each filing, order, or email is read by an extractor — rules, an LLM, or Harvey — and every proposed fact must be backed by a verbatim quote from the document. Due dates are computed by code, not guessed by a model. New or moved deadlines and new adverse parties wait for attorney approval, then the brief regenerates with a clear “what changed” summary and a source for every line.

Every line has a source
A verbatim quote from the document, or it's rejected
Deadlines are computed
Date math by code, never guessed by a model
A lawyer approves what matters
New or moved deadlines and adverse parties wait for review
All AI GPTs & Agents

A self-updating matter brief where every line has a source, every deadline is computed, and a lawyer approves what matters.

How it works

Three steps, in order

Step 1
Extract

New material comes in and proposed facts are pulled out, each with a source quote.

Rules extractor, an LLM, or Harvey
Step 2
Verify

Anything without a matching quote, date, period, or name is rejected. Material changes go to attorney review.

The validation gate
Step 3
Brief

The approved record renders as a brief that opens with what changed.

A source on every line
Matter Intelligence Brief workflow: new material — a filing, order, or email — flows into the human-reviewed matter brief, which routes to grounded extraction, the deadline engine, and the matter record, with attorney review approving material changes.
Matter Intelligence Brief workflow. New material flows into the human-reviewed brief, which feeds grounded extraction, the deadline engine, and the matter record; attorney review approves material changes.

What Harvey would do here

  • Vault

    Holds the matter's documents and bulk-extracts parties, dates, issues, and requests into review tables.

  • Workflow Builder

    A “matter update” workflow: user input (matter and new document), AI action (extract), logic (classify the document type), output (structured rows with source passages).

  • Microsoft and DMS integrations

    Possible upstream source of new documents, if it can watch iManage, NetDocuments, or SharePoint.

  • Assistant, Knowledge

    Not part of the pipeline. Lawyers use them for questions, drafting, and research alongside the brief.

What Harvey does not do here

This repo owns the parts that make the brief trustworthy:

  • The validation gate, which requires a verbatim quote and dates that are stated in it
  • The durable record with a source on every fact
  • Deterministic deadline math
  • The materiality policy and attorney review queue
  • The change log behind “what changed”
Rendering the brief

Why I'd keep rendering outside Harvey

  • 1. No self-grading

    A system shouldn't grade its own extraction. Harvey extracts and your layer verifies.

  • 2. Vendor-neutral record

    The record stays vendor-neutral, so you can swap Harvey for another tool or a local model without losing history.

  • 3. A hard gate, not a habit

    Harvey's own team describes validating every finding against source documents with humans making the final call. This design makes that a hard gate.

MCP servers

This repo has none — and that's the point

It's a Python package with a CLI, and the only integration point is the extractor interface, including the Harvey stub. That differs from HR Supervisor Coaching, where hr-policy-library is an MCP server the agent calls.

The natural next step is an MCP server that exposes the matter record as tools an agent can call, so an assistant could answer “what's due next on this matter, and where does that date come from?” from the validated record:

  • get_brief

    Returns the current brief for a matter.

  • list_deadlines

    Returns upcoming deadlines with their sources.

  • list_pending_changes

    Shows what is waiting for review.

  • ingest_document

    Adds a new document and returns what changed.

  • approve_change

    The sensitive one. I'd keep it out of the agent's tools, or gate it behind explicit human confirmation, since approval is the lawyer's decision.

View the code on GitHub
Integration

Three ways to connect it

Manual bridge

Run a Harvey workflow, export the table, and import it as proposals. This needs no API and is the realistic pilot path.

No API · realistic pilot path
API bridge

A workflow run is triggered by a new document, and results flow straight in. This depends on Harvey exposing that, which I haven't confirmed.

Depends on Harvey's API · unconfirmed
Build it all inside Harvey

You'd get the extraction and a Harvey-native experience. You'd lose the persistent change log, the deadline engine, and the review policy unless Harvey offers equivalents. It also couldn't live on GitHub.

Fastest surface · loses the durable layer
Caveats

Worth knowing before you lean on it

  • The docs disagree with themselves on one parameter

    ids= versus file_ids=. The client follows the API reference.

  • Strictness has a cost

    A period written only in words, like “thirty days”, would be rejected. Run the eval on real documents before relying on it.

  • The demo is a hybrid

    The sample Harvey rows cover only their columns, and the rules extractor fills the rest, such as the third-party claim.

Let's architect your next transformation

Whether you're modernizing platforms, scaling AI, or rethinking your operating model — let's talk about what's possible.

Start a conversation About Elyse