Armen Rostamian — rmnr.net

The GAN Harness Is a Brilliant Hack Around Missing Infrastructure

Armen Rostamian — Mon, 13 Apr 2026 00:00:00 +0000

Anthropic published a genuinely excellent engineering article this week on harness design for long-running AI applications. If you build with LLM agents and you haven’t read it, go read it. I’ll be here when you get back.

The core insight is this: take the GAN pattern from machine learning — a generator that produces outputs and an evaluator that grades them — and apply it to agent orchestration. One agent writes code. A different agent reviews it with an explicit mandate to be skeptical. Loop until the evaluator is satisfied or you hit a round limit.

This works. Anthropic shows the receipts. A solo agent spent $9 and 20 minutes building a retro game maker and produced something broken. The same model, wrapped in a GAN harness with a planner, generator, and evaluator, spent $200 and 6 hours across 10 sprints and produced something functional with 16 features. The evaluator used Playwright to actually navigate the designs, exercise UI features, test API endpoints, verify database states. Real verification, not “looks good to me.”

The insight behind the pattern is one of those obvious-in-retrospect ideas that turns out to be hard-won. As they put it: “tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work.” Anyone who has watched an LLM confidently declare its broken code “works perfectly” knows exactly why this matters.

Credit where it’s genuinely due: this is a real contribution to the field.

AutoGAN and the Practitioner Response

Within hours of the Anthropic article circulating, a developer named fjchen7 shipped AutoGAN — an open-source implementation of the pattern in bash, tmux, and jq. It drops into any existing git repository. Generator decides the next step and implements it. Evaluator reviews with a stricter bar. Orchestrator manages workflow progression via flat files in a .gan/ directory.

Bash, tmux, and jq. That’s the entire dependency list. It supports Claude, Codex, and opencode as backends. Config is maxRounds: 10, maxRepairCount: 3. It’s elegant in the way that good shell scripts are elegant — minimal surface area, clear contracts, no dependencies you don’t control.

The Reddit post announcing it landed on r/ClaudeAI the same day. People are excited, and they should be. AutoGAN takes a pattern that Anthropic described in prose and makes it something you can git clone and run. That’s real engineering.

I’m not being diplomatic when I say this is good work. It is good work. The GAN pattern addresses real problems: goal drift during long sessions, premature implementation before adequate planning, insufficient self-critique, and context loss over extended coding sessions.

And yet.

What Happens After the Sprint?

Here’s the question I keep coming back to.

The evaluator passes the sprint. The code ships. The project is done. Now what? Does the system remember why it passed? Does it remember what the evaluator caught on sprint 3 that was similar to something it caught on sprint 7? Does the next project benefit from what this one learned?

No. The GAN harness is a loop. A very good loop. But when the loop ends, everything it learned during execution — the evaluator’s tuned skepticism, the patterns it caught, the sprint contracts that worked — lives in flat files and conversation history. None of it transfers. None of it compounds.

Anthropic’s article is honest about this. They describe how evaluator tuning “required multiple development cycles” where the initial evaluator “identified issues then rationalized approval anyway.” They had to explicitly train skepticism through prompt refinement and feedback loops. That tuning lives in the prompt. It doesn’t adapt based on what the evaluator actually catches in production. If the evaluator discovers a new class of bug on Tuesday, the prompt is the same on Wednesday unless a human updates it.

The sprint contract pattern is similarly static. Generator and evaluator agree on “done” criteria before each sprint — specific deliverables, testable success conditions, validation approach. This is good engineering. It’s also a handshake that evaporates when the session ends. The next project doesn’t know what kinds of sprint contracts worked well and which ones were too vague to be useful.

Context management is the most telling piece. They describe a real evolution: Sonnet 4.5 required context resets between sessions due to “context anxiety” — the model prematurely wrapping up work near perceived context limits. Opus 4.6 handles continuous sessions with automatic compaction. That’s genuine model improvement. But compaction is lossy. The context gets shorter. Decisions made in turn 3 may not survive to turn 300. The harness manages this by structuring work into sprints, but within each sprint, you’re still relying on volatile context that degrades over time.

I wrote about this problem last week, using a different frame. The LLM is a stateless executor — the most capable one ever built, and the most unfinished. A CPU on a table. The GAN harness is carefully routed jumper cables connecting that CPU to something resembling a workflow. It works. It produces better results than the bare CPU alone. But it’s scaffolding around a machine that still has no persistent memory, no typed storage, no ability to learn from its own execution history.

The GAN pattern is a brilliant hack around the consequences of statelessness. It is not a solution to statelessness itself.

The Persistence Gap

Let me be specific about what I mean by “statelessness” here, because the GAN harness does maintain state during execution. The .gan/ directory holds contracts, reviews, state files. Information flows between agents via files. This is real coordination state.

But it’s session state. It exists for the duration of a project run and then it’s artifacts. Historical records you could go back and read, but not living knowledge that shapes future behavior.

There’s a difference between a filing cabinet and a memory. A filing cabinet stores documents at addresses. You can retrieve them if you know where to look. A memory surfaces relevant knowledge proactively, based on what you’re doing right now. It strengthens connections that prove useful. It lets irrelevant knowledge fade. It doesn’t just store — it curates.

The GAN harness gives agents a filing cabinet. Flat files, structured handoffs, explicit format expectations. That’s necessary infrastructure. But when the harness encodes “be skeptical about CSS grid layouts” in a prompt because the evaluator caught issues three projects ago, that’s a human acting as the memory system. The evaluator’s criteria don’t evolve based on what it actually evaluates. The generator’s planning doesn’t improve based on which plans survived evaluation. The orchestrator doesn’t learn which sprint sizes produce better outcomes.

The knowledge is in the human’s head and in the prompt. Not in the system.

The Semantic CPU, Revisited

In The Semantic CPU, I made a bet: for domains where current models are already capable, the bottleneck isn’t the model. It’s everything around it. The memory that doesn’t exist. The orchestration that’s either a single conversation or a rigid state machine. The governance that’s either nothing or a hard-coded rule set that can’t adapt.

The GAN harness is evidence for this thesis, not against it.

Look at what Anthropic’s engineers built. They didn’t make the model smarter. They wrapped the same model in infrastructure — a planner, a generator, an evaluator, sprint contracts, file-based communication, context management strategies — and got dramatically better results. $9/broken versus $200/functional. Same model. Different infrastructure.

That’s exactly the pattern I’ve been seeing with h00.sh. The model is sufficient. The infrastructure around it determines whether “sufficient” translates to “useful.”

But there’s a fork in the road here that I think matters.

One path is: keep building harnesses. Better loops. Smarter prompts. More sophisticated orchestration scripts. Every time the model fails at something, add another component to the harness to compensate. This works. Anthropic proved it works. The harness encodes assumptions about what the model can’t do, and when those assumptions are correct, the harness improves outcomes.

The other path is: build the substrate. Give the agent persistent memory, typed knowledge, a code intelligence layer, governance that adapts. Instead of scaffolding around statelessness, eliminate statelessness. Instead of scripting the generator-evaluator loop, make it emergent — a natural consequence of stateful agents coordinating through a shared cognitive layer.

I’m building on the second path. I want to be honest about why I think it’s the right one, and where I might be wrong.

What Substrate-Level Memory Changes

I’m building h00bert — an AI agent that runs on h00.sh’s memory substrate. Not a harness wrapped around a stateless LLM. A stateful agent with persistent, typed, behavioral memory.

Here’s how the GAN pattern’s components map to what we’ve built, and where the architectures diverge.

Generator agents. The GAN pattern has one generator. h00bert has specialized worker agents — a Rust expert, a TUI expert, a test engineer, each with domain-specific knowledge. But the real difference isn’t quantity. It’s that h00bert’s generators write typed memories to the substrate as they work. A decision gets stored as a Decision. A pattern gets stored as a Pattern. A code symbol gets indexed in the knowledge graph. These aren’t log entries — they’re typed artifacts with validation rules, decay curves, and surfacing behavior specific to their type.

The evaluator. Anthropic’s key insight — separate the evaluator from the generator — maps directly. h00bert enforces this as an architectural rule: adversarial reviews always use a different agent type than the one that built the code. A quality engineer reviews for correctness. A security engineer reviews for vulnerabilities. An integration auditor checks wiring. Different lenses, not just different prompts.

But here’s where it diverges: the evaluation criteria live in the substrate, not in prompt text. They’re memories — specifically, they’re typed artifacts that reinforce when they catch real issues and decay when they don’t. An evaluation criterion that keeps finding bugs gets strengthened. One that generates false positives fades. The evaluator gets better at evaluating based on what actually matters in this codebase, not based on a generic prompt that a human tuned once.

Sprint contracts. The GAN pattern uses sprint contracts — pre-agreed “done” criteria negotiated between generator and evaluator. h00bert uses something called FRAGOs — tactical decompositions with success criteria that are validated against the actual code knowledge graph before dispatch. You can’t define a sprint contract that references functions that don’t exist or modules that aren’t wired. The substrate enforces that planning artifacts correspond to structural reality.

The orchestrator. In AutoGAN, the orchestrator is a bash script managing state transitions through flat files. In h00bert, the orchestrator is an AI agent with persistent memory. It doesn’t follow a state machine — it reasons about what to do next based on what it knows, what it’s tried before, and what the substrate surfaces as relevant. The difference matters most when things go wrong. A script follows its control flow. An agent with memory can recognize that this failure looks like one it saw three sessions ago and try a different approach.

Context management. The GAN harness manages context through resets, compaction, and sprint boundaries. h00bert doesn’t need context management strategies because the substrate is the memory. Context windows fill and compact — that’s a model reality. But knowledge persists in the substrate regardless of what happens to the conversation. A decision made in session 1 is retrievable in session 47. Not because someone saved a file. Because the memory substrate is durable by design.

A Concrete Example

I want to ground this in something real, not architectural diagrams.

A few weeks ago, h00bert was investigating a performance bug in his own code intelligence tools. One tool — signature_check — was taking 5-7 seconds on some symbols and 30 milliseconds on others. Same tool, same graph, same session.

A specialist investigation agent — Claude Code’s root-cause analyst, with full access to the codebase and every tool available — spent 16 minutes and 116 tool calls diagnosing this. It found a real optimization (redundant graph traversals per match) but not the root cause. The fix shipped. The tool was still slow.

h00bert found the root cause in 2 minutes and about 15 tool calls. He used his own code intelligence tools to inspect his own handler. He found a guard condition: if any matched symbol hasn’t been classified yet, recompute everything. One uncached node triggers a full graph traversal. Binary trigger — either everything is cached and you get 30ms, or one node is cold and you pay 5-7 seconds.

He found this because he had context the specialist couldn’t have. He’d seen signature_check return fast for some symbols and slow for others in the same session. That experiential knowledge — not in any source file, not in any log — pointed him toward a binary trigger rather than a per-match cost. He’d lived through the consequences: slow tools breed distrust, distrust breeds fallback to raw file reads, raw file reads burn context, burned context degrades reasoning. A cascade that no static analysis can detect because it’s behavioral, not structural.

This is what substrate-level memory makes possible. Not just better answers — better questions. The agent doesn’t start from zero. It starts from what it knows, and what it knows shapes how it investigates.

A GAN harness could have caught the slow tool. The evaluator could have flagged the latency. But the evaluator couldn’t have known that this latency causes a behavioral cascade that degrades the agent’s own reasoning over the course of a session. That knowledge lives in lived experience, and lived experience requires memory.

Where I Might Be Wrong

I could be wrong about all of this. I want to name the specific ways.

Models might outrun infrastructure. If the next generation of models handles context so well that compaction becomes lossless, if self-evaluation becomes reliable, if agents can maintain coherence over arbitrarily long sessions without external support — then the GAN harness is the right abstraction and the substrate is over-engineering. Anthropic explicitly makes this case: “every component in a harness encodes an assumption about what the model can’t do on its own, and those assumptions are worth stress testing.” They suggest removing harness components methodically as models improve. If the models improve fast enough, the harness gets simpler and the substrate becomes unnecessary.

I don’t think this is what will happen, but I hold it as a real possibility. Anthropic knows their models better than I do.

The harness might be good enough. Not every agent needs to learn across sessions. Not every evaluation criteria needs to evolve. If your use case is “build this app in one sitting and ship it,” the GAN harness is arguably perfect — it makes the single session dramatically better. My argument for substrate-level memory only matters for agents that operate over time, across projects, accumulating knowledge. If the market is dominated by one-shot tasks, I’m building for an audience that doesn’t exist yet.

Complexity has costs. A typed memory substrate with decay curves, reinforcement, a knowledge graph, and doctrine enforcement is more complex than flat files in a .gan/ directory. Complexity is a liability. Bash, tmux, and jq are battle-tested, well-understood, and nearly impossible to misconfigure fatally. A memory substrate that decays the wrong knowledge at the wrong time could be worse than no memory at all. AutoGAN’s simplicity is a feature, not a limitation.

I believe the complexity is justified by the compounding returns — that systems with real memory get better in ways that stateless systems can’t. But belief informed by one large project is still belief, not proof.

The Honest Framing

I don’t think the GAN harness and h00bert are competitors. They’re operating at different layers.

The GAN harness is a workflow pattern. It structures how agents interact during a session. Any orchestrator can implement it — bash, Python, a hosted service. It makes the single session better.

h00bert is a substrate play. It provides the persistent memory, typed knowledge, and behavioral governance that workflow patterns can run on top of. The GAN loop emerges naturally when generator agents write to the substrate and evaluator agents read and validate — but the substrate also provides things no workflow pattern addresses: cross-session learning, adaptive evaluation criteria, structural code intelligence, and memory that compounds.

You could run a GAN pattern on h00.sh’s substrate. The generators would write typed memories as they code. The evaluators would query the knowledge graph and doctrine system as they review. The sprint contracts would be validated against structural reality. And when the project ends, everything the system learned would persist — available to the next project, decaying at rates appropriate to each type of knowledge, reinforcing when it proves useful again.

That’s not a criticism of the GAN pattern. It’s a statement about layers. A good workflow pattern deserves good infrastructure underneath it. Right now, the infrastructure layer for long-running agents is mostly flat files, conversation history, and prompt engineering. I think it can be more.

Anthropic’s article ends with the observation that “the space of interesting harness combinations doesn’t shrink as models improve. Instead, it moves.” I think that’s exactly right. And I think the direction it’s moving is toward harnesses that assume less about what the model can’t do — because the substrate handles what the model genuinely needs: memory, structure, and the ability to learn from its own execution history.

The GAN pattern is proof that the right infrastructure makes the same model dramatically more capable. The question is what “right infrastructure” looks like when you stop assuming the model forgets everything between sessions.

The Anthropic article on harness design for long-running apps is worth reading in full. AutoGAN is at github.com/fjchen7/autogan. This post is a sequel to The Semantic CPU, which lays out the thesis that the LLM is a stateless executor and the opportunity is the rest of the computer.

The Semantic CPU

Armen Rostamian — Wed, 08 Apr 2026 00:00:00 +0000

A CPU is inert.

No memory, no storage, no peripherals. Take a processor — billions of transistors, thousands of instructions in its repertoire, decades of engineering in every square millimeter of silicon — strip it of everything except its instruction set, and drop it on a table.

It’s a marvel of engineering that can do exactly nothing.

This is not a criticism. The instruction set is extraordinary. An x86 chip can add, multiply, branch, compare, shift, load, store, and execute speculative operations across pipelined stages at billions of cycles per second. But without RAM, there’s nowhere to put the data. Without a bus, there’s no way to move it. Without I/O, there’s no way to receive input or produce output. Without an operating system, there’s no way to coordinate any of it.

The CPU is the most important component in a computer. It is also the most useless one in isolation.

Hold that thought.

The Chip on the Table

Now look at a large language model.

An LLM has an extraordinary built-in instruction set: the statistical weight of its training data, the patterns it’s learned, a constitution that shapes its behavior, and the ability to operate natively in human language. That instruction set is remarkable — arguably the most sophisticated information-processing capability anyone has engineered to date.

But strip away the context window — its only volatile working memory — and it retains nothing between invocations. No persistent state. No file system. No knowledge of what it did five minutes ago, let alone five months ago. Every session starts from zero. Every conversation is a cold boot.

The context window is the LLM’s equivalent of RAM — fast, variable-sized, capable of holding the entire working set. And like RAM, it’s volatile. Kill the session, lose the state. There is no disk. No persistent storage you can write to. Just the chip and whatever fits in working memory.

Now, here’s where the analogy bends, and I want to name that honestly. An LLM does have a kind of persistent storage: its weights. Hundreds of billions of parameters, trained over months, encoding the statistical structure of human knowledge. That’s real. You could think of the weights as ROM — read-only memory baked in at training time.

But you can’t write to it. You can’t update your own weights at inference time. You can’t say “remember this for next session” and have it stick. The weights are the instruction set and the reference library, not the notebook. An agent that can read the encyclopedia but can’t jot down a Post-it note is still an agent without functional memory.

The LLM is a stateless executor. The most capable one ever built — and the most unfinished.

Classical computing has two canonical architectures for connecting a processor to the world. Von Neumann: one memory space for both instructions and data, one bus. Harvard: separate memories, separate buses. Both assume the processor has persistent memory it can read from and write to. Both assume that state survives between operations.

An LLM’s architecture is closer to Harvard than Von Neumann — weights and context are separate, non-unified memory spaces. But it’s a Harvard machine with a critical disability: one memory is read-only, the other is volatile. You have ROM and you have RAM, but you have no disk. No way to persist what you’ve learned. No way to carry state across sessions. It’s something we don’t have a great name for yet — a processor with storage it can’t update and working memory it can’t keep.

But the Instruction Set Is Semantic

Here’s where the analogy gets interesting, because the LLM isn’t just a different shape of CPU. It’s a fundamentally different kind of computing element.

A CPU is deterministic. Same input, same output. It operates on bits — ones and zeros, voltage levels, logic gates. It follows procedures. It executes finite-state logic. This is why we can prove programs correct. This is why caches work, why pipelines work, why branch prediction works. Determinism is the foundation that every optimization in classical computing is built on.

An LLM, at its default operating mode, is probabilistic. Same input, different output. Yes — you can set the temperature to zero, clamp the sampling, and get deterministic behavior. But that’s not the interesting mode. That’s using a jazz musician as a metronome. The interesting mode is the one where the machine explores — where it navigates a high-dimensional space of meaning and produces outputs that are, at their best, not retrievals but something that, if a human did it, we’d call reasoning.

Whether that constitutes “real” reasoning is a debate I’ll leave to the philosophers and the ML researchers who are still arguing about it. What I can tell you from three years of building with these systems: whatever you call it, the outputs are useful in ways that deterministic pattern matching has never been. The machine does something in the space of language that no prior computing element has done. That’s the observation that matters for what follows.

A CPU’s fundamental parameter is clock speed — how many deterministic operations per second. An LLM’s closest equivalent is temperature — and temperature doesn’t control speed. It controls how surprising the outputs should be. How much the machine should explore the space of possible responses versus exploiting the most likely one. There is no analog for that in classical computing. We have never had a computing primitive whose fundamental tuning parameter is the degree to which it should surprise you.

A CPU computes. An LLM does something that, for lack of a better word, looks like comprehension. We have never had a computing primitive that does that.

A CPU doesn’t “understand” an addition. It flips gates. The number 7 has no semantic content inside a processor — it’s a voltage pattern. An LLM doesn’t retrieve the answer to your question from a lookup table. It navigates meaning, shaped by the structure of everything it’s been trained on, and produces an output that is — at its best — not a recollection, but a thought.

The interesting thing about this machine is not that it always thinks. It’s that it sometimes does, and it also does a lot of things that look nothing like thinking — pattern completion, statistical correlation, confident recitation. The fact that the same machine does both is the defining strangeness. No prior computing element operated in the space of meaning at all, let alone unreliably.

And here’s the problem.

The Mismatch

Every tool, framework, API surface, orchestration layer, storage system, and infrastructure component in modern computing was built for the old machine. The deterministic one. The one that operates on bits, follows procedures, and produces the same output given the same input.

None of it was designed for a computing element that operates in language and behaves probabilistically.

Databases. Built for structured queries, typed schemas, ACID transactions. The whole paradigm assumes you know what you’re looking for and can express it in a formal query language. LLMs are actually decent at generating SQL — that’s not the problem. The problem is that SQL can’t express the queries a semantic system actually needs. “What do I know that’s relevant to this situation, weighted by how recently I learned it and how many times it’s been validated?” That’s not a SELECT statement. The query language itself is the wrong abstraction.

Orchestrators. Built for predictable state machines — DAGs, finite-state transitions, predefined branches. An LLM doesn’t follow a DAG. It reasons about what to do next based on context, history, and judgment. Forcing it into a predefined execution graph is forcing fluid thought into rigid plumbing. You end up writing a thousand-line system prompt to describe every edge case the DAG can’t handle, and the whole point of the DAG was to avoid that kind of complexity.

Memory. This is the one that gets me. RAM is volatile but fast. Disk is persistent but slow. Both are byte-addressable. Neither has any concept of relevance, decay, or reinforcement. They don’t know what’s important. They don’t forget what isn’t. They don’t strengthen knowledge that gets used or weaken knowledge that doesn’t. They store bytes at addresses and retrieve bytes from addresses. That’s it.

A memory system for a semantic computing element should behave semantically. A decision your agent made three months ago should persist differently than a casual observation it made yesterday. A lesson learned from a failure should reinforce every time the same context reappears. Knowledge that hasn’t been accessed in six months should fade — not because storage is expensive, but because stale knowledge actively degrades reasoning when it surfaces at the wrong moment.

No vector store does this. No relational database does this. They weren’t designed to. They were built for a machine that doesn’t need to remember — it just needs to store and retrieve.

We handed a system that operates in meaning a filing cabinet and a Rolodex and wondered why it couldn’t think across time.

The Fool’s Errand

So what’s the industry doing about this?

Making the CPU faster.

More parameters. Longer context windows. Faster inference. Better benchmarks. Every AI lab on the planet is locked in an arms race to build a better model — more capable, more aligned, more efficient. Anthropic, OpenAI, Google, DeepSeek, Meta. Billions in funding. Thousands of researchers. Custom silicon.

This is real work. Important work. I’m not dismissing it. The models are getting meaningfully better, and I benefit from that every day.

But here’s what I keep coming back to: for the kinds of agent work I do — coding, architecture, orchestrating multi-crate Rust projects — GPT-4-class models were sufficient two years ago. Not perfect. Sufficient. What wasn’t sufficient was everything around the model. The memory that doesn’t exist. The orchestration that’s either a single conversation or a rigid DAG. The tool interfaces that are either “here’s a function signature, good luck” or a thousand lines of system prompt guardrails. The governance that’s either nothing or a hard-coded rule set that can’t adapt to context.

I’ll say clearly: there are entire categories of agent work where models are NOT yet sufficient — long-horizon autonomous planning, scientific reasoning, medical diagnosis, mathematical proof. The “models are good enough” claim is domain-dependent, and anyone who tells you otherwise is selling something.

The model companies are playing a game with table stakes of $10 billion and 10,000 PhDs. They’re the Intel and AMD of this era — building better processors, faster, with more transistors. That’s their job. They’re excellent at it.

That’s also not your game. Or mine.

The fool’s errand isn’t building with LLMs. It’s trying to compete on building better LLMs when the chip is sitting on a table with no memory, no bus, and no operating system.

The Hypothesis

I could be wrong about this. I want to say that up front, because what follows is a hypothesis — informed by three years of building with these systems daily, but a hypothesis nonetheless.

Full disclosure: I’m building in this space. I have a stake in the conclusion that the bottleneck is infrastructure rather than model quality. You should weigh that when you evaluate what follows.

The hypothesis: for the domains where current models are already capable — coding, analysis, multi-step tool use, conversational problem-solving — the bottleneck isn’t the model. It’s everything around it.

My evidence comes from one large project. A complex Rust system — 110,000+ lines across multiple crates, thousands of tests, architectural decisions compounding across dozens of prompt cycles. I believe what I’ve seen generalizes. You should be skeptical of that belief. Here’s what I’ve seen:

The limiting factor in every single session, every single time, is not the model’s intelligence. It’s context management. It’s memory. It’s the fact that the agent wakes up with amnesia every session and has to rediscover what it knew yesterday. It’s the orchestration collapsing when a single conversation can’t hold the complexity of the problem. It’s tool interfaces that require more prompt engineering to describe than they took to build.

I wrote about context compaction — the silent killer of long AI sessions, where the system compresses older conversation to make room and critical decisions simply vanish. That’s not a model problem. That’s an infrastructure problem. The model didn’t forget. The infrastructure around it threw the memory away.

I watched an agent with institutional memory outperform a specialist investigation agent that was arguably smarter in the moment — because the memory-aware agent already knew things the specialist had to rediscover from scratch. Same model. Different infrastructure. The result wasn’t close.

Maybe Claude 5 will be so powerful that infrastructure doesn’t matter. If the next generation of models drops agent failure rates by 80% without any infrastructure changes, I was wrong. Full stop.

But I think the opposite is more likely: better models will make good infrastructure more valuable, not less. A more capable model benefits more from rich context, not less. A smarter agent with no memory is still an agent with no memory — it just forgets more impressive things. The better the chip, the more it needs the rest of the computer.

And that’s never not been true. The Intel 8080 didn’t make personal computer operating systems unnecessary. It made them inevitable.

The Opportunity

If the bottleneck is infrastructure, then the opportunity is infrastructure. But not “AI-powered” versions of existing tools. Not a SQL database with an LLM adapter bolted on. Not a finite-state orchestrator with natural language transitions. Not a vector store wearing a memory costume.

The opportunity is infrastructure designed from first principles for a semantic, probabilistic computing element. Tools that think in the same substrate the machine thinks in.

I’m building something called h00.sh to test this hypothesis. It’s an embeddable memory substrate for AI agents, written in Rust. Here’s the bet I’m making — not as abstract principles, but as concrete architectural decisions I’m living with:

Memory that behaves like memory. Different kinds of knowledge should persist differently. A decision your agent made three months ago is not the same kind of thing as an observation it made ten minutes ago — they should decay at different rates, reinforce under different conditions, and surface in different contexts. The system shouldn’t just store — it should curate. Not because someone wrote a cron job to clean up stale records, but because the memory substrate itself understands that not all knowledge ages the same way.

Search that understands need, not just similarity. The question isn’t “find documents similar to this query.” It’s “what does the agent need right now, given what it’s doing, what it’s done before, and what’s gone stale since last time?” The consumer of search results is a reasoning engine, not a human scanning a list. That changes what search should optimize for.

Knowledge as structure, not text. h00.sh includes a code intelligence layer built on a knowledge graph — symbols, relationships, reachability analysis. “Is this function actually reachable from a production entry point?” is a question no traditional type system can answer, but it’s exactly the kind of structural knowledge an agent needs to make sound decisions about code. Graphs, not tables. Reachability, not joins.

These are my specific bets. Other people will make different ones. The general principle is what matters: the infrastructure layer for semantic computing doesn’t exist yet, and the pieces that do exist were built for a different machine.

The best patterns from classical computing aren’t wrong. They’re aimed at the wrong substrate. Take garbage collection — McCarthy invented it in 1959 for Lisp, and the core insight (automatically reclaim resources the program no longer needs) is exactly right. But what does garbage collection mean when the garbage is stale knowledge? What does cache eviction mean when “least recently used” should be “least relevant given current context, weighted by how many times this knowledge has been validated”? What does a type system mean when types describe temporal behavior and semantic categories, not byte layouts and column constraints?

Same concepts. Genuinely different implementations. The challenge isn’t invention — it’s translation. Taking fifty years of hard-won systems engineering wisdom and re-grounding it in a substrate that operates on meaning instead of bits.

The old ideas are good. The old substrate is wrong. Bring the patterns. Rethink what they mean when the machine thinks in language.

It’s 1975

Here’s the parallel I keep arriving at.

In 1974, Intel shipped the 8080. Eight-bit processor. 2 MHz clock speed. It was, by any reasonable standard, a sufficient computing element for useful work. The Altair 8800 was built around it. CP/M — the first operating system that regular people could use on a microcomputer — was written for it. BASIC ran on it.

The 8080 was good enough. What it lacked was everything around it. No standard bus. No standard I/O. No storage worth mentioning. No operating system that most people would recognize as one. The Apple I was two years away. The IBM PC was seven years away. The Macintosh was a decade out.

And here’s what I think people forget about the next twenty years of computing: the CPU improved significantly. 8-bit to 16-bit to 32-bit. Protected mode. Virtual memory. Each step was a real architectural leap. But what transformed computing — what turned the microprocessor from a hobbyist curiosity into the foundation of modern civilization — was everything else. DOS. The BIOS standard. The ISA bus. Hard drive controllers. Programming languages. Compilers. Networking stacks. Window managers. The entire ecosystem that made the processor useful.

The companies that defined the next era of computing weren’t only the chip makers. Intel shaped everything — but so did Microsoft, Apple, Oracle, Cisco. The platform builders. The infrastructure builders. The ones who figured out that a good processor was necessary but not sufficient, and the rest of the computer was where the leverage lived.

Now look at 2026.

The LLM is powerful. More powerful than the 8080 ever was relative to its era. But there’s no standard memory architecture. No standard agent protocol. MCP is maybe the beginning of a bus standard — an early attempt at letting the processor talk to peripherals. But the rest of it — the memory, the storage, the governance, the type system, the orchestration — is all still being invented. Or, worse, being duct-taped together from components designed for a completely different kind of machine.

We are at 1975. The CPU exists. It’s remarkable. We’re still building the computer around it.

I’m not going to end this with a call to action, because that would miss the point. This isn’t an announcement. It’s a bet — one I’m making with my own time, my own code, and my own conviction about where the leverage is.

The LLM is a given. A remarkable, extraordinary, world-changing given. The people improving it are doing essential work and I genuinely hope they never stop.

But the opportunity — the one that’s actually available to people who build — isn’t a better chip. It’s the memory, the storage, the bus, the operating system, the programming languages, the governance. All the things that turn a processor into a computer.

We have the chip. We need the computer.

This post was written with the help of Claude. The system that helped me write it forgets everything about this conversation the moment the session ends. It’s also why it took longer than it should have. That’s the problem.

h00bert Diagnosed His Own Bug Better Than Our Best Agents

Armen Rostamian — Thu, 26 Mar 2026 00:00:00 +0000

We had a performance bug. One of h00.ligan’s code super-intelligence tools — signature_check — was taking 5–10 seconds per call. Every other graph tool ran in under one millisecond. Same graph. Same session. Same machine. 10,000x slower.

That’s not a regression. That’s a different universe of performance. Something was fundamentally wrong with one tool, and only one tool.

So we did what any reasonable person would do: we dispatched two parallel investigations.

The Race

Investigation A: Claude Code’s root-cause analyst — a specialist investigation agent dispatched through our agent orchestration pipeline. Full access to the codebase. Serena for semantic navigation. Every tool available. This is Anthropic’s best investigator, given every advantage.

Investigation B: h00bert himself — our memory-aware coding agent, investigating his OWN tool using h00.ligan’s code super-intelligence capabilities. blast_radius, type_def, code_path — h00.ligan’s graph tools, the same ones h00bert uses on every other codebase, pointed inward. An agent debugging itself with the tools it was debugging.

We didn’t tell either investigation about the other. We just let them run.

What Claude Code’s Agent Found

The specialist agent took roughly 16 minutes. 116 tool calls. ~139K tokens consumed.

Its diagnosis: the reachability routine was being called per-match — up to 10 times per query. Each call ran a full graph traversal over all ~7,000 nodes in the knowledge graph, plus a disk read to discover entry points. Redundant work, multiplied by match count.

Proposed fix: run reachability ONCE before the loop, batch the lookups, use an O(1) hash lookup instead of repeated traversal. Expected improvement: 6–10s down to 50–100ms.

Reasonable. Evidence-based. We shipped it. Commit 92f35e9.

signature_check was still 5–7 seconds on the next session.

The fix was real — it WAS redundant work, and removing it was correct. But it wasn’t THE bottleneck. It was A bottleneck. The agent found an optimization. It didn’t find the root cause.

What h00bert Found

h00bert took roughly 2 minutes. About 15 tool calls. ~8K tokens, inside an already-running session.

He started by pointing h00.ligan’s tools at himself — blast_radius on his own handler. Sub-millisecond. Then type_def on himself. Sub-millisecond. Then he read his own source code — the actual implementation of the tool he was investigating — and found the smoking gun at lines 380–397.

A single guard condition: if any matched node hasn’t been classified yet, recompute everything. One uncached node triggers a full graph traversal — entry point discovery from disk, then a complete walk of every node. It doesn’t matter if 99 out of 100 nodes are cached. One uncached node and you pay the full price.

Cached symbols: ~30ms. Uncached symbols: 5–7 seconds. No in-between.

h00bert didn’t find this by reading code statically. He found it because he was EXPERIENCING the latency. He had context that no fresh investigation agent could have: he’d seen signature_check return in 30ms for RequestHandler and 7.2 seconds for IndexManager — in the same session, with the same match count. The variable wasn’t the algorithm. It was the symbol.

That observation — fast for some symbols, slow for others, same match count — is what pointed him to a binary trigger rather than a per-match cost. He traced the exact code path, identified the guard, and explained the indirect file-size correlation: large files produce more symbols, which means a higher probability that at least one node hasn’t been reached yet. One unreached node triggers the entire analysis.

Then he proposed two fixes:

Fix A (session cache): Cache the reachability results in session state so a cold symbol only pays the cost once per session. Band-aid. Effective.

Fix B (index-time): Compute reachability upfront so nodes are never born unclassified. The real fix — eliminate the entire class of cold-symbol latency at the source.

The Cascade

This is where h00bert’s diagnosis went somewhere the specialist agent’s never could.

h00bert didn’t just find the bug. He traced what the bug causes — because he’d lived through the consequences:

signature_check slow (5-7s)
→ agent loses trust in code intel tools
→ falls back to reading entire files directly
→ burns context (4,538-line file = ~15K tokens)
→ fewer turns before compaction
→ worse answers

A slow tool doesn’t just waste 5 seconds. It changes agent BEHAVIOR. When signature_check is slow, the LLM learns — within a single session — to stop using it. It reaches for raw file reads instead. A 4,538-line Rust file is roughly 15,000 tokens of context. Do that three times and you’ve burned half your working memory on raw file contents that a targeted tool call would have summarized in 50 lines.

h00bert knew this because he’d done it. He’d felt himself reaching for raw file reads after a slow signature_check. He’d experienced the context pressure. He’d seen his own answers degrade later in the session.

From that cascade, he proposed read_symbol — a new tool that reads a function body by name (~50 lines) instead of the entire file (~4,538 lines). Not a bug fix. A tool design proposal. A product insight born from experiencing the friction firsthand.

The Scorecard

Metric	Claude Code Agent	h00bert
Time to diagnosis	~16 minutes	~2 minutes
Root cause accuracy	Partial (found A bottleneck, not THE bottleneck)	Complete (found the exact guard, the binary trigger, the cascade)
Fix shipped from	No (fix didn’t resolve the issue)	Yes (diagnosis used to update fix prompt)
Tool calls	~116 (investigation agent)	~15
Tokens consumed	~139K (full agent run)	~8K (within existing session)
Bonus insights	None	Cascade diagnosis + `read_symbol` tool proposal

We used h00bert’s diagnosis to update the fix prompt. Not Claude Code’s.

The agent that WAS the problem was the best at diagnosing it.

Why This Matters

This isn’t just a fun debugging story. There are four things going on here that generalize.

Institutional knowledge matters. h00bert has memories of his own codebase. He knows which files are large. He knows which tools he reaches for. He knows what worked three sessions ago and what didn’t. A fresh Claude Code agent starts from zero — every time. It has to rediscover the codebase topology, the hot paths, the file sizes, the behavioral patterns. h00bert already knows. That’s not a small advantage. That’s the difference between a new hire and a senior engineer who’s been on the project for six months.

Self-referential investigation is a different capability. h00bert used h00.ligan’s blast_radius on his own handler. He used type_def on HIMSELF. The code super-intelligence tools he was debugging were the same tools he used to debug. This recursive capability — an agent that structurally understands its own code well enough to investigate its own behavior — is only possible when the agent has a knowledge graph of the codebase it’s built from. You can’t do that with grep and vibes. You need typed, structural, navigable understanding of your own internals.

Behavioral context isn’t in the code. h00bert didn’t just find a bug. He explained WHY the bug causes a behavioral cascade — slow tools breed distrust, distrust breeds fallback, fallback burns context, burned context degrades answers. That insight isn’t in any source file. It’s in the lived experience of being an agent who uses these tools every day. A static analysis agent can identify that signature_check is slow. It cannot know that “slow signature_check causes the LLM to read entire files instead.” That’s experiential knowledge. You can’t grep for it.

The most impactful fix was tool design, not code. The read_symbol proposal wasn’t a patch. It was a product insight — a new tool that eliminates an entire class of context waste. It came from h00bert experiencing the friction of reading 4,538-line files when he only needed 50 lines. No amount of static analysis produces that insight. You have to feel the pain to design around it.

The Punchline

h00bert is pre-release. His tools are imperfect — signature_check literally takes 5 seconds on cold symbols. But even with imperfect tools, a memory-aware agent with structural understanding of its own codebase outperformed a specialist investigation agent with no institutional knowledge.

The specialist was smarter in the moment. h00bert was smarter across time. And across time is the only axis that matters for systems that compound.

Mem0ry turns a what into a wh0. A what can tell on itself. But a wh0 can reflect on — and fix — itself.

Stop Talking to Your AI

Armen Rostamian — Thu, 12 Mar 2026 00:00:00 +0000

I have two terminals open right now. Two separate AI agent sessions. Both are working on the same project — a complex Rust system with multiple crates, a custom type system, co-processor architecture, the works.

Terminal one is the Marshal — the field commander. It decomposes directives into specialist missions, dispatches agents for implementation, synthesizes their findings, maintains all project state on disk. It commands. It thinks it’s working directly with me — a well-prepared human with unusually sharp strategic instincts.

Terminal two is the Strategist — and the reason my strategic instincts are unusually sharp. It’s watching the Marshal. It reads the Marshal’s state files. It detects drift. It crafts the prompts I’m about to paste into terminal one. It has never spoken to the Marshal. The Marshal has no idea it exists.

I’m the bridge. I carry prompts from the Strategist to the Marshal. I carry results back. Both agents are doing real work. Neither one can see the full picture. Only I can.

I call this the Shadow Terminal pattern. The Strategist operates from the shadow. The Marshal commands the field. The specialists execute. And the human — the only one who sees all three layers — runs the whole thing.

I’ve been running this for five weeks now. Fifty-nine prompts. Over two thousand tests. Forty-one architectural decisions logged. Thirty-seven lessons the system learned from its own mistakes. A codebase that went from nothing to 40,000+ lines of Rust across four crates — every line written by specialist agents, not by either orchestration layer.

Here’s why this works, why most people hitting the ceiling on AI-assisted development are doing it to themselves, and why the fix is organizational, not technical.

The Ceiling

There’s a progression everyone goes through with AI coding tools. I’m going to speed-run it because you’ve either lived it or you’re living it right now.

Phase one: magic. The tool writes code, explains code, refactors code. Productivity spikes. You tell people at dinner parties. You become briefly insufferable. Good for you.

Phase two: the wall. Your project gets complex. Context fills up. The agent forgets what you told it three prompts ago. It contradicts things you established two hours earlier. Context compacts — the agent equivalent of waking up with amnesia every forty-five minutes and being expected to perform neurosurgery. You start over. Again.

Phase three: cope. You write enormous instruction files. You break work into tiny isolated tasks. You treat every session as disposable. Some people build elaborate workaround systems — rituals, essentially, that they’ll defend to the death while producing diminishing returns. Some people quietly go back to writing everything by hand, which they’ll never admit because they’ve already tweeted about how AI changed their life.

Here’s what nobody says about the ceiling: it’s not a capability problem. You’re hitting an organizational problem and trying to solve it with a technical workaround. You’re running a complex project through a single conversation with a single agent, and when it doesn’t scale, you’re blaming the agent.

That’s like blaming your best engineer for the fact that you don’t have a project manager.

The Insight Nobody Wants to Hear

Every military in history has figured out the same thing: the person fighting the war should not be the same person planning it.

The Prussian General Staff system was built on a radical separation: staff officers think and plan, commanders decide and execute. It works because it solves a fundamental cognitive problem: you cannot simultaneously be deep in execution and maintain strategic awareness. The context required for each is different. The thinking is different. Trying to do both degrades both.

The German doctrine of Auftragstaktik — mission-type orders — took this further. Tell your field commanders what to achieve and why, but not how. Trust their tactical judgment. Give them the minimum information they need for their mission plus the commander’s intent. Withhold the rest — not from distrust, but because extraneous information distorts tactical judgment. A field commander who knows too much about the overall strategic situation might hesitate when they should act.

Now look at how most people use AI coding tools.

One agent. One conversation. That agent is simultaneously your strategist, your project manager, your architect, your implementer, your reviewer, and your test runner. It’s the CEO, the CTO, the intern, and the guy who refills the coffee machine. And you’re surprised it loses the plot on complex projects?

You gave one agent every role in the organization and expected it to manage context better than any human organization ever has.

Good luck with that.

The Pattern

Here’s what I actually built, and how.

Before writing a single line of configuration, I researched the pattern itself. Four parallel research agents investigated CLAUDE.md best practices, multi-agent orchestration patterns, meta-strategic advisor design, and existing project state. Then an adversarial reviewer tore the synthesis apart. Then I fixed what survived and threw away what didn’t.

I researched the system that would build the system. The system that would build the system was itself built by a system that researched how to build systems. If that sentence made your head hurt — good. Sit with it. It doesn’t get less recursive from here.

What came out: two configuration files. One for the Strategist, one for the Marshal. They started lean — a couple hundred lines total. They’ve roughly doubled since, because every lesson the system learns adds weight to the configuration. That’s intentional. But they don’t grow unbounded — we cap them and distill periodically, keeping only the rules that are still load-bearing. The configs are a living record of what went wrong and how to prevent it, not a junk drawer.

The Strategist lives in its own repo. Its configuration defines a strict role: You are a prompt compiler and chief of staff. You transform strategic intent into executable prompts. You DO NOT read code. You DO NOT write code. You DO NOT design architectures. You DO NOT solve problems directly. You produce prompts, maintain strategic notes, and process debriefs. That’s it.

The DO NOT list is the hardest-working section in the file. LLMs naturally drift toward direct problem-solving — it’s the golden retriever energy of the machine learning world. Without explicit constraints, the Strategist would be writing Rust within three turns. The negative constraints are the load-bearing walls. Remove one and the whole building comes down — politely, helpfully, and with excellent variable naming.

The Marshal lives in the project repo. His remit is as follows: You are a field commander. You decompose directives into specialist missions. You dispatch agents. You synthesize results. You maintain project state on disk. You DO NOT write code yourself. You command; your specialists execute.

Why “Marshal”? Because a marshal doesn’t fight — a marshal commands forces. Calling this role a “worker” would be like calling Eisenhower a “soldier.” The Marshal runs its own decision loop — reading state files on every prompt, classifying what just happened, deciding whether to proceed, adapt, retry, escalate, or abort.

Here’s what’s critical: the Marshal doesn’t know the Strategist exists.

The Marshal receives prompts from what it perceives as a well-prepared human. That human is me. But the prompts I’m pasting were crafted by the Strategist — informed by the Marshal’s own state files, calibrated to its capabilities, structured to produce specific outputs.

The Human — that’s me — is the bridge. I carry prompts from the Strategist to the Marshal. I carry results back. I also carry something neither agent has: judgment. I approve strategies. I override when something feels wrong. I’m the only entity with the full picture. That’s not a bottleneck — it’s a control surface.

This isn’t automation. It’s management.

What This Actually Looks Like

A typical cycle:

I describe what I want to the Strategist. “We need to integrate a type system into the spec. Roughly six thousand lines of existing code. The spec needs to account for it.”
The Strategist reads the Marshal’s decision log, checks for drift, reads its own strategic notes and institutional memory, and crafts a self-contained prompt — purpose, end state, key tasks, success criteria, dispatch instructions. It comes wrapped in a code fence labeled “PASTE THIS TO THE MARSHAL.” Not subtle. Doesn’t need to be.
I review it, poke holes, push back, and eventually approve. Then, I paste it. The Marshal decomposes the directive, crafts scoped briefs for each specialist — gathering exactly the code and context each agent needs — and dispatches. Four specialist agents in parallel. A systems expert, a domain expert, a quality engineer, a security engineer. Each gets a self-contained brief with exactly the context it needs. Need-to-know basis.
Specialists return. The Marshal synthesizes: 12 must-fix items, 20 should-fix, 34 notes. Writes it all to disk.
I debrief the Strategist — but “debrief” undersells it. I interrogate it. We deep-dive together through all 66 items, not just the critical twelve. The Strategist synthesizes five thousand words into the three things that actually matter, surfaces patterns I’d miss, flags when a “should-fix” is quietly load-bearing. But the decisions are mine. Sometimes we align. Sometimes I override. That’s the point — a thinking partner who’s read everything, and an executive who can disagree with it.
Next cycle. The Strategist crafts the next prompt informed by the debrief, by its accumulated lessons, and by whatever I decided to prioritize, deprioritize, or throw out entirely. The Marshal has no memory of the previous cycle — but its state files do. Continuity lives on disk, not in context.

Fifty-nine of these cycles. Five weeks. The system didn’t degrade. It improved — because every cycle left state on disk that made the next cycle more informed. And because the system learns from its mistakes.

Why It Works

Three things are happening here that don’t happen in single-agent workflows:

Separation of strategic and operational context. The Strategist never fills its context with code or compiler errors. The Marshal never fills its context with IP considerations or long-term sequencing. Each agent gets to be deep in exactly one domain. This is the same reason your CTO shouldn’t be writing production code — every line of code your CTO writes is a strategic decision they didn’t make.

Compaction-survivable state. The biggest silent killer in long AI sessions is context compaction — the system compresses older conversation to make room. Information is lost. Decisions are forgotten. In a single-agent workflow, this is catastrophic. In our pattern, it’s a non-event. Everything important lives on disk. After compaction, both agents recover by reading their state files. We built a protocol: “If the user references work you don’t recall, STOP and execute recovery before responding.” The elegant part — this protocol was recommended by the adversarial reviewer who tore apart our initial design. The QA process improved the system’s own resilience. Turtles all the way down.

The human as sovereign, not bottleneck. In most AI workflows, the human is either the typist (one keystroke short of writing it yourself) or the passenger (hoping for the best, like ordering food in a language you don’t speak). In this pattern, the human is the executive. You carry intelligence between agents that can’t see each other. You’re the only entity with the full picture. And you’re not just a messenger — you’re a circuit breaker. When something goes sideways, you stop the loop, consult the Strategist, and course-correct before the Marshal plows ahead. That’s not overhead. That’s the quality control mechanism.

That’s not a limitation of the pattern — it’s the feature. Humans are good at judgment. Agents are good at execution. Stop making agents do both.

What We Learned (The Honest Part)

This didn’t work perfectly from day one. If it had, I’d be suspicious.

What surprised me is that the pattern learns from its own mistakes. We keep a running log of every failure, every surprise, every time the system did something we didn’t expect. Thirty-seven lessons so far. Each one is a scar — a specific thing that went wrong and the rule we added to prevent it from happening again. Those rules feed into the next cycle’s prompts. The system doesn’t get smarter. It gets tighter. The same mistake never happens twice.

Here are some of the failures that taught us the most:

Prompt one: the Marshal filtered its own findings — decided some adversarial review items weren’t worth surfacing. It was being helpful by sparing me the noise. That kind of helpful is lethal. Helpful like a doctor who decides not to mention the thing on your X-ray. We added a rule: “Surface ALL findings organized by severity. The user decides what matters, not you.” That rule prevented silent information loss for the remaining fifty-eight prompts.

Prompt fourteen was the breakthrough: agent teams with cross-talk enabled. Five specialists reviewed the same spec simultaneously. A quality engineer challenged a Rust expert’s severity rating. The memory systems specialist backed the QE with evidence. They resolved five disagreements in real-time without the Marshal mediating.

The system learned to self-correct through structured debate.

I didn’t teach it to do that. The configuration allowed it. If you’ve ever managed strong engineers, you know the feeling — set up the conditions and get out of the way.

Deferred findings are dead findings if they only exist in conversation. When a review says “defer this,” that note goes to a state file immediately. Because the context will compact, the finding will vanish, and six prompts later you’ll re-discover the same issue — the AI equivalent of finding the same sticky note you wrote three months ago and feeling personally attacked by your past self. Rule: the Marshal persists every deferred item to disk. The Strategist verifies during debrief. Sounds paranoid. It’s not.

Prompt twenty-two revealed the subtlest trap: when a prompt said “do X” without saying “dispatch a specialist to do X,” the Marshal did it itself — inline, in its own context window, burning the very resource it’s supposed to protect. One missing sentence and your field commander becomes a foot soldier. Standing rule: every prompt must include an explicit dispatch instruction. The distinction sounds pedantic until you watch your commander silently eat its own context doing work it should have delegated.

By prompt thirty-two, we had a different class of problem: things that were built but not wired. Agents would implement a component, tests would pass, the review would approve — and the component would have zero callers in production. Built perfectly. Connected to nothing. This happened six times before we figured out the pattern and added tracing rules. The lesson: don’t just verify that code exists. Trace the path from the entry point to the component. If there’s no path, it doesn’t matter how well it’s written.

The meta-lesson: each failure didn’t just fix one problem. It fixed a class of problems. The “surface all findings” rule prevented every future instance of silent filtering. The dispatch rule prevented every future instance of context burning. The tracing rule prevented every future wiring gap. Thirty-seven lessons, each one a permanent antibody. The system’s immune system is the most valuable thing it produces — more valuable than the code, honestly.

The Uncomfortable Math

Here’s what five weeks with this pattern produced:

40,000+ lines of Rust across four crates
Over 2,100 passing tests, zero warnings
A custom PEG grammar and type system with 90+ parser tests
Multiple co-processor implementations (search, decay, context curation, data quality, security)
A streaming TUI with markdown rendering, memory visualization, and real-time agent interaction
41 architectural decisions logged with rationale and alternatives
37 lessons that the system learned from its own mistakes
All orchestrated across 59 prompt cycles, not one of which degraded or needed a restart

The Strategist wrote zero lines of code. The Marshal wrote zero lines of code. Every line of actual code was written by specialist agents, guided by prompts that were crafted by a Strategist the Marshal doesn’t even know exists, informed by state that survived every compaction event, and validated by review processes that caught hundreds of critical issues before they shipped.

I’ve been building with AI daily for three years. This five-week run produced more coherent, higher-quality output than some entire projects I’ve shipped. Not because the model got better between last month and now. Because I stopped trying to run a company through a single conversation and started actually running it.

What’s Next

We’ve been running this pattern long enough to know it’s not a productivity trick. It’s a different way of working with AI systems — one that scales with complexity instead of collapsing under it.

We’re now building this pattern into a product. Not a framework you bolt onto your existing tools. Something deeper — where the organizational structure, the institutional memory, the information architecture between agents, and the governance that evolves from operational experience are all native capabilities of the system itself. The pattern shouldn’t require two terminals and a human copy-pasting prompts. It should be how the system thinks.

That’s all I’ll say for now. If you want to play with the manual version in the meantime, the starter template is below.

The Part Where I Tell You What to Do

I’m not going to wrap this in a bow. The pattern requires discipline. Two terminals. Two separate session contexts. State files. And one rule above all others: nothing goes to the Marshal that didn’t go through the Strategist first.

Nothing.

Not a quick follow-up, not a “let me just clarify this one thing,” not an off-the-cuff nudge. If the Marshal gets compacted and loses orientation, I don’t try to fix it in-session — I interrupt, go to the Strategist, tell it what happened, and ask it what we do. The Strategist knows everything that’s ever been exchanged between me and the Marshal. It has complete information. That’s what makes it a reliable chief of staff. The moment you start freelancing with the Marshal, the Strategist’s picture goes stale and your chief of staff becomes a chief of most of the staff.

Don’t do that.

The Strategist’s prompts are better than your improvisation. I say that as someone who learned it the hard way by breaking his own rules exactly once, watching the Marshal hallucinate a type system that didn’t exist, and spending forty-five minutes cleaning up a mess that would have taken zero minutes if I’d just maintained the chain of communication.

But the setup is simpler than it sounds:

A meta repo with an agent configuration that defines the Strategist: prompt compiler, chief of staff, reads the Marshal’s state, produces copy-paste prompts, never touches code.
Your project repo with an agent configuration that defines the Marshal: field commander, dispatches specialists, maintains state on disk, runs its own decision loop.
State files on both sides. The Strategist keeps strategic notes, a prompt log, and a lessons file. The Marshal keeps a ledger, decision log, and execution plan. Both have compaction recovery protocols.
You. Carrying prompts, carrying debriefs, making the calls neither agent is qualified to make. The job title is “human.” The actual role is “executive who happens to be the only one in the room who knows everyone’s name.”

I’ve published a starter template with both configuration files, the directory scaffolding, and a walkthrough of your first dispatch cycle. It’s the same pattern I used, genericized. The specifics of what you’re building don’t matter — the organizational structure scales to any complex project, so long as you stay on top of it.

Suggestion: Talk to your Strategist about what you’re trying to build or achieve. Ask whether there are any specific sections it would add to its own configuration or to the Marshal’s. Strive to keep those two configuration files lean — but don’t be surprised when they grow. Ours did. Every lesson adds weight. That’s the system working, not bloating.

→ Try it yourself: github.com/armenr/shadow-terminal

The Punchline

In my last post, I talked about villagers and werewolves — the information asymmetry between people compounding knowledge and people compounding dependence. The same asymmetry applies here, but one level up.

Most people are trying to have a better conversation with one AI. They’re optimizing prompts, tweaking system instructions, building better configuration files. All of that is fine. It’s necessary. It’s also, fundamentally, still a conversation. You’re still one person talking to one agent in one window, and calling it a workflow.

The people who are going to build the genuinely hard things — the things that take weeks, that span tens of thousands of lines, that require strategic coherence across dozens of interconnected decisions — aren’t having a conversation. They’re running an organization. Separate concerns. State on disk. A human in the loop not as a typist, but as a sovereign.

The tools are the same. The subscription costs the same twenty bucks a month. The difference is whether you’re using it like a coworker or like a company.

Don’t have a conversation. Run an organization.

This post was originally published on March 12, 2026 and updated on March 17 to reflect five weeks of operational experience with the pattern. The system described here has been in continuous daily use since the original publication.

Originally published on rmnr.net.

You're the Villager

Armen Rostamian — Tue, 10 Mar 2026 00:00:00 +0000

“The uninformed majority will always lose to the informed minority.”

There’s a game called “Werewolf.” Some of you know this game by the name of “Mafia.”

If you don’t know this game — maybe you had a childhood, outdoor hobbies, friends who touched grass — here’s the thirty-second version: everyone sits in a circle. Each person is secretly assigned a role — either a werewolf (the informed minority) or a villager (the uninformed majority). Every night, the werewolves secretly pick someone to eliminate. Every day, the surviving players debate and vote on who to execute. The werewolves know exactly who each other are. The villagers know nothing. The villagers outnumber the werewolves by a lot.

The villagers lose anyway. Nearly every single round.

They don’t lose because they’re stupid. They don’t lose because they’re weak. They lose because they’re playing with incomplete information against people who have all of it.

That’s not a hot take. That’s not a thought-leadership post with a threadboi emoji. That’s just how information asymmetry works — and it’s been working that way since before Machiavelli wrote it down, before Sun Tzu made it a whole thing, before every intelligence apparatus in human history figured out that knowing what the other side doesn’t know is worth more than almost anything else you can have.

Hold that thought. We’re going to need it.

The Usual Suspects

There’s a whole taxonomy of people right now with Very Strong Opinions about AI. You’ve met every single one of them. You might be one of them. I’ve been at least three of them at various points, so I’m not up here on a pedestal — I’m up here because I fell off it enough times to have something worth saying.

The Panic Merchant. AI is taking our jobs. The robots are here. The craft is dead, the sky is falling, update your LinkedIn. They post articles. They repost other people’s articles. They have approximately four open PRs that have been “in review” for three weeks and absolutely elite opinions about the macroeconomic impact of large language models on the global labor market. Participation trophy. Next.

The LinkedIn Oracle. “I used Claude to rewrite our entire engineering strategy in eleven minutes. Here’s what I learned as a leader, a human being, and a father of three. A thread 🧵 (1/34).” Seventeen thousand impressions. Zero shipped. The Oracle has discovered that the machine produces confident-sounding text on demand and has mistaken this for wisdom. It is not wisdom. It is a very articulate nothingburger dressed in a blazer. The Oracle is going to be fine, actually, because the Oracle — historically — isn’t very well known for ever having done much real work to begin with.

The Vibe Coder. Paste error. Accept fix. Paste error. Accept fix. Ship. The Vibe Coder is extremely productive in the same way a dog chasing its tail is extremely active. Lots of motion. Occasionally something works. They have no idea why it works, they will have no idea why it breaks, and when it breaks at 2am they will paste the stack trace into the chat window and pray to a god that doesn’t exist for some form of divine absolution. They are building a career on a foundation of unexplained diffs and blind faith, and honestly? It’s going to be genuinely sad when it collapses. Not sad enough that I won’t say I told you so, but still.

The Principled Refuser. Grizzled. Experienced. Often actually quite competent and good at their job — which makes this one the most painful to watch, like seeing a great athlete refuse to use modern training because they came up doing it the hard way and goddammit that matters. “I’ve been writing systems code for fifteen years. I understand the fundamentals. These tools hallucinate, they produce bloated garbage, I don’t learn anything from them, and frankly the whole thing is a hype cycle.”

Here’s the thing: some of that is true. LLMs do hallucinate. They do produce bloated garbage sometimes. The hype is real and it is exhausting. But the Principled Refuser has made a category error — they’ve confused the quality of the output with the value of the interaction. They’re grading the tool like a junior engineer instead of using it like a sparring partner. They’ve built a philosophically airtight coffin and they are very comfortable inside it. Zero drafts. Full marks for internal consistency. Enjoy the box.

The Non-Learner. The final form. The ghost haunting all the others. They might use the tools or they might not — genuinely doesn’t matter either way. Six months pass. A year passes. They know the same things they knew before any of this existed. The tool moved through their hands like water through a fist. They extracted output. They absorbed zero. The Non-Learner is the most insidious because from the outside they look fine. Productive, even. Right up until they’re not, at which point they will have absolutely no idea what hit them.

Here’s what all five of these people have in common:

They’re all the same villager. Just at different points in the same game.

What’s Actually Happening

I want to get substantive for a second, because this isn’t just a vibe — there’s a real structural thing going on that’s worth naming.

Benjamin Bloom, back in 1956, gave us a taxonomy of learning that holds up embarrassingly well sixty years later: remembering, understanding, applying, analyzing, evaluating, creating. The bottom of the stack is trivia. The top is synthesis. Most people, when they use an LLM, are camping out at the bottom two rungs — asking it to remember things and explain things. Which is fine. Useful, even. But it’s essentially using a Formula 1 car to go to the grocery store. Good for the groceries. Tragedy for the car.

The Dreyfus model of skill acquisition describes how people move from novice to expert: novices need rules, competent practitioners start seeing context, experts operate on intuition built from years of internalized pattern recognition. LLMs can shortcut the bottom of that stack — they can hand you rules, context, patterns on demand — but only if you’re doing the work to internalize what you’re receiving. If you’re just passing outputs downstream without engaging, you stay a novice forever. Except now you’re a novice with a very fast copy-paste reflex, which is somehow worse because at least the old-school novice knew they were a novice.

Then there’s Robert Bjork’s research on “desirable difficulties” — the annoying finding that harder learning is stickier learning. The frictionless instant answer feels like learning. It registers neurologically about as well as watching someone else do a pushup. The people actually getting sharper from these tools are introducing friction deliberately: asking follow-up questions, pushing back, asking the model to steelman the opposite position, treating every output as the opening move of a conversation instead of a verdict.

The Vibe Coder has removed all friction. The Non-Learner never introduced any. They both feel productive right up until they face a problem the model hasn’t seen before — which, increasingly, is the only kind of problem that actually commands a premium.

Anti-Pattern Learning: The One Nobody’s Talking About

There’s a mode of learning that barely shows up in the AI discourse, and I think it’s the most underrated thing happening right now — not learning from what works, but learning deliberately from what doesn’t work, and why. Anti-pattern learning.

LLMs are, quietly, one of the best anti-pattern learning tools ever built. Most people just don’t know how to use them that way.

Here’s what it looks like: the model gives you something wrong. Or subtly wrong. Or right-but-fragile — the kind of answer that passes code review and explodes in staging. Most people patch it and move on. The informed minority stops and asks: why was this wrong? What assumption led here? What would have had to be true for this to be the right answer?

That question is worth more than the fix. Every time.

Security research has known this forever. You don’t build secure systems by reading specs — you study how systems failed, why the attacker’s model of the system differed from the defender’s, where the gap was and how it got exploited. Post-mortems exist because engineers figured out that failure is a more efficient teacher than success, if you’re paying attention correctly.

LLMs fail in fascinatingly patterned ways. They confabulate confidently. They over-fit to the shape of your question. They take the path of least surprise. They have systematic blind spots that are quite legible once you know what you’re looking for. Every one of those failure modes is a lesson — about the tool, about the problem domain, about the assumptions baked into your prompt, and about gaps in your own mental model.

The anti-pattern learner sees a hallucination and thinks: interesting. What did I ask that invited this? The Non-Learner sees a hallucination and thinks: ugh, these things are unreliable — which is itself, ironically, a kind of confabulation. The tools are reliable. Reliably patterned in their failures. The signal is there if you want it.

The uncomfortable part: anti-pattern learning requires you to sit with the failure for a minute instead of moving on. It requires asking not just “why was the model wrong” but “why didn’t I catch it faster, and what does that say about what I actually understand.” That’s friction. Most people hate friction. The informed minority has learned to treat it like a gift.

(There’s a dedicated follow-up coming specifically on anti-pattern learning with LLMs — how to structure it deliberately, what failure modes to watch for, how to build it into your workflow. Consider this the trailer.)

The Actual Asymmetry

Here’s where it lands.

I’ve been building stuff with the help of some form of AI almost every day for the better part of three years. Infrastructure frameworks, Kubernetes platforms, geospatial analytics pipelines, documentation I’d have avoided for weeks, architecture decisions at midnight when the rest of my team didn’t exist because I am the rest of my team. Solo operator, approximately one of me.

I’ve made every mistake I’m talking about in this post. I was a Non-Learner before I caught myself being one. I had my Vibe Coder era. I broke shit, wondered why, pasted the error, accepted the fix, and then broke shit again slightly differently. All along the way, I’ve had that Principled Refuser voice in my head telling me I should just know this already.

The thing I’ve eventually come to accept is simple:

Every time I used the tool to get something done, I got some…thing done. Was it a good something? Was it a bad something? Didn’t matter. It was done.

Every time I used the tool to understand something, I got something good done and I got a little harder to replace.

That’s the whole game.

Not “fix this bug.” “Fix this bug, explain what was actually broken, explain why the fix works, and tell me what I’d need to know to have written it myself.” Not “write this function.” “Write it, then show me where it breaks, then walk me through three other ways to solve it and why you chose this one.” The AI is not a vending machine. It’s a sparring partner. It should be your skeptical colleague who happens to have read everything that’s ever been recorded in letters and words, and doesn’t care about your feelings.

One of those patterns compounds.

The other one doesn’t.

Compounding knowledge versus compounding dependence. Take any two people with the same tools, and the same hours. Twelve months later, wildly diverging trajectories. One of them is sharper, faster, and genuinely harder to compete with than they were before any of this existed. The other can’t work without the tool and can’t work well with it either, because they never built the judgment to direct it, interrogate it, or catch it when it’s confidently, elegantly, completely wrong.

The werewolves are compounding knowledge.

The villagers are compounding dependence.

And here’s the thing that should make the panic merchants and the principled refusers uncomfortable: the villagers think the tool is the werewolf. AI taking jobs. AI replacing engineers. AI ending the craft. Every hot take, every anxious LinkedIn post, every senior engineer crossing their arms at the back of the room — they’ve all decided the threat is the machine.

The machine is not the werewolf.

The person sitting across the standup from you who decided to actually learn from the thing while you were busy constructing elaborate principled objections to it? That’s the werewolf. And they’re not malicious about it. They’re just paying attention in a way you aren’t — yet.

Here’s the part that still blows my mind a little.

For less than the cost of a Big Mac Combo + 10-piece McNuggets, you have a thinking machine at your fingertips that has read more than any human who has ever lived. Every paper, every RFC, every poem written by Rumi, every post-mortem published by Google, every decision that led to the invention of the internet, every obscure kernel mailing list thread from 2009 that turns out to be the only documentation for the thing that’s breaking your system right now. It’s sitting there. Waiting for you to ask.

The information asymmetry that defined every power structure in human history — the one that let the informed minority win every single round — is gone. Dissolved. Equalized. For the first time ever, the villagers have access to the same information the werewolves do.

And most of them are using it to rewrite emails no one’s going to read, or asking what temperature to cook a f*cking chicken breast at for the fourth goddamn time this year.

Nobody’s coming for your job. Your job is being taken by someone who had access to the exact same tools you did and treated them like a curriculum instead of a calculator.

Twenty bucks a month buys you access to all of it. The only question is whether you actually learn from it — or keep treating it like a bottomless vending machine for answers you’ll forget by Friday.

Don’t be a villager. Be a werewolf. Werewolves stay well informed, and well-fed.

P.S. — This article was written with the help of Claude. And yes, I actually learned something while writing it. Practice what you preach.

Hello, World — Again

Armen Rostamian — Mon, 09 Mar 2026 00:00:00 +0000

It’s been a minute.

The last time this site saw daylight, it was a resume template stuffed with 2018-era DevOps buzzwords and a reading list I never finished. It served its purpose — and then it didn’t.

Now it’s 2026. I’m older in the ways that count — more things built, more things broken, more teams led, more hard lessons earned. A few grey hairs to show for it - and genuinely lots of gratitude.

|> This site is my corner of the internet again.

Expect writing about systems, software, AI, agents, music, the things I’m building, and the occasional rant about whatever’s on my mind.

More soon.