Agentic research workflows

An introduction to using Codex for research workflows
and getting a project-specific knowledge base started

Chris Sweet

Charles Vardeman

Priscila Moreira

James Sweet

September 21, 2026

The bottleneck moved

The problem with a fast, plausible collaborator

Research is a loop: hypothesize, write the code, analyze, test, revise, and go round again. Producing each result used to be the slow part.

AI now appears to remove that bottleneck. It writes complex code, carries a vast working knowledge of statistics and analysis methods, and returns test results ready to present.

So the bottleneck of research is no longer producing results. It is knowing which results deserve belief.

Plausibility is the enemy. From our own project record, the AI describing its own failure, verbatim:

“The worst failure of this project: I built a tractable proxy instead of the user’s hypothesis, and let loose language hide the substitution.” Lessons-Learned.md, project wiki, 2026-08-19, recorded by the AI and found on query

Nothing was wrong with the output. It ran, it passed, it read well. It just was not the thing we set out to know. We only caught it because the AI had written the failure into a durable memory we could go back and read.

Tip 1. Have the LLM record what it learns into a durable memory you keep and can read back, not a chat window that vanishes. The quote above is from ours.

Open cold with the quote if comfortable. Land in the first minute: this failure was caught, recorded by the AI in its own words, and became a rule. End on the memory seed: we only know about it because it was written into a durable memory we could query, which is exactly what the rest of the deck builds. The talk is about the machinery that makes that the normal outcome, not a lucky catch. Do not name the domain yet; the problem is universal.

What epistemic discipline is

Habits you already have, that AI speed breaks

Epistemic discipline turns a produced result into something you actually know: justified, not merely generated. In practice, a few rules about what must be recorded, and carried with the claim, before it enters the record.

You already practice this. Each one is a standard scientific habit.

The habit	What you already call it
Provenance. a claim carries where it came from, and its scope	citation
Durable memory. what was tried, decided, and abandoned is written down	a lab notebook
Pre-commitment. targets declared before the data arrives	pre-registration

Why it breaks with AI

The habits live in your head and in a chat window that vanishes when the session ends. At AI speed they are the first thing skipped: when a result arrives in minutes, the provenance and the notes are what get dropped.

And AI discards and regenerates work at each step, instead of a small, preserving epsilon step that keeps what was already verified.

Seen here: asked to consolidate three reports into one paper, it regenerated rather than preserved, and the draft did not even describe the framework the reports exist to present. Filed as a dead end.

So stop remembering the discipline. Its key element is memory: move the provenance and the notes out of your head into an artifact the AI writes and you read. Get the memory right and the discipline holds.

This is the motivation slide; its job is to hand off to the wiki. The claim is not that AI needs a new epistemology; it is that AI-speed research needs the old habits moved out of your head, because no one, human or AI, keeps habits at that pace. Example source: consolidation regenerated and lost the framework the reports exist to present (Capabilities-Ledger dead ends). The next slides name that artifact, an llm-wiki, and build one live in Codex.

What kind of memory?

Five kinds, only one is durable and yours to read

An agent has several memories. Most are frozen, optional, scoped, or temporary. The question that matters: which one still holds your project’s knowledge after the session ends?

The memory	What it is	How long it lasts
Embedded (training)	the model's learned world knowledge	frozen at the cutoff
Local memories	optional machine-local cross-session store (Codex /memories)	off by default, empty here
AGENTS.md	scoped instructions, loaded per folder at startup	rules, not a knowledge base
Session context	the live conversation and tool results	gone when the session ends
llm-wiki	pages the agent writes and you read, in git	durable, versioned, yours

And local memories are not yours to control. The agent decides whether to write one, and can overwrite or delete it. There is no version history and no backup: if a memory is lost or silently changed, you cannot see what happened or roll it back.

Only the llm-wiki is durable and under your control: the agent writes it, you read it, and it lives in git, so every change is visible, reviewable, and reversible.

Kinds of memory: embedded/parametric in the weights; a local cross-session memory feature (~/.codex/memories_1.sqlite, /memories) that is not a universal global memory; AGENTS.md scoped instructions loaded global-to-cwd at startup; the session context window, bounded and lost after the session; and the llm-wiki, a separate human-readable git repo the agent reads and writes. The control point is the crux: local memories are agent-generated (Codex memories.generate_memories / use_memories), unversioned, and overwritable, so there is no audit trail or backup; the llm-wiki is git-backed, so writes are explicit, reviewable, and reversible. Do not call the local-memory feature “global.” Next slide defines the llm-wiki.

What an llm-wiki is

The memory the LLM writes and you read

• Proposed by Andrej Karpathy (OpenAI founding member, former director of AI at Tesla): dense, interlinked wiki pages as a persistent memory the LLM authors and maintains, kept as plain Markdown in version control.
• A read-write loop that compounds. The LLM reads the wiki at the start of a session to recall where things stand, and writes back during the session to remember what it learned. Each session builds on the last instead of starting cold.
• Auditable by you. Because it is Markdown in git, you can read exactly what the agent knows and see every change it makes.
• Portable as a knowledge bundle: you can share the whole knowledge base and another person’s LLM can read it.

Trusted AI. The human stays in the loop: audit what the agent knows and check any claim at its source. When something is wrong, you catch it and direct the fix, which the agent makes and logs. Accountable and explainable, the trust our group builds toward, not a black box.

A persistent, compounding project memory the LLM writes and you read, not retrieval re-run from scratch on every question.

Zoom into the winner from the memory ladder; do not re-argue the contrast, slide 3 did that. Three beats: (1) the definition and Karpathy provenance; (2) the read-write loop that compounds, read to recall at session start, write to remember at the end; (3) it is plain Markdown in git, so it is auditable and correctable. The one contrast worth keeping is “not RAG re-run per question.” Framing from llm-wiki.md (persistent, compounding artifact the LLM owns and writes, you read). Next: build one live in Codex.

How to build an llm-wiki with Codex

The tutorial, run with students on 2026-09-15

llm-wiki is a Gist from Andrej Karpathy, an idea rather than an implementation. Our implementation assumes the following:

• We assume project-based work, so there is a base GitHub repo for code, data, and artifacts.
• By default we create the wiki as a GitHub wiki, a special repository GitHub uses for its wiki functionality, so you can view it in the online GitHub interface, shown here.
• Other wiki destinations are available.

The next slides walk the whole process, built live in Codex: install, initialize, ingest a paper, run a real prediction, and record it as a durable wiki page.

github.com/chrissweet/codex-llm-wiki-test/wiki

Transition. The rest is not slides, it is the thing itself. If running live is risky, these are captured screenshots of the same session. Keep it moving; the payoff slide (does it work) comes right after.

Demo 1: install the plugin, make the repo

One marketplace, two commands

Our implementation of llm-wiki provides our own marketplace, a storefront for plugins, and we have versions for the AI harnesses Codex, Claude, and Cursor.

Install the plugin from the LA3D marketplace:

$ codex plugin marketplace add LA3D-LLM-Agents/llm-wiki-colab

Marketplace `llm-wiki-colab` added.

$ codex plugin add llm-wiki@llm-wiki-colab

Added plugin `llm-wiki` from marketplace `llm-wiki-colab` (0.4.0).

Codex loads plugins at startup, so exit and restart Codex, and accept the plugin’s hooks when prompted. Then create the project repo:

$ gh repo create chrissweet/codex-llm-wiki-test --public

✓ Created repository chrissweet/codex-llm-wiki-test on GitHub

Same wiki, any harness. The identical plugin installs in Claude Code (/plugin marketplace add, /plugin install), Codex (codex plugin marketplace add, codex plugin add), and Cursor (cursor-agent plugin marketplace add).

The marketplace is the LA3D-LLM-Agents/llm-wiki-colab repo; the plugin is llm-wiki. Restart and the hook-trust prompt are the two Codex-specific gotchas. The empty repo is where the wiki will attach.

Demo 2: initialize the wiki

wiki-init, GitHub-backed

Run the init skill and choose GitHub:

$ $llm-wiki:wiki-init

? storage backend → GitHub

$ bash "$SKILL_DIRECTORY/scripts/init-wiki.sh" --github --agent "codex"

created .llm-wiki/ (own git repo, attached to the wiki remote)

It scaffolds .llm-wiki/ as its own git repository, attaches it to the repository’s GitHub wiki remote, and writes the SCHEMA plus navigation pages. Result: a blank llm-wiki, ready to push.

Those pages make the wiki self-describing:

• SCHEMA: the conventions, page format, required frontmatter, and the typed links between pages.
• index: the catalog of every page, the wiki’s table of contents.
• log: the append-only, dated record of what was done, by who and using which agent.

Each is namespaced to the project (index_codex-llm-wiki-test, SCHEMA_codex-llm-wiki-test, log_codex-llm-wiki-test), so pages stay unambiguous when wikis are shared or merged.

The wiki is a separate repo from your code. Code and artifacts live in the project; durable knowledge lives in .llm-wiki/.

If GitHub reports the wiki is unavailable, enable the repo wiki and create its first page, then rerun init. Show the two-history point: git -C .llm-wiki log is separate from the code repo.

Demo 3: ingest the AlphaFold paper

wiki-source: one paper, five pages

Ingest turns an external source into wiki pages: the agent reads it and writes summarized, linked, cited pages. AlphaFold is DeepMind’s protein-structure predictor; our source is its 2021 Nature paper.

ingest paper AlphaFold-Protein-Structure-2021.pdf

+ source summary + 4 concept pages

Plain language is enough: asking to ingest makes Codex call the $llm-wiki:wiki-source skill.

One ingest produced a source summary plus four linked concept pages:

• Architecture — Evoformer and structure module.
• Training and data — datasets and training cutoff.
• Evaluation and confidence — the pLDDT and pTM metrics.
• Limitations and inference — where it is unreliable.
• All cross-linked wiki style, with links typed where the relationship is clear.

Pages, not chunks. Preserve what a future reader needs: dataset scope, training cutoffs, named methods, exact metrics, confidence intervals, limitations. A number without a source page does not exist for the project.

The ingested pages integrate into the existing wiki: related pages are updated, any contradiction with what the wiki already claims is reconciled, and back-references are fixed both ways. The ingest is recorded in the index and log, then a verification gate checks every page for unsupported claims and missing provenance before it is committed.

For a PDF, the PDF skill extracts text and figures. The pattern: capture detail a future session will need, so the wiki answers without re-reading the paper.

Demo 4: run AlphaFold on chignolin

A ten-residue mini-protein: GYDPETGTWG

The power of AI removes friction and accelerates understanding. Just from the paper, I can test the ideas by getting Codex to find the code repository, install the software, and run it locally without intervention. In this demonstration I asked it to find a small molecule (it suggested chignolin) and get it to fold it.

ColabFold 1.6.2, AlphaFold2 pTM, single-sequence MSA, five models, seed 0, three recycles, CPU.

JAX_PLATFORMS=cpu colabfold_batch chignolin.fasta results/

--msa-mode single_sequence --model-type alphafold2_ptm

--num-models 5 --num-recycle 3 --random-seed 0 --max-msa 1:1

ranked PDB + pLDDT/PAE plots + run log

Output	Value
Mean pLDDT (10 res)	93.4
pTM	0.06
Max aligned error	5.35 Å

High pLDDT is confident local geometry; pTM 0.06 is poor global-fold confidence, expected here because a single-sequence MSA gives AlphaFold no evolutionary signal. These are model outputs, not experimental validation.

Experiment skill. The llm-wiki plugin includes an Experiment skill that documents an activity like this as a scientific experiment. It is called silently when a run produces results worth keeping.

Chignolin is small and fast, with a known beta-hairpin folded state. The test is structure prediction, not folding kinetics or a free-energy landscape. The honest caveat on pTM is the point: the wiki records the metric and its limit together.

Exact run (for Q&A). Full command: MPLCONFIGDIR=/tmp/chignolin-mpl JAX_PLATFORMS=cpu .venv-colabfold/bin/colabfold_batch experiments/chignolin-prediction/chignolin.fasta experiments/chignolin-prediction/results --msa-mode single_sequence --model-type alphafold2_ptm --num-models 5 --num-recycle 3 --random-seed 0 --max-msa 1:1 --data .cache-colabfold. Input FASTA: >chignolin / GYDPETGTWG. Inspect the outputs with find experiments/chignolin-prediction/results -maxdepth 2 -type f -print | sort, then a small python3 json reader over *scores*.json / *rank_001*.json for ptm, iptm, mean_plddt, max_pae. Measured: mean pLDDT 93.4, pTM 0.06, max PAE 5.34765625 Angstrom. Outputs in experiments/chignolin-prediction/results/.

Demo 5: the result becomes a wiki page

Run in, durable page out

One plain-language line produced the figure:

can you generate a pre and post image for the molecule?

Codex used its built-in image tool to make this unfolded → folded illustration of chignolin.

$llm-wiki:wiki-experiment filed Chignolin-AlphaFold-Prediction. The skill:

• captures the configuration and metrics: parameters, seeds, dataset, headline numbers;
• keeps the interpretation limits with the numbers, filing results honestly;
• notes what changed vs. a previous run, and anything surprising;
• records provenance: links to the results directory and the commit;
• integrates with related pages and reconciles contradictions;
• updates the index and log, runs the verification gate, then commits.

Live page: github.com/chrissweet/codex-llm-wiki-test/wiki

End of demo. The run, its numbers, and its images are now one linked, queryable page, not scattered files that vanish when the session ends. Hand to the payoff: does this memory actually work?

The before/after image is an AI-generated illustration: asked to “generate a pre and post image for the molecule,” Codex used its image-generation tool to make a side-by-side unfolded/folded depiction of chignolin (beta-hairpin), saved to experiments/chignolin-prediction/chignolin-before-after.png. It is explicitly not a measured folding trajectory, an MD result, or a rendering of the AlphaFold PDB.

Demo 6: recall, the loop closes

Ask the wiki, not the paper

A later session asks about the run. The agent answers from the page it wrote, no paper, no rerun:

what did our chignolin run find, and why is the confidence what it is?

Our single-sequence ColabFold run produced a top chignolin model with

mean pLDDT 93.4, but pTM 0.06 and maximum PAE 5.35 Å. It was confident

in local geometry, but not the overall fold. The low global confidence

reflects the absence of evolutionary MSA information; this was a static

prediction, not folding dynamics.

 

Wiki pages read:

- .llm-wiki/Chignolin-AlphaFold-Prediction.md

- .llm-wiki/AlphaFold-Limitations-and-Inference.md

 

I did not reopen the AlphaFold PDF or rerun the experiment.

Write once, recall forever. The next session builds on the page instead of re-deriving it: the read half of the loop, closed.

Real recall run: the codex-llm-wiki-test session was asked “what did our chignolin run find, and why is the confidence what it is?”, constrained to its .llm-wiki pages. It answered from Chignolin-AlphaFold-Prediction and AlphaFold-Limitations-and-Inference (pLDDT 93.4, pTM 0.06, max PAE 5.35 Angstrom; confident local geometry, poor global fold from the single-sequence MSA; static prediction, not dynamics) and did not reopen the PDF or rerun. This is the read half of the read-write loop the deck opened with.

The wiki is git: commit, pull, push

Say it in plain language; the agent runs the git

The wiki is its own git repo, so every page is versioned, diffable, and reversible.

• Commits happen automatically. After each ingest or experiment the agent commits to .llm-wiki/, no need to ask; local commits are cheap and reversible.
• Sync in plain language. Say “pull the wiki repo” or “push the wiki repo” and the agent runs the git for you, no commands to remember.
• Pushes don’t collide. The plugin refreshes the wiki from the remote at the start of every session (fetch, then fast-forward, with any local work preserved), so you always build on the latest memory and your push lands cleanly.
• The main repo too. Your project’s code repo (code, data, artifacts) is also git: commit, pull, and push it with the same plain-language commands.

“Push the wiki repo” lands it on GitHub, versioned and audit-ready, even when the team is writing at once.

Plugin behavior: every wiki edit ends with a local commit in .llm-wiki/ (run without asking; reversible), and push only when the user asks; the user just says “pull/push the wiki repo” and the agent runs the git. The anti-collision mechanism is the session-start refresh in hooks/session-start.d/20-update-wiki.py: when the wiki is clean it detects the remote default branch, fetch origin, then merge --ff-only, so the local wiki starts each session at the latest remote and later pushes are clean fast-forwards; if the wiki is dirty or cannot fast-forward, it skips and preserves local work. Extra layer for truly concurrent writers (project/template tooling, not the base plugin): the wiki_push wrapper (scripts/wiki-write-protocol/) adds optimistic push-with-retry plus index_*/log_* merge=union.

More skills: maintain, share, consult

Beyond building the wiki

Building the wiki is the start. Three more skills keep it healthy and connect it to other projects:

• wiki-lint — a health check over the wiki: finds orphan pages, dead links, stale claims, missing frontmatter, and one-way cross-references, then offers fixes. Keeps the compounding memory honest as it grows.
• wiki-enroll — publishes an agent Card and a discovery topic so this wiki becomes findable by peer llm-wiki agents in the federation.
• wiki-ask — consults another project’s wiki via the ask primitive: it clones that agent’s wiki and queries it, so you draw on another project’s durable memory without leaving your session. It authenticates via GitHub, so without at least read access to that wiki you cannot query it.

One wiki you maintain (lint), publish (enroll), and query across (ask): durable memory that compounds and connects.

These round out the toolkit. wiki-lint is the periodic health pass (orphans, dead links, stale claims, missing back-references, run every several sessions or after a big ingest). wiki-enroll makes the repo discoverable in the LA3D federation by writing a Card and adding the nd-llm-wiki topic. wiki-ask is the federation consumer: clone-and-invoke another agent’s wiki to answer a question from its memory, direct mode (name the agent) or discovery mode (pick from candidates). Not covered here: message/post async modes are not part of ask.

Turning results into knowledge

The discipline, made concrete

Trustworthy results are not automatic enforcement; they come from encoded discipline the agent follows, plus reminders, run by the harness:

1 · Real-output guidanceuse real outputs; scope every number to its corpus; report failures truthfully

2 · Verification gatebefore committing, the agent re-reads each page against a checklist and fixes failures

3 · Discipline gatesa named list of always-wrong shortcuts the agent must reject

4 · Advisory hookssession-start and post-edit hooks inject context and reminders; the gate does the content check

How it runs, one loop:

1 · Session starta hook loads the guidance + the wiki's index and recent log into the agent

→

2 · Workskills carry the read and write procedures for pages

→

3 · After an edita hook reminds; the agent runs the gate and fixes failures

→

4 · Committo git; plain Markdown, so every step is auditable

A chat app runs none of this loop, which is why we build in Codex and Claude Code.

These are agent-followed discipline plus advisory reminders, not automated blocking. Box 1 guidance lives in the plugin (core/templates/guidance.md, core/agents/discipline-gates.md, skill instructions), injected at session start. Box 2 verification gate is an agent-run pre-commit checklist (core/agents/verification-gate.md): re-read each page, apply the criteria, fix, then commit, not an automatic blocker. Box 3 discipline-gates names the “Universal Rationalizations (Always Wrong)”. Box 4: the PostToolUse hook is advisory and exits 0, it does not inspect content or block writes, it only reminds the agent to run the gate; headless codex exec runs no hooks and is a separate mode. This slide is the payoff of the epistemic-discipline setup on “What epistemic discipline is”, and it precedes the measurement so the zero fabrications arrives already explained.

Discipline gates: the shortcuts we reject

Named always-wrong rationalizations, caught before the write

The plugin names the excuses an agent might use to cut a corner, so it self-catches before committing. A few:

The shortcut	Why it is rejected
"I'll add the corpus tag or cross-links later"	Later never comes; do it now while context is fresh.
"The estimate or projection is fine to file"	Numbers must be real outputs or citations; projections are marked as such, never slipped in as fact.
"Close enough to compare these two corpora directly"	A gap between numbers on different corpora is not a gap; tag each with its corpus.
"Good enough to commit"	Run the verification gate first; it costs seconds.
"These changes don't need a log entry"	The log is the next session's input; skipping it makes the change invisible.

The list is meant to grow: each real mistake that traces back to a rationalization becomes a new row.

From the plugin’s core/agents/discipline-gates.md “Universal Rationalizations (Always Wrong)” table. These are the counters the agent applies before a write commits, the discipline half of turning results into knowledge. Also in that file: three gate types (Design, Verification, Sequential) and a skill-dependency chain (a new typed edge must update the reciprocal edge; a numbered claim must append a dated log entry).

Does the memory actually work?

Two measurements: head to head, and at scale

Forty questions on one real project: reading the llm-wiki answered 90% correctly and fabricated nothing, roughly double RAG’s 42% (10 fabrications); no-context scored 2%. And accuracy holds as the wiki grows to thousands of pages.

Head to head (n=40, one project, blind judge)

Approach	Correct	Overall	Fabr.
Model alone	2%	0.10	2
Plain RAG	42%	1.32	10
llm-wiki	90%	2.65	0

At scale (500 to 4,000 real pages, Sonnet 5)

pages	recall	reads	greps	index
500	100%	5	5	90 KB
1,077	100%	5	7	199 KB
2,028	100%	3	5	384 KB
4,013	98%	4	6	778 KB

Recall stays near-perfect across 8x growth, and per-query cost stays flat, because the agent greps the index rather than reading it whole (retrieval is O(1) in corpus size).

Head-to-head source: the WGRA post “llm-wiki vs RAG” and Wiki-vs-RAG-First-Run-Results / Cross-Model-Wiki-Reading. n=40 on one real research project, blind judge; 90% vs RAG’s 42%, a perfect 3.00 on method/judgment questions, zero fabrications; model-alone 2% shows the wiki adds the value. Scaling source: llm-wiki-test-harness/docs/scaling-report.md (Chris Sweet, 2026-09-08), real Sonnet 5 query runs (not projections) over 500 to 4,013 real arXiv pages around a 12-paper gold set; current one-line index; recall by gold-keyword match on specific-fact questions. Headline: recall flat (100% to 98%) and per-query cost bounded (3-6 reads, 5-7 greps) across 8x growth because the agent greps the index. The two panels are different experiments (blind-judge QA vs retrieval-recall); keep them distinct.

This wiki, mapped to a Knowledge Graph

Generated by the wiki-kg plugin from the LA3D-LLM-Agents/llm-wiki-marketplace

The interactive graph of this project’s own wiki, generated by the wiki-kg / wiki-graph-viz plugin. Drag nodes to explore, search by name, and color by type or by recency (git dates). Same structure a reader gets from the GitHub wiki; the typed edges are topology, not the query path.

The llm-wiki marketplace

Extra tooling, installed like the core plugin

Our own marketplace, LA3D-LLM-Agents/llm-wiki-marketplace, ships the extras alongside the core llm-wiki plugin, dual Codex and Claude Code.

• wiki-kg — build, query, and visualize a typed-edge knowledge graph from a wiki (rdflib + pyshacl, in-process). The map on the last slide came from here.
• wiki-agent-msg — cross-harness live messaging: list and message Claude Code and Codex sessions on the same machine.

Install like the core plugin:

$ codex plugin marketplace add LA3D-LLM-Agents/llm-wiki-marketplace

$ codex plugin add wiki-kg@llm-wiki-marketplace

Claude Code: /plugin marketplace add LA3D-LLM-Agents/llm-wiki-marketplace then /plugin install wiki-kg@llm-wiki-marketplace.

Each page becomes typed RDF, so the wiki is a graph you can draw (above) or query with SPARQL:

@prefix wiki: <https://la3d.github.io/llm-wiki-colab/page/> .
@prefix kg:   <https://la3d.github.io/llm-wiki-colab/ontology#> .

wiki:Constraining-the-Field-for-Trust a kg:Synthesis ;
    dcterms:title "Constraining-the-Field-for-Trust" ;
    kg:extends   wiki:Lightweight-Structural-Graphs ;
    kg:mentions  wiki:LLM-Wiki-Read-Path , wiki:Vision .

LA3D-LLM-Agents/llm-wiki-marketplace lists two plugins, wiki-kg (build/query/visualize the KG) and wiki-agent-msg (cross-harness messaging), with a shared plugin tree carrying both .claude-plugin and .codex-plugin manifests. Same marketplace-add / plugin-add pattern as the core plugin from llm-wiki-colab; swap the plugin name. This is where the graph on the previous slide came from. The Turtle snippet is a real node from the wiki’s graph (Constraining-the-Field-for-Trust: type Synthesis, extends Lightweight-Structural-Graphs, mentions LLM-Wiki-Read-Path/Vision).

Read more: the WGRA Nuggets blog

The ideas behind this, one nugget at a time

Short, self-contained posts you can graze in any order. The lineage traces back to Karpathy’s llm-wiki. Topics include:

• Foundations — why agentic software breaks deterministic habits.
• Evidence — llm-wiki vs RAG, and a Bayesian harness for honest evaluation.
• The knowledge graph — typed edges, small ontologies, catalog to content.
• Ecosystem — federation, connectors, data fabrics, a tools marketplace, bundles.
• Practice — standing up a wiki, and how to talk to a research agent.

la3d.github.io/WGRA/blog

The blog is browsable bites on the WGRA ideas, one idea per post, grouped by category (evidence, foundations, ecosystem, graph, practice, retrieval, and more). Point people at it as the middle ground between the one-page flyer and the long deep-dive pages.

Part of a series

Talks, and where to read more

Talks

• Agentic research workflows (this talk) — Codex to start a project knowledge base.
• Research memory that compounds — sources into a durable, queryable llm-wiki.
• Knowledge: Extract, Retrieve, Synthesize — the flow and the knowledge graph.

Pages

• The WGRA overview and the Nuggets blog.
• Ecosystem: Research Agents (the competitive edge), the Knowledge Fabric.
• Deep dives: memory that compounds, team scale, agent capability, the knowledge graph, knowledge bundles.

All at la3d.github.io/WGRA, plus the paper Beyond Memory (Saboia Moreira et al., 2026).

The three talks are in the site’s Talks menu. Deep dives (Memory that compounds, Team scale, Agent capability, The knowledge graph, Knowledge Bundles) and the paper are linked from the WGRA landing page. Use this slide to send people somewhere after the talk.

Questions

Thank you

Agentic research workflows. In one Codex session we installed the plugin, built a durable llm-wiki, ingested a paper, ran a real AlphaFold prediction, and recorded it as a linked, queryable page. That discipline turns results into knowledge you can trust, and it measurably works: it beat plain RAG with zero fabrications, and held near-perfect recall to thousands of pages.

Build one: github.com/chrissweet/codex-llm-wiki-test/wiki

Chris Sweet, Charles Vardeman, Priscila Moreira, James Sweet

Close. Point back at the public wiki as the thing they can go build today: github.com/chrissweet/codex-llm-wiki-test/wiki. Offer the tutorial guide as the step-by-step.