Essay 6.5 — The Markov Phasic Brain, Part 5 of 10.

Essay 6.4 closed with PLAN handing forward — a plan_file named, an altered-list scoped, the cycle’s contract written down. EXECUTE is the phase that builds against that contract.

EXECUTE is the cycle’s only producing phase. Every other phase reads, analyzes, refines, or routes; EXECUTE is the one that turns analysis into artifact. Project source code, scripts, configuration, the .md plan, the .yaml plan, every file the seed agent ever materializes on disk — all of it is brought into existence here. The cognitive failure EXECUTE prevents is the unstructured build — the long uncommitted run that drifts away from the plan, accumulates change, and either ships a different feature than the one designed or erases everything when a failure hits halfway through. EXECUTE’s discipline is checkpointing: short, focused commits that close one piece of the plan before opening the next.

The sources are narrower than OBSERVE’s or PLAN’s. EXECUTE reads the plan document the cycle is executing against, reads the altered-list CLAUDE.md files for the per-directory context, reads the files it is about to edit, and reads the seed agent’s knowledge directory for patterns the plan refers to. External documentation is allowed but rare in practice — the plan is supposed to carry the design decisions; EXECUTE’s job is to build, not to keep researching. The phase dispatches its own family of subagents (execute-* workers), and the budget arithmetic explicitly favors delegation: every execute-subagent dispatch grants +3 direct-action budget; every direct edit outside .claude/ consumes 1.

The write side is where EXECUTE earns its name. The write-tool guard is gentler than the read-only phases', but only inside the altered list — the frozen snapshot of directories that OBSERVE and PLAN authorized for editing. A write inside the list lands; a write outside is rejected at the tool boundary, and the agent has to roll back to PLAN to amend the contract before the path opens. ⓘ

Inside CLAUDE.md files, the anchor discipline cascades downward from ---Ex---. That is the primary section the phase guard nudges EXECUTE toward, and the same enforcement also permits writes into ---Ve--- — so EXECUTE can pre-stage refinements to the VERIFY checklist when execution surfaces something new to check. What the discipline blocks is upward writes: EXECUTE cannot edit what OBSERVE or PLAN wrote above the ---Ex--- marker. Two nested fences — path scope outside, anchor cascade inside — keep the compartmentalization intact even as the phase is the most active. ⓘ

Pacing follows the cycle’s shared shape. The multiplier sentinel locks every tool at phase entry until the agent commits to a depth — the same prevent-silent-skipping rationale that gates OBSERVE and PLAN. ⓘ Smaller numbers declare a deeper phase: a multiplier of 0.5 means each action awards half the base points, so more actions are needed to fill the 100-point phase-transition bucket. Larger numbers (2 to 3) award proportionally more and the bucket fills with fewer actions — a faster, surface-level pass. A pair of point gates paces read/write rhythm against the working CLAUDE.md, and a direct-action budget biases the main session toward subagent dispatch.

What is distinctive in EXECUTE is the checkpointing cadence — the phase-commit script ships two shapes (intermediate and forward), and the intermediate form is the default. Small commits stay in EXECUTE for more work; the forward commit advances the phase. The cadence is the architecture’s structural answer to drift: every few completed plan items, the agent commits and notices whether the cycle is still on course.

The rest of this essay opens the universal-file-creator role, walks the two fences, explains the checkpointing pattern, and names the delegation bias the budget encodes.

The universal file-creator

EXECUTE doesn’t just write code — it writes everything. The principle is universal: every file the seed agent materializes on disk is brought into existence by EXECUTE. Project source, scripts, configuration, the .md plan, the .yaml plan, anything else with a path — all of it is EXECUTE’s deliverable. ⓘ

OBSERVE and PLAN do their thinking inside CLAUDE.md working memory; VERIFY refines what EXECUTE produced; CONDENSE routes content into durable layers. EXECUTE is the only phase that turns analysis into artifact. ⓘ

The .yaml is not a transcription of the .md — it is its own cycle of work. Cycle 1's EXECUTE materializes the .md for the first time, and the plan enters its drafting state. The .yaml does not arrive then. It arrives only after the user approves the .md and the state flips to md_approved — and the cycle that follows is a whole new OPEVC pass dedicated to the .yaml: OBSERVE re-reads the approved .md, PLAN designs the YAML structure inside CLAUDE.md analysis, EXECUTE writes the .yaml file for the first time, VERIFY refines it. ⓘ

Same phase, same compartmentalization rule, different trigger: cycle 1 for the .md, a post-approval cycle for the .yaml — which takes the approved .md as input and produces a context-injection target as output. ⓘ

The full plan-state machine — including how the .yaml injects into every phase entry — is the subject of Essay 6.10.

The frozen fence

The altered list is a frozen snapshot of directories, captured from OBSERVE and PLAN at phase entry. A guard inspects every write call against that snapshot before the call lands. A path inside the snapshot proceeds. A path outside is rejected, and the agent has to either roll back to PLAN to amend the contract or accept the fence. ⓘ

A second guard inside the same hook protects the phase-section markers — the footer anchors from the previous essay — so that EXECUTE’s writes cascade downward from ---Ex---. It can land execution notes there and pre-stage refinements to the VERIFY checklist beneath ---Ve---, but it cannot edit what OBSERVE or PLAN wrote above the ---Ex--- marker. The compartmentalization holds even within a single CLAUDE.md. ⓘ

Image pending — EXECUTE’s two nested fences. An outer path-scope fence drawn from the altered list, and an inner anchor-cascade fence inside each CLAUDE.md showing the cascading-downward write permission (Ex + Ve allowed, Ob + Pl blocked)
Prompt: ASSET: images/execute-two-fences-b6-5.png Style: Match `opevc-cycle-blackboard.png` exactly. Dark slate chalkboard; hand-drawn chalk lines; pastel chalk (cyan, green, orange, pink, magenta — same palette as the cycle image) for the fence borders and the CLAUDE.md tile; white chalk for labels and arrows; chalk sticks at the bottom edge; faint chalk dust at the edges. IMPORTANT: Use only the literal names listed below. Do not invent or substitute any other names, labels, or fence descriptors. Layout: Two nested chalk rectangles arranged concentrically on the board. Outer rectangle (cyan border, large): labeled at the top edge "altered list", with three small chalk file icons inside labeled "dir A", "dir B", "dir C" — these are the allowed directories. A short white chalk arrow enters the outer rectangle from the left labeled "write call"; a second white chalk arrow attempts to enter from outside the outer rectangle and is blocked by a chalk X mark, labeled "out of scope". Inner rectangle (orange border, smaller, drawn inside dir B): represents a single CLAUDE.md, labeled at the top edge "CLAUDE.md". Inside the inner rectangle, four horizontal chalk bands stacked vertically, each labeled with a pastel-chalk anchor name: top band cyan labeled "---Ob---", second band green labeled "---Pl---", third band orange labeled "---Ex---" (highlighted with a small white chalk check mark in the margin marking the primary anchor), fourth band pink labeled "---Ve---" (also marked with a small white chalk check mark in the margin marking the permitted cascade). A white chalk arrow enters the inner rectangle from outside and lands cleanly inside the third band (---Ex---), labeled "primary write". A second white chalk arrow enters and lands cleanly inside the fourth band (---Ve---), labeled "pre-stage verify" — depicting the cascading-downward permission that lets EXECUTE pre-stage verify-checklist refinements. A third white chalk arrow attempts to land in the first band (---Ob---) and is blocked by a chalk X, labeled "blocked upward". Keep every line hand-drawn and slightly imperfect, never ruler-straight. STRICT NAME WHITELIST — the image must contain only these literal text strings as labels: "altered list", "dir A", "dir B", "dir C", "write call", "out of scope", "CLAUDE.md", "---Ob---", "---Pl---", "---Ex---", "---Ve---", "primary write", "pre-stage verify", "blocked upward", plus the caption below. No other words, file names, folders, or fence descriptors may appear.
Image 6.5. EXECUTE’s two fences. Path scope outside, anchor cascade inside — write to Ex + Ve, block upward to Ob + Pl.

Checkpoints over runs

The phase is structured around checkpoints — short, focused commits that finish one piece of the plan before starting the next. The pattern is deliberate. A long uncommitted run inside EXECUTE has the same problem as a long run anywhere else: drift accumulates, and a failure halfway through erases everything. ⓘ

Checkpointing forces small wins. It also gives the agent a clean place to pause and notice when the plan is wrong, before sinking another ten tool calls into the wrong direction. ⓘ

EXECUTE writes two things: the code, and execution notes in the working CLAUDE.md. The notes are short — what surprised the agent, what decisions the agent made when the plan left a judgment call open, what the next phase should know. The notes are what turn a sequence of commits into a coherent narrative. They will be one of the things CONDENSE absorbs. ⓘ

The delegation bias

EXECUTE is also where subagent dispatch shows up most heavily, and the point schedule encodes that explicitly. Every execute subagent the main session launches grants the session a small direct-action budget — a handful of extra writes the main session is allowed to make on its own. Every project file the main session edits itself spends some of that budget back. ⓘ

Reading project files does not consume budget; only edits and writes outside .claude/ do. The arithmetic is small but the bias is intentional: the main session is incentivized to delegate the implementation to execute subagents rather than do the file work itself. A typical execute phase will spawn one or two execute subagents on file edits while the main session works on the spine of the change. ⓘ

The discipline favors sequential dispatch — one execute subagent at a time, with the main session orchestrating between checkpoints. When fan-out is genuinely useful, the operational ceiling is kept low (currently held at two-in-flight in the prototype); the cap was set after a cycle in which a parallel dispatch pushed the context window past a safe tier and triggered cascading compaction. ⓘ The deeper discipline of subagent dispatch — and the per-plugin agent rosters that make it tunable — is the subject of Essay 7.

The comment-density drift gate

EXECUTE carries one gate that no other phase has — a comment-density drift gate on code edits, enforced inside the same execute-guard hook that polices the altered list. ⓘ

The rule is drift-only: an edit cannot lose comments relative to the file’s prior state. There is no absolute floor; a sparsely-commented file does not trigger the gate, only an edit that strips reasoning from the file. Several distinct block verdicts cover the failure modes — code-added-without-comments, comments-stripped, comment-loss-disproportionate, docstring-stripped, new-file-no-docstring — each with its own block voice. A coaching tier (thin-comments) fires below the block threshold and lets the edit through with a stderr nudge. ⓘ

The gate matters because the most common LLM failure mode on code edits is the silent comment-strip. An LLM optimizing for terseness will happily delete the # why this exists line as "cleanup." The reasoning is gone before any human reviews the diff. By forcing comment-loss to be visible at the moment of the edit — and by blocking the worst categories outright — the architecture protects the codebase’s reasoning trail from the very tool writing it. ⓘ

A worked example lands here. Cycle 3 of the migration job has reached EXECUTE. The altered list is set; the marker-schema revert has been planned. The agent dispatches one execute-* subagent to revert cycle 2's marker code, then turns to write a single hook update itself. The Write tool fires; the comment-density gate inspects the delta. The old script.sh carried a six-line header docstring; the new version has it intact but stripped two inline # the reason this branch exists comments from the body. The disproportionate-loss verdict fires. The edit is blocked. The agent reads the block message, restores the comments, re-submits. The check passes. Reasoning preserved; commit landed. ⓘ

What you would customize

EXECUTE is where most architects will tune the most knobs, because it is where the seed agent’s velocity actually shows.

The architect would tune the execute subagent roster. The current roster covers code edits, test runs (deferred to VERIFY), and bulk refactors. A seed working in a content-heavy domain — legal drafting, market research write-ups — would want subagents specialized for prose generation and citation insertion, with their own scope guards. The roster is the surface; the entries are yours. ⓘ

The architect would tune the direct-action budget arithmetic. The current grant (currently +3 in the prototype) per execute-subagent dispatch and the consumption per project edit (currently -1) are tunable. Your seed might want a higher delegation bias (a larger grant, a heavier consumption) or a lower one. The arithmetic is small; the bias it encodes is large. ⓘ

The architect would tune the comment-density verdicts. The current block-categories (currently five in the prototype) and the coach-category (currently one) were calibrated against the prototype’s own cycles. A seed working in a heavily-commented domain might block on thinner deltas; one working with a generated-code intermediate stage might exempt specific paths from the gate entirely. The verdicts are the mechanism; the thresholds are yours. ⓘ

The altered-list-fenced-EXECUTE pattern lifts off the prototype into any work where a misaimed edit is expensive. A legal-drafting seed cultivated by a litigation associate could install the altered-list fence around the active-matter folder, so the redline subagent EXECUTE dispatches cannot edit briefs filed under any other matter; the comment-density verdicts retune to fire on stripped statutory citations and footnote anchors rather than stripped code comments, since those are the reasoning trail the next reviewer depends on. ⓘ

The honest design-limit is that the fence and the verdicts are friction, not mathematical enforcement: the path-scope check, the section-marker check, the comment-density delta are voice injections riding on top of pre-tool-call hooks, and the checkpoint commits are agent discipline rather than transactional rollback. ⓘ

A determined operator can route a cross-matter edit through gmode, the named off-cycle lane, and pay the deliberate-bypass tax of composing the justification; the agent could in principle work around the spirit of the fence by editing through prose channels the guard does not inspect. The discipline rests on the agent reading and obeying the injected voice, slowed enough by the friction that the operator can intervene before the misaim lands. ⓘ

What the architect would not customize is the altered-list fence itself. The fence is the floor: an execute phase that lets the agent write outside the plan’s declared scope is not an execute phase.

The deepest payoff of EXECUTE is the cognitive failure mode it prevents: the cleanup that erases reasoning. An LLM finishing a job will, given freedom, polish its output by removing things it judges decorative — comments, docstrings, the careful # why lines that future-readers depend on. The comment-density gate is the architecture’s structural answer. Combined with the altered-list fence and the checkpoint cadence, EXECUTE is the phase that lets the agent build fast without letting it build fast in ways the next architect (or the next-cycle agent) will silently inherit and curse. ⓘ

When EXECUTE believes the plan is implemented, it commits the final checkpoint and the orchestrator advances the job to VERIFY.

Essay 6.5 — The Markov Phasic Brain, Part 5 of 10.

Previous: Essay 6.4 — PLAN — Decide, Then Lock — naming the contract, the plan_state machine. Next: Essay 6.6 — VERIFY — Independent Eyes — scripts-only, auditor subagents, approval authority.