Best practices for agentic legal data: a field guide for legal data teams

Ask a legal operations analyst what the week looked like and the answer is rarely the forecast. It is the hold that named two systems when the data lived in eleven tables, the renewal date that came out of the CLM as a blank, the invoice batch paid before anyone saw the rate was wrong, and the general counsel's question about what is still in the warehouse past its retention period. The data behind legal operations is small next to the rest of the enterprise and unusually unforgiving. A miss shows up in a dispute, an audit or a regulator's letter.

Three duties meet in the warehouse: preserve what a case needs (in the United States, Federal Rule of Civil Procedure 37(e) addresses what a court may do when electronically stored information is lost because a party did not take reasonable steps), limit what is kept (GDPR Article 5(1)(e)) and protect client information (ABA Formal Opinion 512). Replicas, snapshots, extracts and clones are where those duties collide, and legal data teams are asked to prove, on any day, that they did not.

Our view: the data work behind those duties is repeatable and agents should do it, while attorneys keep every legal judgment. Agents map, check, flag and keep the record. Named people place holds, call privilege, delete and dispute. That line is the design of everything below, and the full playbook goes deeper. The same shape recurs across the public sector and legal data teams group.

The old world

Monday, 07:30. Litigation counsel places a hold on a dispute and names two source systems and three custodian groups. The warehouse carries the same data in places the notice does not mention: a reporting replica, a nightly extract to an analytics workspace, two dashboards and a developer clone. The records team's retention job is scheduled for 22:00 and nobody has connected the two. The same week, a batch of LEDES files goes into the payment queue, a CLM export changes its date format and the renewal calendar quietly loses a column. Every answer is a project, and each one starts with someone hunting through tables from memory.

The new world

Same Monday with Data Workers. The Data Context & Catalog agent finds the tables the matter touches and follows lineage to every copy before 08:00. Three of tonight's purge candidates overlap the hold, so the Autonomous Data-Conductor holds the purge list and sends one decision to the hold attorney and the records owner, with the map and how each item can be undone. The attorney confirms the scope and adds an exhibit export only a person knew about. The retention job runs at 22:00 against a list with no held assets, and the record of who confirmed what is waiting on Tuesday morning.

The eight practices below make that Monday possible. At a glance:

The practices, one by one

1. Map every hold to every copy of the data, from lineage and not from memory

The scope of a hold in the warehouse is rarely the system the notice names, and the map is the first thing opposing counsel or a regulator will ask for.

Why it's harder than it looks: Copies are made by jobs, not people, so they appear on no list. dbt knows its models, the BI tool its dashboards and the orchestrator its schedules; none holds the whole path. Some copies, such as a hand-maintained export of exhibits, are visible to no tool, so a map from lineage is a strong start and never the final word.

1. 1.The Data Context & Catalog agent runs search_datasets for the systems, matter numbers and custodian groups in the hold.
2. 2.It follows lineage forward with trace_cross_platform_lineage to every replica, extract, dashboard and clone, and sizes the reach with blast_radius_analysis.
3. 3.The Data Access & Governance agent routes the proposed scope with request_governance_review.
4. 4.The hold attorney confirms or changes the scope, adding what the agents could not see. Only then does auto_tag_dataset tag the approved assets as under hold. Preservation itself is applied by your hold process and platform teams.

2. Check every purge and cleanup list against open holds

Retention jobs and holds are owned by different people on different clocks. The schedule does not know about the hold, and the hold register does not name tables.

Why it's harder than it looks: A check at the start of a hold does not survive the copy made on Wednesday or the purge list built on Friday. It has to run against every proposal, every time, as a routine and not a reminder.

1. 1.The Data Context & Catalog agent lists stale and duplicate copies with detect_dead_assets, and the Cost Savings & Data Cleanup agent proposes which to retire.
2. 2.A standing routine, "check every retention and cleanup proposal against open holds", runs under the Autonomous Data-Conductor and holds anything that overlaps the hold map.
3. 3.request_governance_review sends one decision: the overlap, the map, and how each item can be undone.
4. 4.The hold attorney and the records owner decide. Agents never delete.

The effect on elapsed time, across six routine tasks:

The biggest change is the retention exposure report: from about 2 weeks to about half a day. Agents find, trace and prepare the evidence in one pass.

3. Check outside counsel invoices against rate cards the day they land

Reviewing a batch after payment is recovery, not control. The LEDES files that carry the lines are structured enough to check by rule on arrival.

Why it's harder than it looks: Rates differ by timekeeper, matter and year, with amendments. Approved timekeeper lists move, task codes are used for the wrong phase and the same entry can appear on two invoices. The rules live in guideline documents and the e-billing platform, while the data team sees only the output file.

1. 1.The Connectors agent confirms the batch landed with get_connector_status, and get_dbt_run_history shows the spend models ran.
2. 2.The Quality Monitoring agent runs run_quality_check on every line: rate cards, approved timekeepers, valid task codes, duplicates. get_anomalies surfaces a firm or phase whose pattern moved.
3. 3.The Data Context & Catalog agent ties matter, phase and spend to the governed definitions with resolve_metric, and generate_audit_report records which checks ran.
4. 4.The matter owner opens a short exception list and decides whether to reduce or dispute. Agents never contact the firm.

4. Check contract metadata every morning, not when a renewal passes

A renewal or notice window that passes unseen is a business loss with a date on it, and the field that drives the calendar is usually the one nobody validates.

Why it's harder than it looks: CLM extraction fails quietly. A date is read in the wrong format, a notice period is blank, an amendment is not linked to its parent. Nothing errors, so the calendar looks fine until the renewal passes.

1. 1.The Schema Evolution agent catches a changed CLM export the day it arrives with detect_schema_change, and assess_impact lists the calendars and dashboards that read it.
2. 2.The Quality Monitoring agent runs run_quality_check every morning on completeness and consistency of the obligation fields, and holds a freshness target on the calendar table with set_sla.
3. 3.Exceptions go to the CLM administrator and the contract owner with the contract and field named. They correct the system of record.
4. 4.Agents do not read the contract or interpret a clause. Renew, renegotiate or terminate stays with the business owner and counsel.

5. Keep one governed definition of matter, spend and renewal date

The general counsel's dashboard, the spend forecast and any AI assistant a lawyer asks must give the same answer.

Why it's harder than it looks: "Matter status" means one thing in the e-billing platform, another in the hold register and a third in finance, and a closed matter can have an open hold. "Renewal date" can mean term end or notice deadline. Each report quietly picks one.

1. 1.The Data Context & Catalog agent records each definition with define_business_rule: matter, status, spend, renewal date, notice deadline and retention category, each with an owner.
2. 2.mark_authoritative and get_authoritative_source point reports and assistants at the certified table, and resolve_metric answers from the definition.
3. 3.The Quality Monitoring agent adds tie-outs with create_quality_tests_for_pipeline: spend to the matter master, contracts to the vendor master.
4. 4.The Director of Legal Operations Analytics approves each definition change.

6. Scope access to matter data by the matter team, and keep the walls in the warehouse

Matter teams, ethical walls and need-to-know change weekly, and the warehouse has to hold the same walls as the document system.

Why it's harder than it looks: Access is hand-built, ticket by ticket, and rarely revoked. A matter number present in billing but missing from the matter master is a gap in the wall. Privileged tables are best kept out of reach of agents altogether.

1. 1.Start with exclusions. Name the matter and document tables agents may never touch and exclude them entirely. Every allowed access is logged.
2. 2.The Data Access & Governance agent checks each request with check_policy and enforce_rbac, and scan_pii finds sensitive columns in tables agents may see.
3. 3.A change to a matter team goes to the matter owner through request_governance_review with the full diff. The grant is applied through your identity tooling and recorded.
4. 4.The Quality Monitoring agent flags matter numbers in billing that are missing from the matter master. Who is walled off stays a decision for your conflicts and ethics function. See also zero-ticket data access.

7. Make retention a fact, with an exposure report on demand

A retention schedule is a statement of policy. Whether the warehouse follows it is a different question, and "we keep everything because we cannot prove what is safe to remove" is how data outlives its schedule.

Why it's harder than it looks: Schedule categories are legal ideas such as "contracts"; tables are physical. The mapping is hand-built, goes stale and is complicated by holds and copies. A report assembled once for an audit is out of date the next week.

1. 1.The Data Context & Catalog agent proposes a schedule category per data set with auto_tag_dataset and keeps owner and category current with generate_documentation. See data classification.
2. 2.check_staleness and detect_dead_assets list what is past its schedule, by system and category, with held assets shown separately.
3. 3.The Connectors agent adds get_snowflake_usage, so the report shows which stale tables are still being read.
4. 4.The records and information governance manager approves the category mapping. The report proposes; the records owner runs deletion after approval, and the attorney decides where a hold may apply.

8. Put every legal decision in front of a named person, with the evidence attached

Autonomy in a legal department is credible only if the decisions that carry legal weight never move. The aim is to make the human decision fast and well informed, not to remove it.

Why it's harder than it looks: Approvals by email leave no record, and a pile of alerts gets approved without being read. An approver shown a diff without its blast radius cannot judge it, and an agent that can approve its own work defeats the point.

1. 1.The Autonomous Data-Conductor sends one decision, not a pile: the change, what it affects and how to undo it. See how approvals work for AI data agents.
2. 2.request_governance_review routes by class: hold scope to the hold attorney, deletion to the records owner, invoice reductions and access to the matter owner. No agent approves its own work.
3. 3.The Observability agent keeps get_audit_trail of what each agent did, and detect_drift watches the agents themselves.
4. 4.generate_audit_report produces the record: scope, who confirmed it, what was excluded and when. If an owner keeps reversing an agent's changes, that domain stops acting on its own and hands back to a person. This is guidance on data operations, not legal advice.

Autonomy where work is reversible and a named person where it matters looks like this by task class:

In this illustration lineage and docs upkeep closes autonomously 86% of the time. For hold, privilege and disclosure decisions, autonomous closure is 0% by design.

Designing the autonomy ladder

Autonomy is set per task class, not per tool. L0 is a person doing the work, L1 is agents observing and reporting, L2 is agents proposing with a named approver, L3 is agents acting reversibly with a rollback point and a check afterwards, and L4 is agents acting on their own inside the domain's standing missions. L0 to L2 run today. L3 and L4 are where a domain can go on its own review record, never a default and never on a calendar.

The operating model: who owns what

Agents change who does the work, not who is accountable for it:

The swarm behind the practices

No single agent delivers these practices. Each is a hand-off between specialists, coordinated under the autonomy you set per domain.

The Cost Savings & Data Cleanup agent proposes cleanup only for assets that are not held. Data Context Wizard holds one governed definition of matter, spend and retention category. The Autonomous Data-Conductor holds anything that touches a hold. Spellbook Data Catalog, in preview, makes each legal data set discoverable with owner, lineage and hold status.

What disappears

• •The hold map drawn from memory on the day the notice goes out.
• •The purge that runs over held data and is found when opposing counsel asks.
• •The invoice paid at the wrong rate and caught, if ever, a quarter later.
• •The renewal that passed because a date field was blank.
• •The retention audit that starts with a month of data pulls.

The magic is not any single agent. It is that the data back office keeps running, and every action leaves a signed receipt and a tamper-evident audit trail, so the team can show what happened and undo it. See how to roll back an agent's change and how Data Workers handles PII.

A Director of Legal Operations Analytics' scorecard

Targets for each quarterly review with the general counsel. They are goals for a maturing deployment, not results:

• •Hold data map for a new matter: from about 2 days to about 1 h
• •Outside counsel invoice batch checked: from about a week to about 2 h
• •Retention exposure report: from about 2 weeks to about half a day
• •Held assets on any purge or cleanup list: target zero, checked on every proposal
• •Contract records with blank obligation fields: each flagged the day it arrives
• •Lineage and docs upkeep closed autonomously: targeting 86% as the deployment matures

Where this goes next

Once the receipts justify it, a domain can move reversible upkeep to L3: lineage, documentation and the daily contract checks. The same agents extend to privacy inventory work, which pairs with GDPR lineage automation. Where the data stays is covered in where your data goes. The legal decisions stay where they are.

The climb: from assisted to autonomous to agentic

Our thesis is that the data platform climbs in stages, and that the hard part of data work was never knowing what to do but doing it. For legal data teams:

• •Assisted. Agents work alongside your team, show what needs doing and propose every fix with a receipt. Holds, tagging, access and retention proposals always go to a named attorney or owner.
• •Autonomous, under your governance. Routine work runs on its own: lineage and documentation stay current, contract fields are checked every morning, invoice files are checked when they land.
• •The agentic enterprise. Legal data becomes continuous: every hold mapped, every contract date checked, every retention question a query. Attorneys decide, with the data ready.

The pilot: how legal data teams start

• •What we connect. Your warehouse, dbt project and orchestrator, plus exports from your matter, e-billing, CLM and hold platforms, over MCP, inside your infrastructure. Nothing migrates, and excluded tables stay excluded.
• •Scope. The hold data map and a retention conflict check for one business unit's data, at L2.
• •First week. Agents run at L1 across the scoped domain, mapping pipelines, definitions and lineage and showing the fixes they would have made. A first map of an existing hold often finds a copy nobody listed.
• •At day 30. We review the impact metrics against your baseline: hold data map from about 2 days to about 1 h, invoice batch checked from about a week to about 2 h, and retention exposure report from about 2 weeks to about half a day.
• •The guarantee. In a 90-day pilot, ten engineering hours per data engineer per week are recovered against a baseline both sides sign on day one, or the $7,500 fee is refunded.
• •Cost. Start with a pilot ($7,500 one-time, a 6 to 12 week pilot, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.

The pilot is the start of a longer curve:

By month 12, more than 34% of agent actions run fully autonomously, while holds, privilege, deletion and disclosure stay with named people.