---
title: "A litigation second brain: case files and agents under review"
description: "Field notes for connecting clients, matters, documents, deadlines, and next actions without delegating legal judgment to AI."
author: "Carlos García"
published: 2026-09-30
updated: 2026-09-30
language: en
human_url: "https://kiia.cloud/blog/litigation-second-brain-ai-agents-case-files/"
---

> **In 60 seconds:** A law firm's second brain is an operational record connecting the client, case number, documents, observed status, next action, owner, and evidence. Build it in stages: organize the repository; add authorized connectors for the available court portals; monitor, compare, and archive without duplicates; then enable queries and drafts with visible sources. AI can read, classify, summarize, and prepare. The lawyer decides strategy, checks facts and citations, and approves every action. If a portal offers no permitted access method, that part stays manual.

In litigation, a seemingly simple question may require checking four places. The client name lives in the practice manager, the case number in a spreadsheet, the latest order in a local download, and the next action in one person's calendar. Searching only by client fails when there are several matters, similar entity names, or documents saved under inconsistent filenames.

Adding another search box will not fix the problem. The firm needs stable relationships between records and a visible way to know what was observed, when, where it came from, and who must act. That is the role of an operational second brain: reduce context loss without pretending that software can exercise a lawyer's professional judgment.

These notes describe a process pattern, not a real client matter or legal advice. Each firm must adapt deadlines, controls, and responsibilities to its jurisdictions, practice areas, and professional obligations.

## The matter, not the chat, is the unit of work

A useful query should not depend on remembering how someone named a folder. The minimum record needs a stable internal matter key and explicit relationships to:

- the client and represented party, under the appropriate permissions;
- the case number and court or jurisdiction;
- the parties and roles needed to distinguish matters;
- documents, with provenance, version, date, and a fingerprint for deduplication;
- the latest observed status and the evidence supporting it;
- the proposed next action, owner, candidate date, deadline source, and review state;
- the history of queries, changes, approvals, and exceptions.

The client name can find candidates, but it should not be the unique key. A name search should return matching matters and require a selection when the identity is ambiguous. The system must not combine case files because they share a surname, company, or lawyer.

Keep four concepts separate: **document received**, **procedural status interpreted**, **next action proposed**, and **task approved**. A new court order may trigger a review. It does not turn a model's inference into a litigation instruction.

A deadline needs the same treatment. The record separates the observed or calculated date, its source, time zone, rule applied, reviewer, and the calendar where it was confirmed. Until that review, it appears as pending data, not as a definitive deadline.

## Risk accumulates at the handoffs

The most consequential failures do not always begin in legal analysis. They often appear between systems:

- a notice arrives but is not linked to the right matter;
- a filing exists but is stored under a name the search cannot recover;
- two people download the same document and work from different copies;
- the portal changes while the practice manager keeps the old status;
- a date is copied without a time zone, source, or owner;
- a draft looks final because its review state is missing;
- a query with no results is interpreted as “nothing changed.”

These are operational patterns, not statistics or incidents attributed to a particular firm. Controlling them requires traceability, idempotency, and an exception queue. The guide to the [cost of copying data between systems](/blog/cost-of-copying-data-between-systems/) explains the same problem across other operations: if every handoff strips away context, the organization has to verify everything again.

## A staged architecture

### Stage 1: an organized repository and a shared index

Start with Drive or an equivalent repository the firm is already authorized to use. Define a matter structure, naming convention, and index that connects every file to the internal matter key. The firm does not need to migrate its entire archive to learn from a pilot.

The pilot can cover one practice area, one team, and a bounded group of active matters. Inventory sources, permissions, owners, and retention rules. Mark which copy is authoritative and which files are working notes. Organized folders help; the shared index is what makes information retrievable without relying on the memory of the person who created them.

Before adding AI, verify that a person can open a matter and answer: what arrived, where it came from, whether it already existed, who must review it, and which next step is pending.

### Stage 2: connectors to authorized court portals

Treat each portal as a separate integration. Use an API, export, inbox, or automated access method only when access rights, credentials, and terms allow it. Record the queried identity, time, search criteria, outcome, and any limitation.

Do not design the workflow on the assumption that every portal provides the same capabilities. One may expose documents; another only a status; another may require a manual lookup. The absence of a connector does not authorize scraping, and an incomplete result does not confirm that nothing changed.

When a portal is unavailable, a session expires, or the matter does not match unambiguously, the system opens an exception. A person resolves the identity or performs the lookup and records the same minimum evidence that the connector would have produced.

### Stage 3: a monitoring and filing agent

The monitoring agent queries only authorized sources and matters. It compares the response with the previous observation, downloads a document when permitted, and proposes its link to a matter. Before filing, it computes a content fingerprint and checks identifiers, filename, date, and provenance to prevent duplicates.

Its output needs more detail than “case updated.” It should be a reviewable event:

| Field | Example state, not real case content |
| --- | --- |
| Matter | Exact match / ambiguous / not found |
| Source | Authorized portal or inbox and query time |
| Change | New document / metadata changed / no observable change |
| File | Stored / duplicate detected / quarantined |
| Review | Pending, approved, or rejected by a person |
| Next step | None proposed / draft pending / task approved |

Writes must be idempotent: running the job twice should not create another copy or another task. If two documents have the same name but different contents, neither silently replaces the other. If their contents are identical, the system keeps provenance without multiplying files.

### Stage 4: a query and drafting agent

Natural-language questions become useful only after the team trusts the index and archive. The agent retrieves matters through identifiers and permissions, shows the sources it used, and separates documented facts from inferences.

It can answer, “these are the latest associated documents, and this is the recorded pending task.” It should not state that a procedural status is final when the source does not establish it. It also should not calculate or promise a legal deadline as though one universal rule applied.

For drafting, the safe sequence is **retrieve → cite the internal source → prepare → review → approve**. The agent can organize the record and produce a first version of an email, summary, or filing within an approved template. Before using it, the lawyer checks the complete file, legal citations, current authority, strategy, and final wording.

The distinction between [copilot and autopilot](/blog/copilot-or-autopilot-ai-agent-autonomy/) is particularly useful here: permission to query and prepare does not confer permission to file, send, or decide.

## Permissions and guardrails belong in the first version

Access follows the matter and the role. An agent should not receive firm-wide visibility merely because centralized search makes that technically possible. Apply least privilege across the repository, portal, model, logs, and people. Separate credentials by connector and keep secrets out of prompts and documents.

Every output should retain:

1. the matter and identity used for the query;
2. retrieved sources and versions;
3. observation time;
4. transformation or summary performed;
5. confidence level or exception reason;
6. reviewer and decision;
7. outcome of any authorized write.

The system stops for ambiguous identity, conflicting sources, an unreadable document, insufficient permission, an unavailable portal, or a decision that requires legal judgment. “I could not verify this” is a valid outcome. Filling the gap with a plausible answer is not.

## What not to automate

Do not delegate litigation strategy, final argument selection, verification of legal citations, definitive deadline calculation, or the decision to file or communicate an action. The agent should not sign, submit to a court, accept notice on someone's behalf, or promise an outcome to the client without an explicit, authorized, and reviewed workflow.

Human approval is not meaningful when the interface hides the executable content. The review must show the document, matter, sources, changes from the previous version, destination, and exact action. The lawyer approves what will actually happen, not merely a fluent summary.

## Verify on day D

Before publishing a product claim or activating the pilot, verify on that same day with the firm and official sources:

- whether the portal permits the proposed access method and under which terms;
- which API, export, connector, webhook, or notification actually exists;
- which fields, documents, and history it provides, and at what latency;
- how identity, sessions, MFA, limits, and regional availability work;
- which retention, residency, encryption, audit, and data-use controls each repository, provider, and model offers;
- which actions can execute and which can only be prepared for review.

These capabilities vary by portal, account, jurisdiction, and provider. A discovery observation or demo is not sufficient evidence to publish them as available features. If something remains unconfirmed, describe it as a design requirement or keep that step manual.

## After filing: case law alerts and corporate work

An optional second stage can monitor potentially applicable case law. It should preserve court, date, identifier, source text, and inclusion criteria. The agent can flag a match for review; the lawyer determines currency, authority, relevance, and use. An alert is not legal advice.

Contracts and corporate templates can come later as another domain, with their own permissions, taxonomy, and approvers. Combining them with the first pilot expands scope before the litigation core has shown that it can connect matters, documents, and next actions reliably.

## A pilot that produces evidence

Choose a small population of active matters and measure operational quality: correct matches, duplicates prevented, changes detected, exceptions, human corrections, tasks with an owner, and time from observation to review. Do not promise ROI or autonomy from a demo.

During the pilot, compare the index with the repository and authorized source. Review every draft. Test matters with similar names, repeated documents, expired sessions, portals with no changes, and ambiguous results. Expand when the team trusts the evidence and knows how to resolve exceptions, not when the agent produces more text.

Kiia can help turn this map into a pilot with permissions, connectors, and professional review. The first deliverable is an operational case file that lets the team find the right context before making a decision.

## Frequently asked questions

### Does a litigation second brain replace the lawyer?

No. The system organizes information, detects changes, prepares summaries, and proposes drafts. The lawyer retains litigation strategy, validates facts and citations, decides each action, and remains responsible to the client and the court.

### Do we need to migrate the firm's entire stack?

No. Start with a shared index over the authorized repository the team already uses. The first version should link client, matter, documents, and next action before replacing tools or automating writes.

### Where do we start without automated access to every court portal?

Choose one jurisdiction or portal with an authorized access method and a small set of active matters. Keep a manual review queue with the same minimum record for everything else. Do not use unauthorized scraping or turn missing access into invented data.