The prompts ran against the Oxford Academic corpus through our Discovery Bridge server, a Model Context Protocol (MCP) service built on the same platform retrieval infrastructure that underlies Oxford Law Pro, the platform work that earned OUP and Silverchair a Gold 2026 EPIC Award from the Society for Scholarly Publishing in the Hosting Platform Features category.
The flagship prompt is worth walking through in full. It asks the model to trace the migration of the proportionality doctrine across three regimes of international law (human rights, investment arbitration, and WTO trade) to identify which scholars argue these are fundamentally one doctrine and which argue they are distinct concepts that merely share terminology, and to map where the analytical frameworks genuinely converge.
Executing that properly is, by design, a twenty-to-fifty-plus tool-call job: canvassing three separate literatures whose shared vocabulary is precisely the open question; filtering by content type and publication window; and retrieving extended passages rather than snippets, because understanding an analytical framework requires reading, not matching. The model grouped scholars by position, mapped the convergences and divergences, and composed the result as a structured analysis in scholarly monograph style, with an OSCOLA bibliography of every OUP source consulted and an appendix tracing the output back to the verbatim prompt.
The other four prompts stress different capabilities — tracing how scholarly opinion shifted over time, disambiguating frameworks that share vocabulary, synthesizing across source types, historiographical analysis — but the pattern is the same. Each assignment is specified in plain English and each ran as its own session in an ordinary Claude client: one prompt in, one document out.
What came back was never a list of results. It was a document.
Figure 1: Anatomy of the session. The flagship prompt run as a single session: successive informed retrievals, no multi-agent orchestration. Scholar groupings, section count, and the 20-source OSCOLA bibliography are from the actual output document; "20–50+ tool calls" is the requirement each prompt was designed to.
The tempting way to explain the result is the way our industry has been explaining things since 2023: semantic search retrieves on meaning rather than string matching. That's true. It's also now table stakes, and it isn't what did the heavy lifting. Two other things did.
A corpus you can navigate, not just query
The first is what the server actually exposes. Not a "search box" endpoint, but a small set of primitives (basic usage patterns) that an AI can compose. Ours exposes exactly two. One runs semantic search crossed with the metadata publishers have spent decades building (content type, publication window, title, identifier) with the filters binding as hard constraints, not ranking suggestions. The other retrieves text at whatever grain the task needs: a passage, an expanding window of context around it, or the full document.The power is in how they compose, because each retrieval is informed by the ones before it: sweep all three regimes; narrow to the framework-setting monographs and reviews; pivot into the adjacent literature where the concept appears without the keyword; follow a citation trail and pull the key monograph in full. The agent doesn't fire one query and work down a ranked list. It narrows, pivots, and follows trails, which is much closer to how a skilled researcher works a library than to how anyone works a search box. And the structure that makes this possible — DOIs, JATS tagging, taxonomies, versioning — was built for human readers navigating platforms. It turns out to be exactly what machine reasoning needs.
Figure 2: Navigation, not querying. Discovery Bridge exposes exactly two tools: semantic search with hard metadata filters, and windowed full-text retrieval. The sophistication is in how an agent composes them.
The environment on the other end of the pipe
The part I think our industry still underestimates is what now sits on the other end of the connection. The first wave of MCP demonstrations was essentially a chat window bolted to a retrieval endpoint: one query in, a handful of passages back. What calls a publisher's corpus today is a different class of system: agentic environments (Claude Science, Claude Cowork, Claude Code, OpenAI's Codex) in which the AI plans, writes and runs code, delegates to teams of subordinate agents, and works unattended for minutes or hours at a stretch.All of these environments can take a large assignment, break it into a work breakdown structure, and farm the components out to sub-agents. Dynamic workflows in Claude Code go a step further. Handed the assignment, the model doesn't just delegate and coordinate from memory: it writes a deterministic orchestration layer (a small program specific to one objective) and that code then runs teams of Claude sessions beneath it. The difference is a master juggler versus building a juggling machine. The coordination moves into code, and the model's intelligence is freed to operate at a higher level of abstraction. Probabilistic intelligence, harnessed to deterministic logic.
Run the flagship prompt that way and the plan writes itself: a reader agent per legal regime, each running the whole single-session shape over its own literature alone, in parallel; structured findings streaming through analysis stages; every substantive claim through a dedicated verification pass before it can reach the final document. Nothing in the assignment caps how much a reader retrieves. Each works its regime as deeply as the question demands, and a run of this shape consumes corpus calls by the hundred before verification even begins. In our own day-to-day use, a single workflow routinely coordinates anywhere from six to several dozen sub-agents and runs ten to twenty minutes unattended. And the assignment itself is still just plain English.
This is the prompt, ready to drop into Claude Code:
Using Fable 5 in Claude Code with effort-level Ultra Code, which implements a dynamic workflow. Queries of this type typically return in five to thirty minutes.
Figure 3: The prompt above, as a dynamic workflow runs it. The environment writes the orchestration plan, fans a reader out per regime (each running the session shape of Figure 1) then streams findings through analysis and verification. The assignment sets no call ceiling. Retrieval runs to whatever the regimes demand; the run pattern (six to dozens of agents, ten to twenty minutes unattended) matches our day-to-day workflow use.
That is the scale of work the two simple primitives get composed into:
| A search box | one query → a ranked list → the human does all the reading and all the synthesis |
| Simple RAG | one query → a handful of best-matching passages → one draft answer |
| A research session | a plan → dozens of informed retrievals → extended full-text reading → verification of substantive claims → a finished work product |
Verification is engineered, not hoped for
Hallucination is the first objection every publisher raises, and rightly so. A language model is a probabilistic system: like a human researcher, it will have an error rate. Scholarly publishing has never answered human fallibility by hoping authors are careful — it built peer review, because fresh eyes catch what an author cannot. Frontier workflows engineer the same discipline into the machinery. In the research workflows we run daily, verification is a first-class phase: substantive claims are handed to independent verifier agents whose explicit instruction is to refute them and a claim reaches the final document only if it survives that panel. Reviewed that way, the likelihood of an error going uncaught drops dramatically. What's refuted isn't silently dropped, but listed, with reasons.Point that machinery at a publisher's corpus and the checks gain something the open web can never give them: authoritative ground truth. Every quotation can be resolved against the version of record before it stands. Which is why the more sophisticated these workflows become, the more valuable the authoritative corpus gets, not less.
Figure 4: Workflows that check their own work. The verify phase of Figure 3, zoomed in. The refutation-panel pattern from the research workflows we run in Claude Code: each verifier reads the full text independently and votes; a claim stands only if it survives the panel. The publisher's version of record is the ground truth the checks resolve against.
The session shape, everywhere
Once you recognize the shape, you can see where it goes across the whole research lifecycle. Picture a systematic reviewer with a standing workflow that watches the pipe for new records, screens them against their own inclusion criteria, extracts effect sizes into their own tables, and flags which claims in the review draft are now contested — a living review rather than a periodic one. Or a materials chemist who points the environment at eighteen months of their own instrument data, has it generate ten candidate mechanisms, and dispatches a literature agent per hypothesis into the corpus in parallel, coming back to an evidence matrix, a surviving shortlist, and a next-experiment memo. In every case the work runs in the researcher's environment, over the researcher's own files, with the published record flowing to them through the pipe.Why this matters for publishers
Publishers have spent decades building the most trustworthy, deeply structured scholarly content in the world. That investment was made for human readers navigating platforms. It has turned out to be the enabling layer for something larger: every guarantee a sophisticated workflow depends on (entitlements, attribution, versioning, retraction status, provenance) is machinery publishers already operate. MCP is simply what opens that machinery to agents: the same guarantees publishers already deliver to human readers through their platforms, delivered on the same terms to the AI environments where the work now happens. The environment side of that equation is already on researchers' desks. The corpus side is the half publishers control, and it's what we're building with partners like OUP today.The tools are already there, and they are improving at a remarkable rate; researcher adoption is following fast. The question in front of publishers is whether their content participates in these workflows on terms they helped shape, or sits at the margins because the infrastructure isn't in place. From where we sit, building that pipe well, with attribution, quality, and access control designed in from the start, is the most important technical investment a publisher can make right now.
This blog was written in collaboration with Claude through an iterative revision process and was fully reviewed and edited by the author before publication.