Agents in Research

Norman (Xuxi) Guo · Saint Louis University · September 2026 · github.com/xuxiguo/research-factory-claude

Over the past year I rebuilt my empirical research pipeline around AI agents — not a chatbot that answers questions, but an organized system that pulls data, runs regressions, drafts sections, answers referees, and remembers everything between sessions. I packaged its core as the Research Orchestra, an open-source plugin for Claude Code: an entire research department in your terminal, from rough idea to journal submission.

The premise behind every design choice is simple. At the start of a big project, you are clearest about the goal. Over the months that follow, an unharnessed AI drifts — it redefines variables, forgets decisions, agrees too readily, and wanders off the question. So read everything on this page as a harness: structure that holds many fast agents to the goal you set on day one, while leaving every judgment call with you. The feature atlas explains each mechanism — the pain it corrects, how it works, what it looks like in use — and the build-your-own section shows how to grow the same harness around your field, your data, and your standards.

28 specialist agents 37 playbooks (skills) 9 conductor commands 9 always-on guard hooks 1 principal investigator: you
> /plugin marketplace add xuxiguo/research-factory-claude
> /plugin install research-factory
> /research-factory:init-project My-Paper # folders, memory files, project contract

Requires Claude Code v2+ and Python on PATH. Works in the terminal and the VS Code extension. Every agent, skill, and template is plain Markdown — edit the prose and you have changed the system's behavior.

Why a harness, not a chat window

A chat window is spectacular in the moment and structureless over the months a paper actually takes. Used naively for empirical research, it drifts off your goal in four specific, repeated ways — and each one shaped a part of the orchestra:

It forgets between sessions

Tuesday's sample filters are gone by Thursday. Every new conversation re-explains the project from scratch — or worse, doesn't. Corrected by: shared memory files and session checkpointing.

It drifts silently

Across a long thread, variable definitions and hypotheses quietly mutate as new plans build on half-remembered old ones. In empirical work this is the fatal failure. Corrected by: a locked design, frozen formulas, and a change log.

It agrees too easily

It praises the research design it should be attacking, and Referee 2 will not be so kind. Corrected by: a built-in hostile referee and reviewers who cannot be talked out of a finding.

One fragile thread

A single context window carries data, results, and prose until it overflows — and what mattered most is exactly what gets summarized away. Corrected by: a department of specialists in fresh sessions, connected by handoff notes.

Idea-Lab brainstorm & rank Strategist design → charter Extraction pull & validate Analysis samples → tables Writing draft → submit Revision answer referees ◎ journal you approve handoff note → CC-Conductor co-author sync via Notion Presenter slide decks from project docs Sentinel scooping & staleness watch side channels — attach to the whole line, on demand or on a schedule
The assembly line. Each station is a conductor command; every diamond is a mandatory stop where you approve before the next phase starts in a fresh session. Paper-Lab (close-reading published papers) feeds the front of the line.

The feature atlas

The headline feature comes first: the orchestra is an organization, not an assistant. You direct nine conductors; the conductors direct twenty-eight specialists; a separate audit bench reviews everything with read-only power. That department is what makes months of AI work fast — and fast is exactly why it needs a harness:

YOU — the principal investigator every gate ends here one command per phase reports & one question at a time 9 conductors — one per phase of a paper's life ideas · design · deep reading · data · analysis · writing · referees · co-author · slides briefs with tool budgets one report, then gone Literature 2 agents Extraction 2 agents Analysis 2 agents Writing 5 agents Revision 3 agents Co-author 3 agents Shared 11 agents the 11 shared services include the audit bench — critics and validators with read-only power, who can flag but never touch
The department. Work flows down as briefs; results flow up as single reports; nothing important happens without passing you. System 1 below explains each piece of this chart.

The six systems below are that department plus its harness, in the order a paper meets them: who does the work, is the goal right, can the goal drift, is every step checked, does it learn your field, and who commands. Within each system the features are a chain, not a list — every pain point hands off to the next fix. Click a system's name for the story of its chain; hover any feature for the pain it corrects, the harness that corrects it, and what that looks like in practice; use next on each card to read the whole atlas as one connected walk.

6 systems · 48 features · hover to preview · click to pin

Build your own orchestra

The plugin you install is a skeleton: the organization chart, the memory schema, the review loops, the guard hooks. The muscle is your field knowledge — and the orchestra's real trick is that it grows that muscle on its own. My copy has taught itself twenty-two guard skills from its own mistakes (sixteen ship in the public plugin); yours will learn different ones, because your data and your methods fail differently. Six months in, your orchestra and mine will share a skeleton and disagree about everything else. That is the design working.

Install the skeleton, initialize one paper

Three plugin commands, then init-project — it creates the folder structure, the memory files, and a project contract. Don't study it first; the conductors explain themselves as you go.

Swap my field profile for yours

Idea-Lab carries my research interests (fintech, banking, microstructure); the house-style skill carries my writing voice and table standards; the regression playbooks assume finance conventions like clustered standard errors and fixed-effects grids. All of it is plain Markdown. Rewrite those files in your field's terms — a health economist's data playbooks and a macroeconomist's are supposed to diverge here.

Work normally, with the gates on

Run a real paper through the line. Lock a charter, let plans pass review, let the critic loop catch what it catches. The point of the early weeks is not speed — it is teaching the system what "done correctly" means in your area, one approved gate at a time.

Let it distill what you both learn

Every phase ends with a distillation sweep: anything that took real trial-and-error and then verified gets written down as a skill that auto-triggers next time. When your database's merge quirk or your method's numerical trap bites once, it becomes a guard — and it never bites again. This is where your orchestra stops being mine.

Audit the memory, not the transcripts

Once a month, read three files: the charter (is the locked design still what you believe?), the belief ledger (which results are robust, fragile, dead?), and the lessons file (what has it learned?). Those three pages are the project — the ten thousand lines of chat that produced them are disposable.

Why this is more than a CLAUDE.md

Most people's first move is to write one big instruction file and hope the model reads it. That works for preferences; it cannot carry a discipline. The orchestra splits "teaching the machine" into four mechanisms, each doing the one job it is good at:

MechanismWhat it carriesWhy a CLAUDE.md can't do it
CLAUDE.md contract A one-page constitution per project: folder conventions, the mandatory-stop rule, where memory lives. This one it can — kept short. It is the only always-loaded piece, so every line must earn its place.
Skills Procedures with trigger conditions: "when a CCM merge inflates row counts, do this." Load only when their symptoms match the task at hand. A flat file grows until nothing in it is read. Skills are retrieval-keyed — forty of them cost nothing until exactly one is needed, and each can hold a full page of hard-won detail.
Hooks Rules enforced by code on every tool call: raw data is unwritable, state checkpoints at every stop, a snapshot fires before context compaction. An instruction is a suggestion the model may forget under pressure. A hook runs whether or not anyone remembers — protection that does not depend on attention.
Memory files The project's evolving state: locked design, decision history, beliefs about results, current phase. Instructions are static; a project is not. State needs files that agents read and write under rules — append-only here, amend-with-approval there.
session 1 dies at the window's edge session 2 ⚡ compaction mid-run session 3 resumes in one read checkpoint (Stop hook) restore (SessionStart) snapshot (PreCompact) docs/_backbone/ — charter · decisions · beliefs · state · pipeline the project's memory — survives every session, every model swap
The mechanism that makes accumulation possible: sessions are disposable, the memory bar is not. Your distilled field knowledge lives below the line — which is why it compounds instead of evaporating.

The model is rented and improves on someone else's schedule. The skeleton is shared and improves when I push a commit. The distilled knowledge is yours alone — it is the part of the system that knows your database's traps, your methods' failure modes, and your field's standards. That layer, not the model, is where a research group's edge will live.

What a session actually looks like

Condensed and illustrative, but faithful to the choreography — the interesting decisions come to you; the mechanics don't:

Install it, break it, tell me what it should do next

The public plugin is the sanitized core of the orchestra I run every day, and it is deliberately unfinished — because the finishing is yours to do, in your field. If you build one, I want to hear what it learned.

⭐ The Research Orchestra on GitHub The blog series on agents norman.guo@slu.edu

Norman (Xuxi) Guo · Saint Louis University · built with Claude Code · this page was produced by the orchestra's own tooling