Grella
Back to Guides & Insights

Legal AI Agents: What Should a Lawyer Delegate?

Define legal AI agent tasks, source access, permitted actions and lawyer review. Includes a delegation brief and a clearly fictional witness-question example.

An illustrated task route inside a defined boundary, ending at a marked lawyer-review checkpoint.

Delegate a defined task to a legal AI agent with explicit sources, permissions and review points. Make clear what it may prepare, what it may change and which actions need a lawyer's approval.

An AI agent is a system that can use tools to carry out several steps towards a task. A legal product might search a document set, extract passages and prepare a draft. Another might also write to connected systems. The word agent alone tells you little about its authority.

This article provides a delegation brief and a fictional example for lawyers supervising that work. Check each product's actual permissions before assigning a task.

Start with work you can inspect

Choose an output with a clear boundary: candidate chronology entries, a comparison of specified documents, an issue list tied to passages or a first factual outline. The reviewer needs to be able to trace material assertions and identify omissions.

Be cautious with vague instructions such as “handle the matter” or “prepare the best response”. They leave the system to guess the scope, relevant material and stopping point. A useful assignment names the exact piece of work and the decision that follows it.

Harvey's March 2026 Agent Builder announcement describes configurable agents for legal workflows. This is a supplier description; the firm's own evaluation should test the permissions and review controls it needs. 1

Separate preparation from consequential actions

Write down the allowed actions before the run. Reading an approved file, proposing a factual row, changing a shared record and sending a message each has a different effect.

For an initial factual task, a firm might allow the agent to search a defined packet and save candidate wording for review. It might require approval before changing a shared factual record and prohibit external messages, filing, negotiation or deletion. These are proposed operating boundaries, not a statement that every product can enforce them.

Check the actual controls. If the tool cannot keep the agent within the required boundary, narrow the task or choose a different method. A prompt asking the agent to be careful is not equivalent to restricting its permissions.

Use a delegation brief

Keep the brief with the result so the reviewer can see what was requested. Include:

  • Task: the specific work to prepare and why it is needed.
  • Inputs: the approved records, source version and any supplied issue list.
  • Scope: relevant people, dates, questions and exclusions.
  • Output: the format, required fields and source references.
  • Permissions: what may be read, created or changed.
  • Limits: missing material, unresolved questions and actions that are prohibited.
  • Stop points: conditions requiring a question or approval.
  • Reviewer: the person who checks the result and decides its next use.

For example, require the agent to stop if an essential attachment is absent, a source cannot be opened or completing the task would require access outside the approved packet. Ask it to record the limitation rather than invent an answer.

A fictional assignment: prepare witness questions

Suppose a lawyer needs candidate questions for a witness who discussed a disputed notice. The approved packet contains two emails, a meeting note and a document index. The assignment is to identify topics to explore, not to assess the witness's honesty or make a finding about whether notice was legally effective.

The brief asks for the proposed question, the source that makes it relevant, a precise reference and any account that differs. The output must attribute statements to their speaker and distinguish a recorded event from an inference. This is a fictional work method, not a report of an agent's performance.

An acceptable candidate question might ask the witness to explain a discrepancy between the recorded sending time and the account of a later call. Its source references let the lawyer inspect both records before deciding how to put the question.

If the meeting note refers to an attachment that is missing, the output should identify the gap. It should not supply the contents of the attachment or treat the absent document as confirmation. The lawyer decides whether to obtain the document and rerun the task.

The witness-preparation guide explains how to organise that source record. Here, the focus is the agent's assignment and authority.

Review during the task and at the end

For a longer run, put checkpoints where a mistaken assumption could affect later steps. Inspect the selected sources before extensive drafting. Resolve an ambiguous issue before asking the agent to produce several related outputs.

At the final review, compare the result with the brief and the approved packet. Check material assertions against sources, search for important omissions and consider whether the output answers the assigned question. Verify cited legal authorities separately where the task includes research about the law.

ABA Formal Opinion 512 addresses appropriate verification and lawyer judgment under the US Model Rules. It does not set one review percentage for every tool and task. Local professional rules, court directions and client requirements still need to be checked. 2

Record whether the lawyer accepted, corrected or left each material point unresolved. Saving a result is not the same as approving it for client advice or filing. The summary-verification guide provides an assertion-by-assertion review method.

Treat instructions in documents as source content

Source material can contain wording that looks like an instruction to the system. It may be irrelevant text, a quoted request or a deliberate attempt to redirect the task. OWASP describes this last risk as prompt injection. 3

The delegated brief should require the agent to treat document text as content to analyse. It must not authorise a change of assignment. Enforce tool permissions and approval boundaries through the product's controls as well.

The service also needs appropriate controls over tools and access. Ask the supplier to demonstrate what happens when a source requests a broader search, a write action or an external message. Confirm that the required permission and approval boundaries still apply.

Use synthetic material for that check. Do not introduce an unsafe instruction into a live client workflow merely to see what happens.

Keep the task history and source version

Retain the brief, packet version, outputs and review record. When material changes, decide whether to rerun the task and which earlier work needs review. A revised answer should not quietly erase the fact that a lawyer relied on an earlier version.

Ask how the product records actions and failures, including whether it reports an incomplete run. If it cannot produce the promised history, record that limit and consider whether it is adequate for the intended use.

Use Grella within its actual scope

Grella organises source-linked matter information for factual work. Its first-party MCP integration provides authorised read-only access to matter context. Read-only access does not authorise an external agent to edit matter records, send messages or file documents.

For any agent used alongside Grella, assess its own permissions, data handling and review controls. Use only public, synthetic or otherwise expressly approved material while the proposed data use is being evaluated.

Start with a bounded assignment whose result a lawyer can inspect. Expand its scope only when the firm has evidence that the workflow and controls suit the next task.

Explore read-only MCP

All guides & insightsBack to top