A chemist asked for one tool. What he needs is an agent, and that changes what we build.
A note from the Center for Research Computing.
At the Extraction Group meeting I mentioned that a domain scientist extracting data from papers, APIs, and online datasets (supplementary information and the like) needs many tools. Olaf Wiest, the Grace-Rupley Professor of Chemistry and Biochemistry, said he wants one tool.
He asked for one tool. What he needs is an agent.
Not a monolithic program, and not a single screen hiding a fixed menu. Olaf interacts with an agent, his Research Agent, and describes what he needs. The agent discovers the tools that fit, orchestrates them, and works over his group's shared memory. The tools stay many; they sit behind the agent, found by discovery and composed on the fly, rather than operated one at a time by the scientist. A document extractor that reads a paper's structure can feed a graph extractor, with the agent discovering and composing the two rather than the scientist wiring a pipeline by hand. A portal makes the researcher run the tools. An agent runs them for the researcher, across everything the group already knows.
This isn't only Olaf's problem. For fifteen years centers like the CRC have built web portals, gateways, and apps to collect and share data, the defining work of the Big Data era that preceded AI. But that data has become siloed inside those very constructs, and the field's emerging answer is the Data Fabric: AI-driven systems that connect data sources and make them accessible in a data-agnostic environment. The open question is the one Olaf's observation posed: how an individual researcher builds on the Data Fabric idea with an agent tailored to their own work, in a way that learns as their experience accrues.
The picture we mean: the knowledge-driven data fabric →, and where our template, wiki, knowledge graph, and federation already sit on it.
Data Fabric: connects data sources in a data-agnostic environment.
The Research Agent: the researcher's single point of contact, discovering and orchestrating the tools over shared group memory, carrying the group's judgment and accruing its experience, and shareable as a unit.
See it working: a live connector against Notre Dame's PAD service →, answering natural-language questions with no UI and no per-endpoint code.
This is less a proposal than a consequence: once you accept agents tailored to a researcher's own work, the thing we build changes shape. We stop building bespoke portals, gateways, and apps for people to operate, and we start building connectors and tools for agents to discover.
And the connectors have to advertise themselves. Each one carries its own description of what it does, what data it speaks, and what domain it serves, so the researcher's agent finds and composes it with no one hand-wiring an integration. The deliverable is no longer a human-facing application but a self-advertising capability. The field is already chasing the premise with Data Fabric; self-advertising connectors are simply what follows once you grant it.
The connectors are agents, not static adapters. Reading a table out of a paper, reconciling a supplementary spreadsheet against a paper's notation, negotiating a chemical database's quirks, normalizing to a schema, attaching provenance and a confidence, retrying when a source is malformed: that is open-ended, interpretive work. A connector is an agent that wraps a source, declares a capability, does the messy extraction, and files the result with its provenance.
Self-advertisement is what removes the center as the bottleneck, and it is where the economics flip.
Portal world: connecting a new source is a human integration, built once, bespoke, slow, and siloed inside that portal. It cannot be shared. Every new source is new work for us.
Connector world: a source ships a self-advertising connector once, and from that moment every agent and every researcher discovers it. No central integration step. The ecosystem grows without us in the loop, and because a connector is a shareable unit, one researcher's setup is something a colleague forks.
Portals put the integration burden on the center, one bespoke build at a time. Self-advertising connectors move discovery into the agent and let the ecosystem compound. And the results do not vanish into an app: they accumulate in the researcher's living memory, which is the part a Data Fabric alone cannot do. The fabric connects data; it does not carry judgment or accrue experience. This does both, because the connectors are agents and what they extract lands in a memory that grows.
The foundation is not hypothetical. It exists and it runs, as the LLM-wiki-template ecosystem: a shared template that every project instantiates, a living wiki that is the shared memory across a project and group (many people and their agents writing to one attributed record, not a private notebook), a reified knowledge graph over that memory (RDF and SPARQL, already standards-based), knowledge bundles as the shareable unit, and a federation where each group's agent publishes a card and answers others through an ask primitive. Data sources reach the wiki today through lightweight ingest connectors. The step in front of us is not to invent the foundation. It is to make the tools researchers rely on self-advertising, and to let discovery emerge from what agents learn.
Have today: a non-proprietary, LLM-agnostic agent with persistent, shared memory. A template, a shared and attributed living-memory wiki, a reified knowledge graph, shareable bundles, and a federation with agent cards and ask.
Build next: connectors that advertise themselves, and discovery that falls out of what agents learn.
The Extraction group already has capable tools; the question is how to make them available in the right way. A tool that lives inside one pipeline is reachable by one workflow; the same tool given a connector and a card advertises itself, and any researcher's agent can discover and compose it. Graph extraction, table and figure readers, database and API pullers each become a resource the whole federation finds and calls, rather than a step buried in one project.
And discovery is not a separate system to build: as an agent learns how to work a source, that competence is filed into a knowledge bundle and published to the federation, so the next agent finds it without anyone wiring it by hand. The change is as much cultural as technical, and the next request to the CRC stops being “build me a portal” and becomes “how do we make this discoverable,” with the tools we already maintain moving onto that footing one at a time.
And distribution already has a working mode. Not every tool is a connector to an external source; a graph extractor or a figure reader is a capability an agent simply installs, distributed through a marketplace the CRC can host. Discovery hides which is which, the agent finds a capability and uses it, whether that resolves to a connector it calls or a plugin it installs. This is not hypothetical: a working plugin marketplace already packages group skills into installable plugins, validated end to end, so the marketplace path the roadmap builds on is proven, not promised.
A security and data-ownership layer. Connectors reach licensed databases and private group data, so the pipeline has to respect ownership from extraction through storage to sharing. Access control is the floor; the harder part is honoring a source's terms end to end, so that a connector to a licensed database never lets its output leak into a public bundle. Every group keeps its own memory, its own permissions, and its own rights.
Data-fabric-compatible publishing. The results should not sit in a walled garden. Publishing them in a data-fabric-compatible form lets them plug into the wider institutional and national fabric rather than compete with it, and we are already part of the way there: the knowledge graph emits standards-based RDF, the format a fabric consumes. Published this way, a group's outputs come out FAIR by construction on three of the four axes, Findable, Accessible, and Interoperable, and Reusable once machine-readable licensing lands. FAIR is the data-management standard funders increasingly require, and it was written for a machine to act on the data with little human help: here that machine is the Research Agent.
Every vendor will hand your scientists a capable agent. None of them will give you a place to keep what the agent learns that you still control next year. That is the gap the template fills, and it fills it by staying neutral on all three axes at once:
Neutral agent: any LLM plugs in through the template's overlays and skills. When a better model arrives, adopting it is a new overlay, not a migration.
Portable memory: your knowledge lives in an open bundle (markdown and a standards-based graph). Move to another solution and take your bundle with you.
Portable tools: connectors speak an open, cross-vendor protocol, so if you change agents the tools and connectors keep working.
Use whatever platform is best for capability today. Keep your memory, your discovery, and your discipline in a template you own, so switching costs you nothing. In a market where the eventual winner is unknowable, the safe bet is the layer that stays true no matter who wins.
Here is the shape, and the core of it runs today. Every researcher works through their own Research Agent over their own wiki (the shared, durable memory) on one non-proprietary template. That template, the living memory, its reified knowledge graph, the shareable bundles, and the federation that carries them between groups all exist and run now, and the appendix shows a working connector-agent reading a live service end to end. The federation is already reachable through a standard, read-only MCP server, so any MCP-capable host (Claude Code, Claude Desktop, Cursor) can discover, open, and search shared bundles, with the researcher's own model doing the reasoning. The diagram is the whole architecture; the marketplaces of tools and connectors, and the reach into more of the external world, are where the roadmap below fills in the edges. Nothing here is a portal: every box is either memory the researcher owns or a discoverable agent the LLM drives.
Each box is tethered to the shared data fabric. The template instantiates the agent (an LLM with its tooling, gates, and hooks) and its llm-wiki memory; agent, memory, and federation all connect through the fabric, and the memory is reachable both by its own agent and via the federation. Marketplaces, connectors, and external sources feed up into the fabric.
A fair and sharp objection: a wrong claim filed into shared memory, then discovered and built on by a colleague's agent, is the failure that scales exactly as fast as the ecosystem does. The architecture answers it at the moment of writing, not with faith in the model. Every claim is filed as a claim, attributed to a person and the agent that wrote it (by: <human> via <agent>) and versioned in git, so provenance is always traceable. A verification gate blocks the agent from filing numerical results that are not backed by real output, catching projection-as-fact before it lands. And corrections do not overwrite: a superseding claim is filed alongside the original with a cross-reference, so a later reader or agent meets the correction and the trajectory, not a silently wrong fact.
How far to trust a number comes from its cited source and, where one exists, a validated statistic, never from an agent's self-reported confidence, which is uncalibrated. Those correctness conventions live in the template, so every project inherits them, and stewarding that template is where the center's role concentrates. The ecosystem itself stays completely open: anyone can build a connector, publish a bundle, or join the federation, with no gatekeeper. The center's job is to maintain the shared, non-proprietary template and the trust gates that make that openness safe, not to govern what people build on it. Its leverage does not shrink; it moves from building portals to stewarding the commons everyone else builds on.
The foundation runs; here is where it goes next.
Template the governed coreEcosystem open, anyone builds
None of this is a portal. It is an agent the researcher controls, over knowledge that stays theirs, and an ecosystem anyone can build on.
The template is open and the ecosystem is open. Bring a project, a data source, or a research group, and build on it.
Contact: Chris Sweet · csweet1@nd.edu · CRC, University of Notre Dame