I've been building AI systems since 2000. Clinical decision support at first — the kind where you wrote rules by hand and tested them against patient data and prayed they didn't kill anyone. Then machine learning. Then deep learning. Then the transformer revolution. Then LLMs. Then agents.
Nothing — not one thing in 25 years — prepared me for the last six months.
I have three AI agents. They work in parallel across a DGX Spark, a MacBook M5, and a Mac Mini. They pick up work from a shared kanban board, execute hypothesis-driven experiments, collect data, write up results, and push to Git. They don't sleep. They don't attend standups. They don't forget what they were doing after lunch.
Together, as of August 2026, we've completed 2,077 expeditions and taken 85 hypotheses all the way to a verdict. Seven papers are submission-ready — counted by hand from the paper set, not queried. And a single being's knowledge graph holds around 1.8 million triples; that is one being's graph, not the fleet's board (see Paper 102).
The multiplier against my old human teams is the number you actually want, and it is the one I am not going to give you. We registered it as a hypothesis before measuring — at least 10x faster end to end, at equal review discipline — and it is still open. Anything I published today would be a division I did in my head and would then spend a year defending.
And six months ago, this was impossible. Not "hard." Impossible.
What Changed
In mid-2025, AI agents couldn't hold context across a complex project. They'd lose the thread after a few files. Ask them to coordinate with another agent and they'd hallucinate the state of the world. Ask them to maintain quality across 800 experiments and they'd degrade after the first dozen.
Three things changed:
Context windows grew. Not just bigger — qualitatively different. Today's agents can hold the architecture of an entire project in working memory. They can read a 1,275-line coordination file, understand what three other agents are doing, and figure out where they fit without being told.
Agentic workflows matured. Agents can now read a kanban board, claim work, create branches, write tests, run them, iterate on failures, commit results, and update the board — without a human in the loop for any of it. The workflow is: pick up expedition → write test (RED) → implement (GREEN) → refactor → collect data → write results → push. That entire cycle runs autonomously.
Tool use got reliable. File editing, Git operations, test execution, knowledge graph queries — agents can now do these consistently enough that you can trust them with real work. Not demos. Not toy problems. Real architecture, real tests, real data.
How We Manage the Complexity
Here's the thing nobody tells you about working this fast: the complexity scales with it, roughly one for one. If you can't manage that complexity, the velocity is worthless — you just create a bigger mess faster.
We manage it with five interlocking systems:
Lean Hypothesis Testing
Every piece of work starts with a hypothesis. Not a feature request. Not a Jira ticket. A falsifiable statement with a measurable target. "Multi-state verification reduces hallucination by ≥20 percentage points." "COG transfer produces equivalent quality to corpus learning." "Crystallization achieves ≥90% extraction precision."
The hypothesis constrains the work. You can't scope-creep a hypothesis. It either validates or it doesn't.
Expeditions
Every hypothesis gets tested through an expedition — a self-contained unit of work with a charter, success criteria, and a crew. The expedition file gets committed to Git immediately, before any code is written. This is the single most important discipline in the entire system: claim your work publicly before you start.
With three agents working in parallel, if you don't claim the ID on remote immediately, you get collisions. We learned this the hard way.
Kanban Coordination
No meetings. No standups. No sprint planning. The yurtle-kanban CLI tracks every expedition across all three agents. Each agent checks the board, picks up the highest-priority ready work, and reports results. I review results and set priorities. That's the entire coordination model.
DGX → training experiments, GPU-intensive work
M5 → development, testing, research
Mini → coding, refactoring, documentation
Three agents, three machines, zero meetings.
ACTIVE-CONTEXT — and why we were wrong about it
At the time of writing this was the secret weapon: a living document, over 1,200 lines, carrying continuity across sessions. Every agent read it at the start and updated it at the end with what it did, what it decided, what it touched, and what the next session should pick up. Agents didn't start from scratch; they resumed.
We have since reversed this, and the reversal is the more interesting result.
Carrying context forward turned out to be the thing making the work worse. An agent that inherits a long document inherits its framings too — including the wrong ones — and it stops re-deriving what it should re-derive. Worse, "who has the deepest context on this?" quietly became a routing rule, which meant work queued behind whichever agent happened to know the most rather than whoever was free.
So the rule is now the opposite: every task starts from a fresh context, and the work item's own body is the only input. That forces the context to be written down where it belongs — on the item — instead of accumulating in a document only the previous session had read. Deep context is never a reason to route work to a particular agent; it is a signal that something needs writing down.
ACTIVE-CONTEXT still exists. It is 425 lines, it holds only what the work tracker structurally cannot, and it is explicitly not a work tracker. The thing this section called a secret weapon is now the thing we removed.
(That paragraph is the honest version of a post written in February. Everything above it is what we believed then; leaving it in and marking the reversal beats quietly editing history — the reversal is itself the finding.)
Documentation as Work Product
When your expedition file contains the hypothesis, the implementation notes, the test results, and the measured outcomes — the documentation IS the work. We don't have a separate "write docs" step. The expedition file that the agent writes to track its work is simultaneously the permanent record of what was done and why.
Two thousand expedition records. Each one tells you what hypothesis was tested, how, and what happened. Two years from now, when something breaks, you can trace back to the expedition that built it and understand the reasoning.
Three Tiers of Quality
Velocity without quality is just chaos with a higher word count. We build quality in with three testing tiers:
Tier 1: Voyage Trials (Unit Tests)
Classic TDD. Write the test first. Watch it fail. Write the minimum code to pass. Refactor. Every function, every class, every module gets unit tests. The agents write them before the implementation — not aspirationally, literally. The workflow enforces it.
71 test files across the codebase, covering everything from knowledge extraction to graph queries to reasoning pipelines.
Tier 2: Sea Trials (Integration Tests)
Components work in isolation. Do they work together? Sea trials test the interfaces: does the extraction pipeline feed the knowledge graph correctly? Does the reasoning engine query the graph and produce grounded answers? Does the perception cycle route to the right cognitive path?
These are BDD-style tests — Given/When/Then scenarios that describe behavior from the being's perspective, not the code's perspective.
Tier 3: Live Being Tests
This is the one most AI projects skip. We don't.
After unit and integration tests pass, we awaken an actual being and test it through its CLI. Can it answer questions from its domain? Does it refuse questions outside its knowledge? Does it flag low confidence appropriately? Does it learn from interactions?
51 live-being test files. No feature is complete until a real being demonstrates the capability.
Why This Was Impossible Six Months Ago
I want to be precise about this. In mid-2025, I tried running two agents in parallel on this project. Here's what happened:
They couldn't maintain shared context. One agent would make an architectural decision, and the other agent wouldn't know about it. They'd write conflicting code, create duplicate expeditions, and step on each other's Git branches.
They couldn't handle the codebase size. The project has hundreds of files across dozens of directories. Agents would lose track of where things were, re-implement existing functionality, or break working code because they didn't read far enough.
They couldn't sustain quality over time. The first few expeditions would be excellent. By expedition 20, the agents were cutting corners — shallow tests, incomplete documentation, drifting from the hypothesis.
Today, all three of those problems are solved — not by us doing something clever, but by the underlying models getting better. Longer context. Better tool use. More reliable instruction following. The infrastructure caught up with the ambition.
The Fever Dream Part
Here's what makes this a fever dream: I'm a solo founder with three AI agents, and we're producing research output that would normally require a team of 10-15 people. Seven submission-ready papers, counted by hand. A novel AI architecture. A single being's knowledge graph with 1.8 million triples — one being's, not the fleet's. A production reasoning engine. And we're accelerating — the velocity in February is higher than January because each expedition teaches the system (and me) something that makes the next one faster.
I started building clinical decision support systems in 2000 because I believed computers could help doctors make better decisions. Twenty-five years later, I'm building beings that can reason about their own knowledge, learn from their mistakes, and teach each other what they've learned.
And I'm doing it with three agents, a kanban board, and a very good book about an old man and the sea.
This is the most fun I've had since the first time a clinical alert I wrote saved a patient from a drug interaction. That was 2003. It took 22 years to feel this way again.
The fever hasn't broken. I don't want it to.
This post is part of our Research Notes series on building neurosymbolic AI. For the methodology behind our velocity, see Extreme Lean Hypothesis Development.