Why agents are so reliable, and how I replicate that in the browser

Why agents are so reliable, and how I replicate that in the browser

This question keeps coming up in my workshops: “Why does my prompt sometimes work brilliantly on one task and produce nonsense on the next, even though I’m using exactly the same prompt?”

In one case, for example, the AI did a wonderful job of writing part of the description for a patent application; in the other case, it was just generic AI slop.

The answer rarely has anything to do with the prompt. It almost always has to do with the context the prompt landed in.

What an agent gets right by default

Whether it’s analyzing numerous patent documents, responding to an examination report, or preparing a search report for a comprehensive FTO. Anyone who has spent some time with agentic AI such as Claude Code, OpenCode, or Cursor in the last few months knows: they can be surprisingly effective. You give the tool a task, it works through the necessary steps, several sub-agents are called behind the scenes, and the result is often significantly better than that of a manual browser chat. With the chat, the hit rate on the same task is much more variable.

That reliability does not come primarily from the model. It is usually the same Claude or GPT that runs in the browser. Thus, the same language model that ChatGPT and Copilot use.

It comes from the architecture of the tools: one skill, one context, one task. When I invoke for example a custom command like /analyze-office-action in Claude Code, the tool opens a fresh session and dispatches several specialised sub-agents in the background, each with its own isolated context:

• one extracts the PDF documents,
• one analyses the disclosure of the application,
• one checks the cited prior-art passages of a cited document against the claim set.

Only the distilled outputs of these sub-tasks flow back into the main chat, where the actual office-action response is drafted. The main chat stays lean and focused, because it does not have to carry either the full text of each document, the raw PDFs, or the intermediate notes. And yesterday’s task leaves no trace either.

Example for a typical output of Claude Code

That is the discipline that makes agentic tools strong: every task gets its own bounded context. In manual prompting, several tasks blur into each other if you are not paying attention.

Why context engineering matters

Language models do not have short-term memory in the classical sense. They process the full context for every answer: the current question, the entire chat history, all attached documents.

The problem: anything that sits in the context keeps acting on every subsequent answer, even when it is irrelevant for the new task. A typical scenario: yesterday afternoon you worked on an application for an invention (let’s say a camera sensor with improved exposure control). This morning you reuse the same chat for a client letter about a completely different invention (let’s say a LiDAR sensor). The model pulls terms and arguments from the camera-sensor application into the new letter, and nobody notices, until a concrete detail does not fit (for example, suddenly, the LiDAR is being attributed characteristics that actually apply to the camera sensor).

One failure mode is particularly insidious: quotes from the chat history that look like quotes from the patent specification. The model picks up a sentence that has been formulated ten minutes earlier, and gives it back as a passage from the description. The attorney sees a plausible quote with quotation marks and adopts it.

Three common mistakes in everyday work

What agents get right by default can be rebuilt in a browser chat manually. Three mistakes I keep seeing:

Mistake 1: Reusing old sessions. A particularly serious failure: an attorney opens the chat in the morning where they were working on an office-action response yesterday, and types: “Now let’s look at the next application.” The model still has yesterday’s office action in the context. The construction of one claim set bleeds into the next, without anyone noticing.

Mistake 2: Throwing too many documents into one context. Three applications, five office actions, the entire prosecution file. More material is not the answer. With long contexts, the model loses passages from the middle of the document, a phenomenon researchers call “lost in the middle”. For practice this means: what sits in paragraph [0047] of an attached citation will come through worse than the content of claim 1 or the abstract. With long files this is a real risk. Liu et al. (2024) systematically showed that even models with context windows of 100,000 tokens or more reproduce content from the middle of long inputs significantly worse than content at the beginning or the end. The effect is U-shaped. The cause is believed to lie in the position-encoding methods of the transformer architecture, in particular Rotary Position Embedding (RoPE), which weights tokens close to the sequence boundaries more strongly than tokens in the middle.

The entire relevant context is rarely relevant to every task, and therefore often overwhelms the model in one single chat

A practical rule of thumb: with long inputs (a patent specification with only one prior art is enough, the remaining attached prior art is often already too much), the effect becomes noticeable. Newer models with dedicated long-context training (GPT-4o, Claude 3.5/Opus 4, Gemini 2.5) significantly reduce the effect but do not eliminate it: a 2025 Chroma study of 18 frontier models still found accuracy drops of 20 to 50 percent between 10,000 and 100,000 tokens of input length. The countermeasure stays the same as described above: put less into the context window, or split the task across several focused sessions.

Mistake 3: Patching the running chat after the result has already gone wrong. When the first answer is off, most people instinctively follow up in the same chat. Doing so cements the wrong assumption in place. An example: the model claims a feature is disclosed in paragraph [0023] of the description, even though no such passage exists. The attorney corrects: “That paragraph does not exist.” The model produces a “corrected” version that now cites [0024], with the same fabricated statement in it. As long as the original hallucination sits in the context, it reappears in every further answer, in slightly altered form. The cleaner move is to open a new chat, with a refined question and the right documents.

The rule in one sentence

New task, new chat, only the content that is actually relevant for this task in the context.

The content that is actually relevant is rarely the entire document (and certainly not a collection of documents), but only the relevant excerpts. Yes, context engineering can be time-consuming.

An example workflow; the red arrows represent the output of the last chat, which also serves as context for the next one

That is the discipline a well-configured agent enforces automatically. In a browser chat it depends on you. Concretely: at least one chat per matter, more than one chat per office action, more than one chat per scope-of-protection analysis, and before every attachment the question whether the document is really needed for this task or just attached because it is on hand.

For anyone who gets used to this one discipline, the quality jump shows after a few days. Answers become more precise and post-editing shorter. The only effort is changing your own habit.

About this series

This is the first of four upcoming newsletter issues on the four pillars that recur across our workshops as the framework for every task in patent practice. The next three follow in the coming weeks:

• Pillar 2: Duty of evidence. How I force the model to back every statement with a quote and a reference.
• Pillar 3: Paragraph-by-paragraph review. Why skimming is the most common weakness.
• Pillar 4: Self-reflection and devil’s advocate. Why the model that produced the draft is the worst possible reviewer.

If you found this interesting and would like to read future issues, here’s a tip: why not sign up for my newsletter? Here is the link: https://boesherzgoebel.de/en/newsletter/

Resources

1. Context Engineering (Knowledge)
2. Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (TACL 2024)

Enjoy exploring!

Sebastian Goebel, Founding Partner, Bösherz Goebel