What Legal Agents Inherit from Coding Agents: Lessons from Legora

1. The same loop, different domain

Software engineering and law look nothing alike on the surface. But strip away the vocabulary and both disciplines reduce to the same four-beat pattern:

1. Read — ingest unstructured information (a spec or a contract)
2. Think — apply domain expertise to understand what it means
3. Write — produce structured output (code or a redlined clause)
4. Verify — check the output against a standard (tests or a clause checklist)

Legora’s engineers noticed this isomorphism early. The company built legal-AI agents by asking a disciplined question: which coding-agent patterns can we inherit, which need translation, and which do we have to invent? That question is the frame for this lesson.

Legal AI is, in Legora’s framing, “tracking the same curve as software development, one cycle behind.” Coding agents moved from line autocomplete (2021) → multi-file editing (2023) → multi-hour autonomous tasks (2025). Legal agents started later but are climbing the same ladder, and the firms that understand what was already built for coding agents have a head start.

2. What transfers directly: the inherited patterns

Several coding-agent patterns move to legal with almost no modification. Legora leaned on three in particular.

Tool use

Coding agents routinely call external tools — a bash shell, a code search index, a type checker. The pattern of “model decides which tool to call, calls it, integrates the result” transfers directly. Legal agents call different tools: a legal database (for case law), a document management system, a regulation index, a citation verifier. But the orchestration architecture — maintain state, pick tool, parse result, decide next step — is unchanged.

This is also why multi-tool composition matters as much in legal as in coding. A contract due diligence agent might call a tabular extraction tool, then a web search for jurisdiction-specific regulations, then a citation checker — chained together in the same loop a coding agent uses to call grep, then a compiler, then a linter.

Long-context reasoning

Coding agents deal with repositories that may span millions of lines. Legal agents deal with entire matter files — hundreds of documents, prior correspondence, jurisdiction-specific precedents. The long-context handling techniques built for code (hierarchical summarization, smart retrieval, attention to which context to load for which sub-task) transfer directly.

There is one important calibration: legal documents are dense. A 10-page contract can require more sustained attention than a 50-file repository of utility code. Legora found that context management strategies tuned for code sometimes needed recalibration for legal precision requirements — but the underlying techniques came from the coding-agent playbook.

Retrieval-augmented generation

Both domains reward a model that knows when to retrieve rather than rely on training. Coding agents retrieve from the codebase. Legal agents retrieve from a body of law, prior client positions, and firm knowledge. The RAG architecture is identical; the retrieval targets differ.

3. What needs translation: adapted patterns

Some patterns transfer in shape but require substantive redesign to fit the legal domain.

Verification: from tests to playbooks

This is the most important translation, and the one with the most engineering depth.

In a coding agent, verification is cheap to automate: run a test suite, check the return code. Green means correct (or close enough). The feedback signal is binary, fast, and machine-readable.

Legal has no test runner. Correctness in a contract clause is not a boolean — it’s whether the clause meets the client’s risk posture, aligns with negotiation guidelines, and satisfies jurisdictional requirements. Legora’s answer: playbooks. A playbook is a codified set of internal standards — clause checklists, redlining preferences, negotiation positions — that an agent can run against a document just like a linter runs against source code.

The analogy is exact: a style linter checks code against a rule set; a playbook agent checks a contract against a firm’s clause library. Both produce annotated diffs that a human can review. Both enable the verify step without requiring a human to read every line.

The critical difference is that playbooks are richer and more ambiguous than lint rules. A linter rule is “no trailing spaces.” A playbook rule is “our standard indemnification clause must be present, or a human-approved substitute.” The model has to interpret, not just match.

Human-in-the-loop: from interrupt to orchestrator

Coding agents pause for human review when they hit a decision they can’t resolve — a merge conflict, an ambiguous requirement. The human unblocks them and the loop continues. The pattern of structured human checkpoints at decision nodes is the same in legal, but the role of the human shifts.

In a coding context, the developer is still writing code most of the time; the agent assists. In a legal context, the lawyer increasingly becomes an orchestrator — defining tasks, reviewing outputs, approving actions — rather than the primary drafter. This shift in workflow required Legora to redesign the UX around human review flows rather than inline suggestions.

The agent delivers finished, reviewable work products rather than mid-task interrupts. Human checkpoints are built into workflows at structured approval gates, not triggered ad-hoc. Every agent action is auditable — because in law, defensibility is a first-class requirement.

Agentic orchestration: from task to matter

A coding agent typically works within a bounded task: fix this bug, add this feature. A legal matter is more like a project with dozens of interrelated tasks, different timelines, and work products that depend on each other. Legora had to extend the orchestration model to track matter context — client, jurisdiction, prior positions — across sessions and across agent invocations.

This is the legal equivalent of memory in coding agents: persistent context that makes each subsequent task smarter than the last.

4. What had to be invented: legal-native patterns

Some things in legal AI have no coding-agent precedent. Legora had to build them from first principles.

The document editing UX

Coding agents edit files. The feedback loop is: make change → run tests → iterate. Legal agents must edit documents that lawyers will stand behind in court. The editing UX requirements are entirely different:

• Changes must be visible as tracked edits (the redline), not just a new file version
• Every change must be attributable (who or what made it, when, for what reason)
• The editing environment must integrate with the tools lawyers already use — Word, DMS platforms
• Approval must be a first-class concept: “accept this change” or “reject and explain why”

This led Legora to build native Word integration and embedded redlining rather than treating documents as blobs to be swapped out.

Bulk review with structured output

Legal due diligence often means reviewing hundreds or thousands of contracts to answer the same set of questions: “Does this agreement contain a change-of-control clause? What is the termination notice period?” Coding agents have batch processing patterns, but not at the document-times-question matrix scale that legal due diligence requires.

Legora’s tabular review addresses this: upload a set of documents, define a question set, get back a structured grid — one row per document, one column per question, each cell linked to the source passage. This is not inherited from coding agents; it’s a novel pattern built for the legal use case. The closest analogy is a spreadsheet formula evaluated across many rows, but the “formula” is an LLM query with citation grounding.

Defensibility as a design constraint

Code that produces a wrong answer fails a test. Legal output that is wrong can result in malpractice liability, professional sanctions, or client harm. Defensibility — the ability to explain and audit every agent decision — is a non-negotiable constraint with no close analogue in coding-agent design.

Legora’s response: complete audit trails for every agent action, human approval at critical decision points, and grounding of every output in matter and client context. The system must be able to answer “why did the agent flag this clause?” with a specific, traceable rationale — not just “the model said so.”

5. The three-category framework

Legora’s experience suggests a reusable design heuristic for anyone building agents in a new domain. When you map from a well-solved agent domain (like coding) to a new one, classify every design decision into one of three buckets:

The trap is treating everything as “invent.” Most agent work is “inherit” and “translate.” Unnecessary reinvention is the most common cause of slow domain-specific agent development. Conversely, treating everything as “inherit” and failing to do the translation work — especially on verification — produces agents that feel impressive in demos and fail in production.

The lesson Legora draws: spend most of your design energy on the translate column, because that’s where domain expertise turns into durable competitive advantage.

6. Applying this to your domain

The coding-agent-to-legal-agent comparison is a case study in a more general pattern. Any knowledge-work domain where humans currently do text-intensive, precision-critical work is potentially on the same curve: accounting, medical documentation, regulatory compliance, patent prosecution, insurance underwriting.

Before building agents in any such domain, run the three-category analysis:

1. Map the loop: What does read-think-write-verify look like in your domain?
2. Identify verification: What is your test runner equivalent? This determines agent quality ceiling.
3. Audit the toolset: Which tools already exist? What needs to be built?
4. Design for defensibility early: Who is liable if the agent is wrong? Build audit trails before features.
5. Find the bulk pattern: What is the document-times-question equivalent in your domain?

Domain: Contract compliance checking

READ:   Ingest a contract PDF and a set of regulatory requirements
THINK:  Identify which contract clauses touch each requirement
WRITE:  Produce an annotated contract with compliance flags
VERIFY: Check each flag against a playbook of required clause language

| Pattern              | Category  | Notes                            |
|----------------------|-----------|----------------------------------|
| Tool-calling loop    | Inherit   | Identical to coding agents       |
| Long-context RAG     | Inherit   | May need density tuning          |
| Test runner → ?      | Translate | Define your playbook format      |
| Human checkpoints    | Translate | Design approval UX for domain    |
| Bulk doc × question  | Invent    | Build domain-specific matrix     |

def check_against_playbook(document_text: str, playbook: list[dict]) -> list[dict]:
    """
    Run each playbook rule against the document.
    Returns a list of findings: {rule, status, excerpt, suggestion}.
    """
    findings = []
    for rule in playbook:
        result = run_agent_check(document_text, rule["prompt"])
        findings.append({
            "rule": rule["name"],
            "status": result["status"],     # "present" | "missing" | "non-standard"
            "excerpt": result["excerpt"],
            "suggestion": result["suggestion"],
        })
    return findings

def agent_workflow(task: dict) -> WorkProduct:
    """
    Agent produces a complete work product.
    Human reviews and approves before any action is taken.
    """
    draft = agent.execute(task)
    findings = check_against_playbook(draft.content, task["playbook"])

    return WorkProduct(
        draft=draft,
        findings=findings,
        requires_approval=True,       # never auto-submit
        audit_trail=agent.get_trace() # full action log
    )

@dataclass
class AuditEntry:
    timestamp: str
    actor: str          # "agent" | "human:<name>"
    action: str         # "tool_call" | "approval" | "rejection"
    tool: str | None
    input_summary: str
    output_summary: str
    rationale: str      # model's stated reason, or human comment

Where to go next

• Watch the original talk by Jakob Emmerling of Legora at Anthropic’s YouTube channel — the live product demo is particularly instructive.
• For the foundational agent architecture patterns referenced throughout this lesson, see Building Effective Agents.
• For how to decide whether a given piece of logic belongs in a tool, a skill, or a subagent, see Tool, Skill, or Subagent?.
• Legora’s public writing on The Year of Agents in Legal AI expands the domain-curve analysis with case studies.