Context Engineering in Patent Work
Why drafting, office-action response and FTO analysis belong neither in a single prompt nor in a single chat, and how to structure them instead.
Article last updated on 25 April 2026
Core message: Patent work means working with many different documents. Applications under examination, prior art, invention disclosures, examination reports, commentary, product specifications. Dumping all of this into a single chat produces a mixture of everything and none of it precise. Context engineering means preparing exactly the context each step needs, and nothing beyond.
The three stages
Prompt engineering, prompt chaining and context engineering are an evolution, not alternatives. Each stage solves a problem of the previous.
- Stage 1: single prompt. You ask one question and get one answer back. Works for isolated tasks like a wording question, a definition, a short summary. Breaks as soon as the task requires several reasoning steps or several inputs. "Draft a claim set for this invention disclosure and write the description too" is already too much for a single prompt.
- Stage 2: prompt chaining. You split the task into steps and give each step its own prompt. First assess the invention, then compare it with the prior art, then draft the claims, then the description. Each step takes the output of the previous as input. Works inside one long chat, as long as the context window holds and all steps need the same context. Breaks when the steps need different contexts or poison each other.
- Stage 3: context engineering. You rebuild the right context for each step from scratch. Different chats, different roles, different document excerpts. At the end of each chat you consolidate the result into a handover prompt for the next chat. You separate confidential parts from what goes into the cloud. You verify claims in a fresh chat that has not been biased by the production work. This is the approach that can handle a 300-page file, several prior-art references and an invention disclosure at the same time without the contexts bleeding into each other.
Why this matters especially for patent practitioners
Our documents are long, heterogeneous and confidential. A patent application runs 40 to 200 pages, a file history several thousand. An invention disclosure arrives as a hand-written Word file, an examination report as a scanned PDF. The model needs to distinguish "unpublished invention" from "freely available D1", and it can only do that when the context is clearly structured.
The reflex to load every relevant document into a single chat and then ask questions leads to context contamination. The model mixes invention features with prior-art features, it cites from the wrong document, and by the second or third prompt it loses the separation between "our claim" and "the prior publication". Context engineering separates these levels before the model can mix them.
Six context-engineering patterns for patent work
1. Document triage before the first prompt
Before the first word goes to the model, the document itself is prepared. Which paragraphs of the application are relevant to the question? Which columns of the prior art belong in the context? You cut what is not needed. A claim-construction prompt does not need the drawings description, and a problem-solution prompt does not need the definitions section of the prior-art document.
2. Chain per task, not chain per chat
Every logically separate step gets its own chat with its own system prompt. Invention assessment runs in Chat 1, the comparison against each prior-art reference in its own chat (Chat 2 for D1, Chat 3 for D2), claim brainstorming in Chat 4. The system prompt for Chat 2 can be phrased such that the model has no knowledge of what Chat 1 assessed, and no idea that a second prior-art reference even exists. This prevents bias and lets every step think afresh.
3. Consolidation prompt at the end of each chat
Before you leave a chat, ask the model to compress all facts, decisions and open questions into one self-contained prompt that a new model instance can continue without seeing the chat history. That handover prompt becomes the entry point of the next chat. It is the only information that crosses the boundary, and that is intentional.
4. Fresh context for verification
Verification does not belong in the chat that produced the artefact. A model that has just drafted a claim is a poor judge of its own draft. For evidence-citing, self-reflection and devil's advocate passes, open a new chat with the finished output plus the source document and let the model review blind. The source document must be present verbatim, paraphrases do not count.
5. Confidentiality isolation
What makes the invention novel stays out of the cloud context or is replaced by placeholders. A general prior-art exploration runs in the cloud with anonymised terms. The actual claim drafting with the secret feature runs locally or in a trusted cloud instance. This is not only a compliance matter but also a context-quality matter: a trusted instance receives the real features and can work more precisely than a consumer chat talking about placeholder-X.
6. Role-isolated parallel chats
When a step is essentially an argument, such as drafter versus reviewer, or attorney versus examiner, the two sides run in separate chats with clear system prompts. You are the orchestrator: you take the output from chat A, hand it to chat B, hand its response back to chat A. Neither chat knows the other side is an AI. That preserves the sharpness of the roles, which in a shared chat would soften within two rounds.
Applied to typical patent scenarios
Drafting: invention disclosure to application draft
Available sources: invention disclosure (EM), two prior-art references (D1, D2), filing template (AV). The application itself does not yet exist; it is the result. Everything runs locally because the EM and the resulting claims are confidential.
- Chat 1: analyse the EM. What is the invention, what are its features?
- Chat 2: compare Chat 1's feature list against D1. Which features distinguish the invention from D1?
- Chat 3: compare Chat 1's feature list against D2. Which features distinguish the invention from D2?
- Chat 4: claim brainstorming based on the outputs of Chats 1, 2 and 3.
- Chat 5: application draft from the claims of Chat 4, the EM and the AV template. Supplemented by the summaries from Chats 6 and 7 for the prior-art section.
- Chat 6: summary of D1 for the prior-art section.
- Chat 7: summary of D2 for the prior-art section.
Run this schema a few times and the orchestration cost becomes obvious: open chats, hold the order, copy outputs, keep confidentiality discipline. That is when the move from hand-flow to agent graph pays off. Parallel nodes for Chats 2/3 and Chats 6/7 halve the wallclock, mechanical handovers between nodes replace copy-paste, the routing between local model and cloud is defined once. See Multi-model workflows for the bridge.
Office-action response
- Chat 1: structure the office action paragraph by paragraph. Input: only the OA text.
- Chat 2: map cited references against the claims. Input: the references plus the claim set, without the OA.
- Chat 3: develop response strategies. Input: consolidation from chats 1 and 2.
- Chat 4 (fresh): evidence check. Input: strategy claims plus the references, with a verbatim-quote requirement.
Freedom-to-operate
- Chat 1: decompose the product description into features. Input: the product specification.
- Chat 2: pre-filter the hit list. Input: feature list, no product details.
- Chat 3 per hit: infringement analysis per patent. Input: one patent plus the feature list, isolated.
- Chat 4: consolidate the risk matrix. Input: the individual analyses, without the full patent texts.
Connection to the other articles
- Context management: the underlying discipline of keeping context small and fresh. Context engineering is that principle applied to patent workflows.
- Paragraph-by-paragraph review: the pattern for turning a long document into a structured context cleanly.
- Duty of evidence: the verification building block that works best with fresh context.
- Prompt engineering patterns: the building blocks that govern single-chat quality.
- Multi-model workflows: role-isolated parallel chats in detail, with drafter-reviewer examples.
Newsletter
Stay up to date on generative AI in patent practice.
Subscribe to the GenAI newsletter