Where Code Meets Court: Building AI for the Legal-Technical Frontier

1. Why legal AI is harder than it looks

Developers who build their first legal AI product often discover the same thing: the hard part is not the law, and it is not the technology — it is that legal work demands both at the same time, with a very high bar for accuracy.

General AI tools already save lawyers hours on everyday research. And AI helps engineers reason through complex technical systems every day. Patent law is unique in that it demands both capabilities simultaneously: a practitioner must search across millions of prior-art documents while also comprehending the technical intricacies of a genuinely novel invention — often in a field they have never worked in before.

That combination — breadth of legal corpus, depth of technical subject matter, and zero tolerance for error — is why patent law has become the canonical benchmark for what is actually possible with LLMs in professional practice. It is also why the profession is undergoing more radical change than almost any other legal field.

The lesson for developers: the difficulty of patent law is a useful stress-test for any legal AI system you build. The patterns that work here generalize. The shortcuts that fail here will fail you in less demanding legal domains too.

The two-domain problem

Every legal AI product operates inside at least one domain: a corpus of statutes, cases, contracts, or regulations. Most legal AI products can get away with a single domain. Patent law cannot.

A patent attorney must:

1. Understand the invention — often a novel semiconductor process, a new drug delivery mechanism, or a distributed systems architecture — well enough to describe it precisely in legal language.
2. Search prior art — across patents, academic papers, product literature, and standards documents — to determine whether the invention is truly novel.
3. Apply legal standards — novelty, obviousness, written description, enablement — to the technical facts they’ve assembled.

An AI that is good at legal reasoning but cannot understand the technical domain will miss prior art. An AI that understands the technology but does not know the legal standards will produce work product that does not hold up to scrutiny. You need both, deeply integrated.

2. The three failure modes of legal AI

Before designing a legal AI system, you need to understand exactly how they fail. Legal AI has three characteristic failure modes that do not show up in most other enterprise AI applications.

Failure mode 1: Hallucinated citations

An LLM that has absorbed legal text learns that claims are supported by citations. When it cannot find a real citation, it will invent one — a case name, a patent number, a statutory reference — that looks plausible but does not exist. This is catastrophic in legal work, where every claim needs to be traceable to an actual document a court or examiner can inspect.

The fix is not to prompt the model to “only cite real sources.” The fix is architectural: the model must not be allowed to produce citations that were not present in its retrieved context. Generation must be grounded in retrieved documents, not in training data.

Failure mode 2: Misapplied legal standards

Legal standards are precise in ways that general language is not. “Obvious” in patent law has a specific meaning under Graham v. John Deere and KSR that is different from its everyday sense. “Anticipated” means something exact. “Person having ordinary skill in the art” is a legal construct, not a description of an average engineer.

A model that has read case law may learn these terms without internalizing their precise application. It will use the right words to reach the wrong conclusion. The fix is evaluation-driven: you need test cases where the correct application of each legal standard is known, and you need to measure your model’s performance against those cases before deploying.

Failure mode 3: Domain-blind retrieval

Most RAG systems retrieve by semantic similarity. In patent law, semantic similarity is insufficient because prior art can be technically equivalent to an invention without using any of the same words. A patent covering a “latching mechanism” is prior art to a patent on a “snap-fit connector” if they accomplish the same thing by the same means — but a vector search on “latching mechanism” will not surface the second document.

Legal retrieval requires understanding the function and structure of what is being described, not just its surface vocabulary. This usually means expanding queries through the model itself before retrieval, not relying on the original claim language alone.

3. Designing a dual-domain retrieval pipeline

The core engineering problem in patent AI is retrieval: how do you find the right documents across two very different corpora — legal documents indexed by legal concepts, and technical prior art indexed by engineering concepts — when your query lives in both domains at once?

Step 1: Decompose the query

A single patent claim like “A method for reducing latency in distributed consensus systems using a novel leader election protocol” contains:

• A technical domain: distributed systems, consensus protocols
• A legal framing: novelty is at stake, so you need prior art search specifically
• A structural description: the function (reduce latency), the means (leader election), and the context (distributed consensus)

Before any retrieval happens, ask the model to decompose the claim into these three components. This decomposition drives different search strategies.

Step 2: Run parallel retrieval streams

Use the decomposed query to run retrieval in parallel across at least two streams:

Legal stream: Search the patent corpus (USPTO, EPO, WIPO) using structured patent classification codes (CPC/IPC) as well as keyword search. Patent classifiers are a controlled vocabulary that cuts through vocabulary differences — “leader election” and “primary node selection” share classification codes even if they share no words.

Technical stream: Search academic literature, standards documents, and product documentation using the technical description. This is where vector search is most useful — academic papers describe the same phenomenon in many different ways.

Step 3: Cross-domain re-ranking

Retrieve broadly from both streams (top-50 from each), then use the model to re-rank the combined candidate set. At re-ranking time, the model can apply legal judgment: “Does this document describe the same function achieved by the same means as the claim, as required by the doctrine of equivalents?” This question cannot be answered by a vector similarity score.

Step 4: Grounded synthesis

Now, and only now, generate the output — a prior art analysis, a freedom-to-operate opinion, a claim chart. The strict rule: every sentence in the output must be attributable to a specific passage in the retrieved documents. Build your prompts to enforce this. After generation, run a verification pass that checks each citation against the source.

4. The unique compliance landscape of legal AI

Legal AI is not just technically harder than most enterprise AI — it is regulated differently. Developers who come from consumer or general enterprise backgrounds often underestimate this.

Unauthorized practice of law

In most jurisdictions, providing legal advice is restricted to licensed attorneys. An AI product that gives specific legal advice to end users may constitute unauthorized practice of law (UPL), regardless of disclaimers. The practical line that most legal AI products draw is between legal information (what the law says) and legal advice (what you should do given your facts). Products that stay on the information side of this line face less UPL risk.

For patent AI specifically, activities like drafting claims, preparing office action responses, and representing clients before the USPTO are all regulated activities. The clearest safe harbor is positioning the AI as a tool that assists licensed practitioners, not one that replaces them.

Confidentiality and privilege

Attorney-client privilege and work product doctrine create strict constraints on where legal data can flow. When you build a legal AI product:

• Data sent to third-party model providers may implicate confidentiality obligations. Enterprise customers will require data processing agreements and may prohibit certain data from ever leaving their infrastructure.
• Processing data on behalf of a law firm may make your company a “non-lawyer” with access to client confidences, which triggers professional responsibility rules.
• Audit logs — who asked what, what the model said, and what the attorney did with it — are increasingly important for malpractice defense.

Accuracy standards and error disclosure

In engineering, a 95% accurate system is often good enough. In legal work, a 5% error rate can mean a missed patent filing deadline (unrecoverable), a missed prior art reference (invalidates a patent), or a misquoted statute (sanctions). Legal AI products need explicit accuracy disclosures, recommended use cases, and clear warnings about the types of errors they are known to make.

Build your system so that uncertainty is surfaced, not hidden. A legal AI that says “I found 3 potentially relevant prior art references; you should verify whether these fully cover claim 4” is more professionally useful than one that confidently declares “No prior art found.”

5. What legal AI reveals about LLM capabilities at the frontier

Patent law did not become a frontier for AI by accident. It sits at the intersection of two things LLMs do best — synthesizing large document corpora and reasoning about novel technical problems — while also demanding the things that are hardest for current models: precise application of formal standards, reliable attribution, and reasoning about whether two things are “the same” at the right level of abstraction.

The obviousness problem

The non-obviousness requirement in patent law (35 U.S.C. § 103) is one of the hardest things to automate. Determining whether an invention would have been obvious to a person having ordinary skill in the art at the time of filing requires:

• Understanding what was known in the field at a specific historical date
• Modeling what a hypothetical skilled practitioner would have been motivated to combine
• Applying case law (KSR, Graham v. John Deere) to set the right level of skill and motivation

Current LLMs can engage with all of these questions, but they do so inconsistently. The model’s training data does not have a clean temporal boundary, so it may reason about “what was obvious in 2015” using knowledge it only has because of things published after 2015. This is a subtle but serious failure mode in prior art analysis.

The claim construction problem

Before you can evaluate any patent claim, you have to understand what it means — and patent claims are deliberately written in a way that is technically precise but lexically unusual. “Means-plus-function” claiming, “comprising” vs. “consisting of,” independent and dependent claim structures: these are conventions that trained patent attorneys internalize over years.

LLMs can be taught this vocabulary through fine-tuning or in-context examples, but they are not reliable without explicit scaffolding. When building patent AI, include claim parsing as a distinct step before retrieval or analysis: ask the model to restate each claim element in plain engineering language before doing anything else with it.

Where LLMs genuinely excel

Despite the challenges, there are tasks in legal work where LLMs provide unambiguous, large-scale value today:

• Corpus scanning: reviewing thousands of documents to identify the ten most relevant ones — a task that would take a paralegal weeks — is a natural fit for the long-context capabilities of current models.
• Drafting assistance: producing first-draft claim language, office action responses, or technical summaries for attorney review compresses the drafting cycle significantly.
• Cross-domain translation: explaining a novel technical invention to a non-specialist examiner, or translating dense legal language into engineering requirements, plays to LLMs’ core strength.
• Consistency checking: flagging inconsistencies between the specification and the claims, or between claims in a family of related patents, is a mechanical task LLMs do reliably.

6. Building legal AI that professionals will actually trust

Technical correctness is necessary but not sufficient. Legal professionals are trained skeptics who will abandon a tool the first time it confidently produces a wrong answer. Earning and maintaining trust with that audience requires a different approach than most enterprise AI products.

Design for review, not replacement

The legal professionals who adopt AI tools earliest are those who see the AI as a faster first pass, not an autonomous decision-maker. Design your product around this mental model. The output of your AI should be something a professional can review, check, and sign off on — not something they accept or reject wholesale.

Practically, this means:

• Every retrieved document should be accessible with one click
• Every generated claim should show the source passage it came from
• Uncertainty should be quantified where possible (“found in 8 of 12 retrieved documents” is more useful than “likely”)

Instrument for failure

Legal AI will make mistakes. The question is whether you know when it does. Build logging and feedback mechanisms into your product so that practitioners can flag errors, and so that you can identify systematic failure patterns. In high-stakes legal work, silent failures are more dangerous than noisy ones.

A well-instrumented legal AI product becomes a dataset for improvement. Every time a practitioner disagrees with an output and explains why, you have a potential evaluation case. Over time, your evals will represent the real-world failure modes of your specific system in your specific legal domain — which is more valuable than any generic benchmark.

Work with legal professionals from day one

The biggest mistake legal AI developers make is building the product before talking to the practitioners. Patent attorneys have deep, specific opinions about what makes prior art analysis trustworthy, what constitutes an adequate written description, and what the examiner is actually looking for. These opinions are not in any paper. They live in the practice.

Find practitioners who are curious about the technology — they exist, and they are increasingly easy to find — and treat them as collaborators in the design process. The best legal AI products are built by engineering and legal teams working in the same room, not by engineers who read the patent statute.

pip install anthropic httpx
export ANTHROPIC_API_KEY="sk-ant-..."

mkdir legal-ai-demo && cd legal-ai-demo
touch pipeline.py

import anthropic

client = anthropic.Anthropic()

DECOMPOSE_PROMPT = """You are a patent analysis assistant. Given a patent claim, extract:
1. Technical domain: the engineering field this claim belongs to
2. Legal frame: what legal question is being asked (novelty search, freedom-to-operate, etc.)
3. Functional elements: what the claim accomplishes (the function)
4. Structural elements: how it accomplishes it (the means)
5. Alternative vocabulary: 5 alternative ways to describe the same concept

Respond in JSON. Do not add explanation outside the JSON object."""

def decompose_claim(claim_text: str) -> dict:
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=1024,
        messages=[
            {"role": "user", "content": f"{DECOMPOSE_PROMPT}\n\nClaim: {claim_text}"}
        ]
    )
    import json
    return json.loads(response.content[0].text)

def retrieve_prior_art(query_terms: list[str], top_k: int = 10) -> list[dict]:
    """
    In production: call patent search API with structured queries
    built from query_terms. Here we return a stub.
    """
    # Replace with: USPTO PatentsView API, Espacenet OPS API,
    # or a vector search over your own patent corpus
    return [
        {
            "patent_number": "US10,123,456",
            "title": "Placeholder prior art document",
            "abstract": "This would be a real patent abstract...",
            "cpc_codes": ["G06F", "H04L"],
            "url": "https://patents.google.com/patent/US10123456"
        }
    ]

SYNTHESIS_PROMPT = """You are a patent attorney's research assistant.
Analyze the following claim against the provided prior art documents.

STRICT RULES:
- Only cite documents from the PROVIDED DOCUMENTS list below
- Every factual claim must include a [Patent: US_NUMBER] citation
- If you are uncertain, say so explicitly
- Do not reference any document not in the provided list

PROVIDED DOCUMENTS:
{documents}

CLAIM TO ANALYZE:
{claim}

Provide a prior art analysis with inline citations."""

def analyze_claim_against_prior_art(claim: str, documents: list[dict]) -> str:
    doc_text = "\n\n".join([
        f"[Patent: {d['patent_number']}] {d['title']}\n{d['abstract']}"
        for d in documents
    ])
    
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=2048,
        messages=[
            {
                "role": "user",
                "content": SYNTHESIS_PROMPT.format(
                    documents=doc_text,
                    claim=claim
                )
            }
        ]
    )
    return response.content[0].text

def run_prior_art_pipeline(claim_text: str) -> dict:
    print("Step 1: Decomposing claim...")
    decomposition = decompose_claim(claim_text)
    
    print("Step 2: Building retrieval queries...")
    query_terms = [
        decomposition.get("technical_domain", ""),
        *decomposition.get("functional_elements", []),
        *decomposition.get("alternative_vocabulary", [])
    ]
    
    print("Step 3: Retrieving prior art...")
    documents = retrieve_prior_art(query_terms, top_k=10)
    
    print("Step 4: Synthesizing grounded analysis...")
    analysis = analyze_claim_against_prior_art(claim_text, documents)
    
    return {
        "claim": claim_text,
        "decomposition": decomposition,
        "retrieved_documents": documents,
        "analysis": analysis,
    }

# Example
if __name__ == "__main__":
    claim = """A method for reducing latency in a distributed consensus system,
    comprising: electing a primary node using a randomized timeout protocol;
    replicating log entries from the primary to a quorum of follower nodes;
    and committing an entry when acknowledged by a majority of nodes."""
    
    result = run_prior_art_pipeline(claim)
    print("\n=== ANALYSIS ===")
    print(result["analysis"])

import re

def verify_citations(analysis_text: str, retrieved_documents: list[dict]) -> list[str]:
    """Returns a list of citation warnings for any patent cited but not retrieved."""
    retrieved_numbers = {d["patent_number"].replace(",", "") for d in retrieved_documents}
    cited_numbers = set(re.findall(r'US[\d,]+', analysis_text))
    
    unverified = cited_numbers - retrieved_numbers
    return [f"WARNING: Citation {n} not in retrieved context" for n in unverified]

Where to go next

• Watch the original talk for the full discussion of what is possible at the legal-technical frontier.
• The companion talk What legal agents inherit from coding agents from Legora covers how one team adapted coding agent patterns to legal document editing.
• For the agent architecture foundations underlying legal AI pipelines, see our Building Effective Agents lesson.
• For evaluation methodology — essential before shipping any legal AI — see Evaluating Agents at Scale.