Prompt Engineering Is the Wrong Mental Model for AI Agents

What building an absurdly complicated PubMed search agent taught me about tools, deterministic checks and the importance of deep domain expertise

TL;DR

Prompt engineering is the wrong mental model for building serious AI agents. What matters more is the harness around the LLM: the tools it can use, the context it sees, how work is decomposed, what can be checked deterministically, and where professional judgement is required.

Just as importantly, domain expertise matters more than generic prompting skill. An evidence-synthesis librarian may have a real advantage building an agent for PubMed searching because they know what good search practice looks like, what can go wrong, and which trade-offs matter. That advantage does not automatically transfer to legal reasoning, medicine or engineering.

And being good at ChatGPT is not the same as being good at building agents. Chat-level competence is mostly about interacting effectively with an LLM. Agent-level competence means understanding how prompts, context, tools, validators, memory, control loops and system constraints work together.

Building my absurdly complicated PubMed search agent drove this home, and I became acutely aware of how much I lacked in both domain expertise and agentic engineering. While the agent worked decently, it may not be as efficient or effective as it could be if I had stronger expertise in both areas.

Introduction

Most of us learnt generative AI through a chat box. That may be exactly why AI agents are so easy to misunderstand.

That sounds backwards. Surely someone who has spent the last few years becoming good at ChatGPT has a head start?

Up to a point.

The problem is that ChatGPT encourages a particular mental model:

Human → carefully constructed prompt → model → answer

Once you get good at this, it is tempting to assume that AI expertise consists largely of finding the right words to make the model behave.

And librarians may be particularly susceptible to this.

I have heard librarians describe themselves, sometimes with a little humble bragging, as being unusually good at prompt engineering because it reminds them of learning DIALOG decades ago.

For those unfamiliar with this history, professional online searching once involved mastering specialised command languages, field codes, Boolean operators, proximity operators and database syntax. Skilled searchers learnt exactly how to express an information need in the language understood by the retrieval system.

Then generative AI comes along with another mysterious text box and we think:

Ah. I recognise this.

The professionals will learn the advanced incantations.

I increasingly think that analogy is not merely imperfect.

It may point us in almost exactly the wrong direction. The deeper problem is that prompt engineering gives us the wrong mental model for AI agents. It encourages us to focus on what we say to the model, when the harder questions are increasingly about what surrounds the model.

This is not entirely a new scepticism on my part even prior to the emergence of agents. When I first wrote about prompt engineering in 2023, I was already ambivalent about how much of it represented durable expertise rather than model-specific tricks¹. A year later, writing about prompt engineering in RAG systems, I became even more cautious about assuming that techniques developed for a chat interface would transfer straightforwardly to systems where the same user input might also be driving retrieval.

Before going further, it helps to separate three things that are often bundled under or confused with “prompt engineering”:

• LLM literacy: understanding how models behave (for example, that LLMs are generally non-deterministic, the basic idea of RAG, context limitations, and how to communicate tasks effectively).

• Domain expertise: knowing what good work looks like and what errors matter.

• Agentic engineering: designing workflows, tools, state management and validation around the model so that it can perform useful tasks reliably.

These capabilities are related, but they are not interchangeable.

Even LLM literacy needs a further distinction. Chat-level competence means knowing how to get useful work out of a conversational model: writing clearer instructions, providing context, asking follow-up questions and recognising obvious limitations. This skill is becoming increasingly common, especially as models improve at interpreting ordinary language.

Agent-level competence is different. It requires understanding how models behave when they operate over multiple steps inside a system: how context is managed, how tools are selected and called, how state is maintained, how failures propagate and how non-deterministic behaviour can be controlled through the surrounding architecture. This is where LLM literacy starts to overlap with agentic engineering.

Put differently: basic chat-level prompt skill is increasingly becoming a commodity. The differentiator is moving from knowing how to ask a model for an answer to knowing how to build systems where the model can reliably do useful work.

Domain expertise and agentic engineering are the scarce complements. The DIALOG analogy flatters the commodity and encourages librarians to invest in the wrong one of the three.

The rest of this post argues that case, with an extended example of what happens at the boundary between the other two.

LLMs are not Boolean search engines

The most obvious problem with the DIALOG analogy is that an LLM does not work anything like a Boolean retrieval system.

Prompts condition probabilistic model behaviour. Therefore database-search syntax expertise does not translate into privileged ability to “speak LLM”.

This is why I am sceptical of claims that librarians experienced in complex searching have a special advantage in prompt engineering. There are transferable habits: decomposition, iteration, constraint-setting and evaluation². But these are general analytical skills, not evidence of a privileged ability to “speak LLM”.

What actually gives a librarian an advantage?

Librarians may have a real advantage with LLMs, but it is much more contextual than “librarians are good at prompt engineering”.

The advantage is domain expertise.

An evidence-synthesis librarian may be unusually good at getting an LLM to help with evidence-synthesis searching, not because they know Boolean syntax, but because they know what good evidence-synthesis searching looks like. They understand recall trade-offs, controlled vocabulary, search-resistant concepts, testing against known relevant papers, and the many ways a plausible-looking strategy can still be poor.

Ask the same librarian to design an LLM workflow for legal reasoning and that advantage largely disappears. An experienced lawyer is far better placed to know which distinctions matter, which errors are serious, and what competent reasoning looks like.

So the librarian advantage is not some general ability to “speak LLM”. It comes from knowing the task well enough to tell the model what good work looks like, recognise when it has gone wrong, and decide what should happen next.

That distinction becomes even more important once we move from chatbots to agents.

Prompt engineering is the wrong level of abstraction

A good agent is not just a really long prompt.

It is tempting to think of agent design as prompt engineering at scale. I used to describe it that way. I increasingly think that is misleading.

Scott Cunningham, writing about research agents, makes the point that familiarity with ChatGPT can actually get in the way: people assume research agents are mainly about finding the “right prompts”.

And what I typically say to them is that their knowledge of ChatGPT actually has made it harder for them to understand what Ai agents can do, ironically — not easier. They will think AI agents for research is all about having the “right prompts”. A hilarious statement to many of us more and more — as if any of us are “prompting” agents to do research.

Jimmy Lin, a professor of Information Retrieval, makes a similar point in his opinion paper on reproducibility:

It might be tempting to think of skills as “merely” prompts, but a more accurate characterization is that skills represent executable artifacts. They don’t merely document or describe in a static manner; they directly accomplish the tasks they were designed for (as steered by a user). Skills are programs, in the sense that a program is just a sequence of instructions, that once fed into a computer, executes to perform some task. The markdown in a SKILL.md file is code, in that code is merely the textual representation of a program—in this case, not in a programming language, but in natural language.

He goes on to say:

While skills should be conceptualized as executable artifacts and markdown should be treated like code, the “interpreter” (i.e., model + harness) is a non-deterministic execution engine that behaves very differently from the von Neumann machines that we are accustomed to.

So what is the harness³? I use the term to mean the software environment around the LLM that lets it do more than simply answer a prompt. The harness manages things such as what enters the model’s context, which tools it can call, what state persists between steps, how actions are executed, what gets checked, and whether the agent should continue, retry or stop. See also - What is a harness?

Claude Code and Codex are examples of general-purpose agent harnesses. A skill like my PubMed Search Builder runs inside such a harness and gives it a domain-specific workflow, tools, reference material and checks⁴. The prompt is one part of the harness. It is not the whole harness.

It can be hard to grasp what these two professors mean if you have not actually tried creating an agentic skill using a coding harness such as Claude Code or Codex.

I started to see the light while trying to automate something familiar to librarians: constructing a high-sensitivity PubMed search.

What was wrong with asking the LLM for a Boolean search?

Early work on LLM-generated search strategies often produced disappointing results.

For example, Wang, Scells, Koopman and Zuccon found that ChatGPT could generate Boolean queries with relatively high precision but poor recall, exactly the wrong trade-off for systematic-review searching. Other work has since explored better prompting, fine-tuning and reinforcement learning.

But something about these comparisons always struck me as slightly unfair.

In these setups, the model was typically asked to generate and refine a search strategy from prompts alone, without being able to search PubMed, check candidate terms against MeSH, inspect the indexing of known relevant papers or see what its current strategy actually retrieved.

We would not normally ask a human evidence-synthesis librarian to work that way either. Expert searching is not mainly about recalling the perfect Boolean string from memory. It is iterative: search, inspect, learn, revise.

Gold-standard search strings are so good because they incorporate this loop:

propose → test → inspect → revise → repeat until satisfied

Yet look at what we were asking the LLM to do: here is the review question, now generate the final search strategy from your model weights.

Effectively:

propose → Answer

So the more interesting question became: what happens if we give the model an environment in which it can work more like an expert searcher? That experiment ended up teaching me much less about prompting than about three other things: tools, deterministic checks and professional judgement.

My absurdly complicated PubMed Search Builder

At an evidence-synthesis conference in 2024, I happened to meet one of the authors of such a paper and asked why they had not done what seemed obvious to me: give the LLM tools such as PubMed and the MeSH Browser so it could run searches, inspect terms and test strategies. The answer was essentially that it would be too much work with little incentive to do it.

At the time, I lacked the skill to build it but by 2026 with Claude Code, this was very possible, so I built it.

This post is not a claim that the skill I built matches the best evidence-synthesis librarians. It does not. My lack of expertise on both the domain side and the technical side hampers me a great deal. It was my first attempt at a serious skill and it basically ran away from me. The current versions are huge monsters that I barely understand myself after iterative rounds of adding features that sounded like a good idea at the time, either from me or from the LLM. It is now so complicated that I use the LLM itself to explain the structure of the skill back to me.

I have four main versions of the PubMed Search Builder, which I will cover in another post. They are over-engineered and extremely expensive to run, and go for upwards of thirty minutes to an hour and eat a big chunk of your token limits.

One of the more “basic” Pubmed Search Builder Skill

Instead of asking for a Boolean string, the system could:

• query real MeSH terms and entry terms;

• inspect indexing of seed papers;

• run PubMed searches;

• test retrieval of known relevant studies;

• identify missing terminology;

• revise and repeat.

Without this loop, LLMs tend to produce Boolean cosplay: expert-looking strategies without empirical grounding.

The first version was better than prompting alone, but still far from expert-level performance.

The prompt became the least interesting part

The shift in my mental model looked something like this:

Chat:
Human → prompt → model → answer

Agent:
Human gives goal → harness gives model context and tools → model chooses an action → tool executes it → result comes back → model decides what to do next → checks are applied → repeat until done

The LLM is still important. But it is now one component inside a larger system.

As the system evolved, I stopped thinking about prompts and started thinking about architecture:

What belongs in context?

What should be loaded only when needed?

What should be tool-driven versus model-driven?

What should be deterministic code?

What state should persist?

How do we enforce validation?

What should hooks guarantee rather than merely request?

What should the model be allowed to decide?

If these questions still sound like jargon, that gap is precisely what I mean by the difference between chat-level and agent-level competence⁵.

A key distinction to think about: LLM judgement versus system enforcement.

For example:

• “Suggest synonyms” → LLM task

• “Never invent a PMID” → system constraint

• “Verify MeSH terms” → deterministic check

• “Run PubMed query” → tool execution

This is no longer primarily prompt engineering. It is system design around probabilistic components, blended with deterministic code.

That is why I now think “prompt engineering” is not merely an incomplete description of agent building. It can actively direct your attention towards the prompt, when the harder and more consequential design choices often sit around the model rather than inside it.

For example, my skills are guaranteed to build search strings that will not throw an error in PubMed and that will never contain hallucinated MeSH headings⁶, because of a final deterministic QA check run through a script rather than through the model.

That is the first and probably most important concept you will grasp as you start creating agents.

Agents, like humans, are fallible. More precisely, their behaviour is probabilistic. You can write “NEVER MAKE UP MeSH” in bold, capitals, repeat it ten times, and the model can still violate the instruction. Prompting can reduce errors; it cannot eliminate them.

If you need a guarantee, do not ask the agent to guarantee its own behaviour. Put the constraint outside the model. A deterministic validation script can check every proposed MeSH heading against the authoritative MeSH vocabulary and reject anything that does not exist⁷.

The agent can hallucinate. The system does not have to let the hallucination through.

That is harness thinking in a nutshell. Prompt engineering asks: how do I persuade the model not to hallucinate a MeSH heading? Harness engineering asks: given that the model sometimes will hallucinate, what should the surrounding system do about it?

And as you will see, even apparently technical design problems quickly led me back into questions of domain expertise.

A small example: how aggressive should MeSH search be?

One of the tools I built performs MeSH expansion.

My instinct was to make the MeSH search aggressive. If the goal is high sensitivity, why not search broadly for possible controlled-vocabulary terms rather than trusting the first obvious MeSH heading? So the tool could take candidate concepts and try multiple labels, synonyms and related terms, inspect entry terms and sometimes move around the MeSH hierarchy looking for plausible descriptors.

The problem was that aggressive sweeps had an annoying tendency to time out.

This is where working in Claude Code or Codex became interesting. The model could see the failure and suggest perfectly sensible engineering fixes: cache repeated lookups, retry failed calls, batch requests, run some in parallel, perhaps even maintain a local MeSH index.

But every fix introduced another trade-off. Persistent caching needs refreshing because MeSH changes. Retries can turn a bad operation into an expensive loop. Parallelisation can worsen rate limits. And even if I solved the API problem, aggressive searches could dump dozens of candidate headings into the model’s context. Somebody still has to inspect them.

Eventually I realised I was asking the wrong question.

The question was not simply:

How can I make aggressive MeSH exploration faster and more reliable?

It was:

When is aggressive MeSH exploration worth doing at all?

Perhaps “aggressive” should not be a fixed setting. The system could start cheaply and escalate only when the evidence warrants it:

• look up the obvious candidate headings and entry terms;

• inspect how known relevant papers are actually indexed;

• compare what MeSH retrieves with what the free-text block retrieves;

• expand more deeply only when there is evidence of a vocabulary gap.

Then comes the harder question: what should trigger escalation, and what should make it stop?

A seed paper missed by the current controlled-vocabulary terms might justify more exploration. So might several relevant papers carrying an unexpected MeSH heading, or evidence from Bramer Reciprocal Gap Analysis that MeSH is finding useful records missed by free text. Conversely, another round that produces no new plausible descriptors or useful unique retrieval might be a reason to stop. Or perhaps some concepts simply deserve more exploration because experienced searchers know the indexing is particularly tricky or unstable terminology.

Those decisions cannot be settled by API documentation or clever coding alone.

An engineer might say:

We can reduce the timeout problem by caching every lookup and running eight requests concurrently.

The evidence-synthesis expert might reply:

Why are you making eight requests in the first place? For this type of concept, two carefully chosen lookups followed by inspection of seed indexing would normally be enough.

Or the expert might say the opposite:

This concept is notorious for being represented inconsistently. Don’t stop at the obvious heading. This is exactly where I would spend additional effort exploring MeSH.

Now the engineer has something useful to engineer.

The domain expert decides when expensive exploration is warranted and what evidence should make it stop. The agent engineer works out how to carry out that exploration reliably and efficiently. Together they might arrive at an adaptive policy: start cheap, inspect evidence, escalate when justified, and stop when marginal value falls.

I did not start there. I started by making the sweep aggressive, watching it time out, and asking the LLM how to fix the timeout.

That is why the example stuck with me. The model was quite good at suggesting technical fixes. What it could not settle for me was whether the expensive operation was worth doing in the first place. Asking it to list the pros and cons of each proposed plan was no help, since it would happily tell you and be equally convincing either way.

Notice what would not have helped here: better wording. No amount of category-one prompt skill resolves a question about how much a controlled-vocabulary sweep is worth. That decision sits right at the boundary between domain expertise and agentic engineering, which is where the hard problems in agent design actually live.

The hard engineering question is often not how to make the agent capable of doing more. It is how the system decides when doing more is worth the cost.

More agentic does not mean better

It is easy to replace one bad instinct with another.

The old instinct was: if the model fails, add more instructions.

The new one can become: if the agent fails, add more machinery.

My PubMed workflow grew from simple search construction to:

• validation sets;

• critic loops;

• held-out evaluation;

• scope locking;

• ablation tests;

• multi-stage revision gates.

It became far more complex. This for example is the latest branch.

But I still cannot prove it is better.

That matters. Complexity is not quality. Every extra tool, loop or layer needs to justify itself against additional cost, latency, context use, maintainability and new failure modes. Otherwise we risk building elaborate machinery that looks impressively agentic without actually improving outcomes.

Subagents are a particularly seductive example.

I could create separate agents for question analysis, controlled-vocabulary exploration, free-text mining, retrieval testing and PRESS-style critique, each working in its own context and reporting back to a main agent. There are plausible reasons this might help. A fresh context could reduce context rot. Specialisation might keep individual tasks focused. Independent critics might catch errors the main agent misses.

But the questions immediately multiply.

Why does this need to be a subagent rather than a tool or simply a fresh model call with bounded context? Does splitting the work reduce context overload, or merely duplicate context across several agents? What happens when two agents disagree? How much latency and token cost does orchestration add? Does dividing the workflow make it harder for any one component to see the whole search problem? Should tools be allowed to discuss among themselves in parallel tasks?

Meanwhile frontier models keep getting better. It is quite possible that a strong model with one very good generic web search tool and a handful of boring deterministic checks gets most of the benefit of my giant workflow at a fraction of the cost.

Don’t believe me? At the time of writing, take GPT-5.6-sol or Opus 5, set effort to maximum, and ask for a Boolean search strategy. Even with plain web search, it tends to do pretty well and often without hallucinated MeSH. In my informal tests, the search strings are frequently not much worse than one generated by a complicated skill.

While weaker models in the past might have needed specialised harnesses, a stronger modern model with generic tools may need much less. The value of the harness therefore has to come from something other than sophistication for its own sake, and you can only find out what by measuring.

What empirical result would convince me that the multi-agent version is actually better?

It might help enormously.

It might mostly add theatre.

The same applies to almost every apparently sophisticated agentic feature. A critic loop sounds sensible. So does another validation step, another retrieval tool or another round of reflection. But each is really a hypothesis about how to improve performance.

That hypothesis needs testing.

Ironically, this takes us straight back to information retrieval. You need evaluation.

For search strategy generation measuring performance is fairly clear if you have gold standards⁸. Measure relative recall of each version against published gold-standard strategies. Check what proportion of known relevant seed papers each version retrieves. Track the precision cost of any recall gain, since a strategy that finds everything by retrieving half of PubMed has not achieved anything.

In short, the point of agent engineering is not to build the most agentic-looking system.

It is to build the simplest system whose additional complexity earns its keep.

Encoding expertise

At this point, agentic skills start to look less like clever prompts and more like a modern form of expert system.

The comparison is useful because the expert-systems movement of the 1980s ran into a problem that should sound familiar: the knowledge-acquisition bottleneck. The difficult part was not merely building the rules or inference engine. It was extracting tacit expert judgement from human practitioners and turning it into something explicit, operational and maintainable.

Librarianship tried this too. Just like libraries of today who work on chatbots, systems such as PLEXUS and Answerman attempted to encode aspects of reference expertise in the late 80s to 90s. The technology was very different, but the underlying problem remains remarkably similar.

LLMs make it much easier to express fuzzy professional knowledge in natural language. But they do not remove the need to decide what good professional practice actually consists of.

That is what I increasingly think a good agentic skill is: an encoded professional workflow.

It may contain natural-language instructions, tools, deterministic checks, context management, state, evaluation loops and human judgement. Ideally it reproduces something closer to:

act → inspect → evaluate → revise → repeat

rather than:

prompt → answer

The hard part is deciding what belongs where. Which decisions can safely be left to the model? Which should be checked deterministically? Which require tools? Which parts of expert practice can be made explicit at all, and which still depend on tacit professional judgement?

So the important question is no longer simply what prompt should I write?

It is: what workflow are we encoding, and whose expertise defines it?

The Kiln People problem

There’s a slightly darker side to this that’s been on my mind.

It reminds me of David Brin’s Kiln People, in which people can create temporary copies of themselves, carrying their skills and memories. The obvious attraction is that expertise is no longer limited by the number of hours in one person’s day.

Agentic workflows point, imperfectly, in the same direction.

If you can capture enough of an expert’s working method in a reliable system, you have created something more interesting than a good prompt. You have captured parts of how the expert actually works: how they frame the problem, which tools they consult, what evidence makes them change direction, which checks they insist on, and when they decide that enough is enough.

For an evidence-synthesis librarian, that might mean knowing when to expand MeSH aggressively, when to inspect seed papers, when an apparently useful term is generating mostly noise, and when further searching is unlikely to justify its cost. For a lawyer or accountant, the corresponding workflow would encode entirely different professional judgements.

This is where domain expertise becomes both more valuable and more scalable. An expert can personally help only so many people. But encode enough of that expertise into a reliable workflow and many more people can use something resembling that expert’s method. The scarce resource is no longer merely access to the model. It is the expertise that determines how the model, tools, software and human judgement are assembled.

That has an uncomfortable corollary. If one expert’s working method can be scaled this way, you may need fewer experts to perform the same volume of work. And if agents increasingly perform the routine work through which juniors once learnt the profession, it becomes less obvious how the next generation acquires the tacit judgement needed to build, evaluate or supervise those agents in the first place.

That, to me, is a much more consequential question than whether librarians have a special talent for prompt engineering.

The potentially disruptive combination is not expert prompt writer + LLM.

It is top-tier domain expertise + good agent engineering → a scalable professional workflow.

The wrong thing to optimise

I started with prompt engineering because that is how many of us first learnt to think about generative AI: there is a model, there is a box, and our job is to find better words to put into the box.

This is why prompt engineering is the wrong mental model for agents: agents change the unit of analysis.

The important question is no longer simply:

What should I tell the model?

It becomes:

What should the model decide, what should a tool retrieve, what should code verify, what should the system remember, what should evaluation measure, and what should remain a human judgement?

My PubMed Search Builder taught me this mostly by going wrong. I kept adding instructions, tools, checks and critic loops. Some probably help. Others may simply be expensive machinery solving problems that did not need solving. I cannot tell by looking at how sophisticated the architecture appears. I have to evaluate it.

This is where the three kinds of expertise separate most clearly. LLM literacy helps you work with the model. Agentic engineering helps you build a reliable system around it. But domain expertise tells you whether the system is doing something worth doing in the first place.

LLMs are extraordinarily good at making almost any workflow sound plausible. They can suggest another tool, another retry, another subagent or another validation step. What they cannot supply automatically is an independent standard of good professional practice.

So perhaps the most valuable question for librarians is not whether our history of complex searching makes us unusually good prompt engineers.

It is whether we understand our own professional practice well enough to say: this is the part that matters, this is the evidence I use, this is where judgement enters, this is what can safely be automated, and this is where the machine should stop.

If we can do that, then agentic AI becomes genuinely interesting. Not because we have discovered better incantations for talking to machines, but because we have begun turning expertise into executable workflows.

And if Kiln People is even partly the right analogy, that may ultimately be the much bigger deal.

1. Interestingly, because my blog post was one of the most public pieces discussing the potential of prompt engineering for librarians, it has been cited a few times by LIS peer-reviewed literature that almost imply I agree with this idea. In truth, I was skeptical.

2. This claim strikes me as rather condescending to other professions. Are we really saying librarians are uniquely good at decomposition and problem-solving? Lawyers, doctors, engineers and many other professionals do this routinely, often in far more complex and high-stakes settings.

3. Strictly speaking, there is no universally agreed list of what belongs in an agent harness, and different systems draw the boundaries differently. A useful way to think about it is as the engineered machinery surrounding the LLM that turns repeated model calls into an agent capable of acting in an environment. Typical components include: Context and instructions, the agent loop or orchestration, tools, the execution environment, State and memory, Checks and constraints etc.

4. Usage of harness is not entirely consistent. In a broad sense, it can refer to the execution environment and surrounding scaffolding that makes an agent work, in which case skills can reasonably be considered part of the harness. A narrower usage distinguishes the two: the harness is the machinery that manages instructions, context, tools, validation and orchestration, while a skill is a reusable package of instructions, scripts and resources that the agent can load and use. On that definition, a skill operates through the harness rather than being part of it.

5. That haziness is the gap between chat-level and agent-level competence in practice. The answer to any one of them may not be straightforward, but you should at least grasp what is being asked.

6. More accurately, the system can guarantee that the final string passes its syntax checks and contains only MeSH headings validated against the authoritative vocabulary.

7. A deterministic guarantee is only as strong as the validator, its authoritative data source, and the code implementing it. More importantly, you can only validate properties that can be checked mechanically without requiring professional judgement, unless you introduce some measurable proxy for that judgement. A script can verify that a proposed MeSH heading exists in the authoritative MeSH vocabulary. It cannot directly verify that the heading is appropriate for the research question, except through proxies such as whether it appears in known relevant seed papers or improves retrieval of a validation set.

8. In reality, creating a “gold standard” dataset is notoriously difficult, time-consuming, and subjective. You can use existing ones (e.g. CLEF Technology-Assisted Review datasets) but the data would be leaked to LLMs. That said there are some very recent interesting ones like MetaSyn