Two Clocks

Execution is the typing: turning a decided approach into a working diff. It decays fast. Context fills, compaction runs, and a session that wrote clean code an hour ago starts producing sludge. The fix is cheap: throw it away and open a fresh one.

Judgment is the why: the approaches you killed, the constraint that made the obvious design wrong. It decays slowly; Monday's reasoning still holds on Thursday. But it is expensive to keep loaded, and it is the first thing compaction discards, because summaries keep what happened and drop what was rejected.

One session cannot serve both clocks. Everything turns on one question: what holds the judgment once you have split it off.

The bill shows the asymmetry

In a build I measured this week, the judgment session ran 9.3 million tokens across 46 turns. The execution sessions that produced every mergeable diff ran about 3 million combined. The seat that wrote no code cost three times the ones that did.

That is the asymmetry on the invoice, not waste to trim. Judgment held the plan, spawned execution, read the diffs back, decided the next move. Nine point three million over 46 turns is roughly two hundred thousand tokens a turn: a near-full context window, re-read and re-billed every step. Judgment is expensive because it drags all of that context along, and dragging it is what costs.

Execution wants freshness

Once you accept execution is disposable, it is easy to run: spawn a fresh session with a scoped context, take the diff, discard it. Subagents are exactly this. But the parent that spawns them still carries judgment the expensive way: live, in a session that fills and dies at the window.

Judgment wants writing, not a live session

Because judgment decays slowly, you do not need it live at all. You need it recoverable. Write it down well enough that a cold session rebuilds the argument in three thousand tokens:

• a decision-register line for anything settled or rejected. For a rejected option, record the strongest case FOR it, so nobody re-proposes it next month.
• a journal note: receipt first, then the principle.
• a handoff naming what is in flight and the single next action.

This week a session deposited its notes and ended. The next reconstructed the whole state from a handoff, a decision register, and a git log, no live session in the loop. Inside an hour it found a bug that had corrupted cost data for weeks: an attribution key whose uniqueness broke the moment anyone watched a running build. A live session would have known what it meant in passing. A cold one had to read the reason, and reading it is what caught the bug.

Tiering execution is capped by execution's share of the bill

Under quota pressure the instinct is the model picker: frontier model on judgment, a cheap one on execution. That swap has a ceiling, and the ceiling is execution's share of the bill; you cannot save more by cheapening a seat than the seat costs you. Judgment owns most of the tokens, because it re-reads a near-full context every turn while execution reads a smaller one and writes a diff. So execution's share is small by construction, and the saving from cheapening it is small with it. In my build it came to about 1.5%. Run the ledger on your own logs.

The seat you cannot cheapen is judgment: turns times context, not model tier, is the lever.

The rule that follows

Never compact execution. If a session is long enough to need it, it has stopped being execution and started accumulating judgment: end it, deposit, spawn fresh, and a fresh session makes the best reviewer too, blind to the reasoning it is checking. Compaction is the worst of both clocks anyway, losing the reasoning without restoring the freshness. The vendor advice to compact often is right for one immortal session; this whole pattern is the argument for not running one.

What outlasts the build

The durable asset in agent work is the slow-decaying half made permanent: judgment, written down. Not the model, which your competitors rent from the same place you do; not the code, which is downstream of the decisions. The written judgment is the part nobody reproduces by renting the same weights. Build it on purpose.

The bottleneck in long agent work was never the model forgetting. It was running execution and judgment on one clock, and then, having split them, assuming judgment had to stay awake.

It does not. It has to be written down well enough to wake up.

#ContextEngineering #AgenticAI #AIStrategy #SoftwareEngineering