Seven posts explaining the system. This one shows it.
Seven posts describing how a system works is not the same as watching it work. You can read every post in this series, follow every step, and still have an open question: "But what does it actually look like when it runs?" That question deserves a direct answer.
This post is that answer. Not more explanation. A real session, recorded, unedited.
The claim behind this entire series is that a well-built AgenticOS doesn't make AI magic. It makes AI predictable. The session you're about to watch isn't impressive because of what the AI does. It's impressive because of the system around it. The same session, on the same task, produces the same shape of output every time. That's the point.
This is a real task from the actual codebase. Not a demo task built to look clean. Not a simplified example. The codebase is this system's own library of skills and agents. The task is something that needed doing.
Here is what you'll watch happen, in order:
Session start: the context loads. When Claude Code opens, ~/CLAUDE.md loads automatically. That file is the constitution. It tells the agent where memory lives, how to dispatch work, and what the rules are. Before a single instruction is typed, the agent knows the system it's operating inside. The memory index loads next. That's where prior session context lives. The agent reads it and starts hot instead of cold.
The task goes through the prompt-shaper. Rather than typing a vague instruction and hoping the agent figures out what's wanted, the task runs through prompt-shaper first. The shaper asks a focused set of questions. It turns a rough idea into a scoped brief: what the output is, what files it touches, what done looks like. This takes a few minutes. It prevents thirty minutes of correction later.
Specialist agents are dispatched in parallel. Once there's a brief, agents execute against it. Not one agent doing everything sequentially. Multiple agents running simultaneously in a single message, each with a narrow scope. You'll see this in the terminal output: multiple task outputs arriving in a short window.
The review gate runs. After the implementation agents finish, code-reviewer and library-reviewer are dispatched in parallel. They're read-only. Their job is to catch what the implementation agents can't see. The reviews come back with a verdict: ship, ship-with-fixes, or hold.
Reading the diff. Before merging, the diff is read directly. Not trusting the agent's summary. Checking the actual changes: what changed, in which files, does it match the brief.
Done: the merged result. The task is merged. The session ends. The memory layer gets a new entry if anything non-obvious was learned.
That's the full loop. Now watch it.
This session took real time 22 minutes; its fast-forwarded!
Readers of the series will recognize the patterns as they appear. A few things worth watching for specifically:
The shaper isn’t run because the PRD was excellent. This saves the agent time, and you your sanity. Ask in chat if you want the PRD.md
The review gate runs in parallel. Two agents, one message, both results arrive before a merge decision is made. The gate is not a formality. It's structurally separate from the implementation agents, which means it has no stake in defending what they wrote. An independent second pass by construction.
The memory loaded at the start. One of the memory entries that loads is the one that explains the 🌶️ Take prefix for social posts. That's why the agent doesn't ask about it. The system knows. That's what memory is for: non-obvious facts that would otherwise have to be re-explained in every session.
The agents don't improvise scope. At no point does an agent decide the task needs something extra. The brief is the contract. The agents execute the brief. Scope decisions happen at intake, not during implementation.
The diff is checked, not assumed. The agent's final message is a description of what it intended to do. The diff is what it actually did. Those two things are checked against each other before merging. This is the habit that prevents a whole category of invisible errors. A subagent that says "I updated the routing in CLAUDE.md" and a diff that shows it also touched three other files is a signal, not a rubber stamp. Read the diff.
The session is reproducible. There is no moment in the recording where the output depends on a lucky prompt or a particularly cooperative AI response. The structure of the session is the same every time this class of task runs. Shaper runs first. Agents dispatch from the brief. Gate runs after implementation. Diff before merge. Any engineer on any team can follow the same structure and get the same shape of result.
The session you just watched isn't impressive because of the AI. The underlying model is the same one you have access to. What's different is the system it's operating inside.
CLAUDE.md loads on session start. Memory starts the agent warm. The shaper turns vague requests into tight briefs. Specialist agents execute with narrow scope. The review gate runs independently. The diff is read before merging.
None of these steps are clever. Each one is just a habit encoded into a file. The aggregate of those habits is a system that produces predictable output from the same starting materials every time. That's not magic. That's engineering.
If you've read this series and want to build your own version, start with the map. Every component is explained there, with the build order, the reason each layer exists, and what it gives you. You don't have to build all seven layers at once. The map tells you which layer to start with and what you get from it.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.