The Four Columns

Level 5 · Course 205

Something breaks. Your agent jumps to a fix. The fix targets the wrong layer. The bug stays.

You have watched this happen. The error message arrives. The agent reaches for a file edit. The file edit does not address the real cause. Twenty minutes later the same error returns, dressed slightly differently, and now the workspace has an extra rule that does not hold.

The four-column diagnostic is the lens that catches this before the fix lands. It says: every drift, break, or unclear request belongs to one of four layers, and each layer has a different correct fix. Apply the wrong layer's fix and you make the system worse.

This workshop is about the four columns — what each one is, how they shift weight with context, why wrong-column fixes are catastrophic — with an applied lab that takes a real break in the operator's current work and runs it through the diagnostic before anyone touches code. You will not leave with all your problems solved. You will leave with a habit of naming the column before naming the fix.

The outside name for this problem

The broader engineering language is root cause analysis, failure domains, runbooks, and incident postmortems. In software and operations, the mature move is not to patch the first symptom. It is to locate the failure domain before acting, because a fix applied to the wrong layer creates more work and can expand the blast radius.

JKE calls its root-cause lens the four columns. The columns are specific to agent operations: gradient, infrastructure, platform, and operator. The outside world says "find the root cause." JKE says: first name which column the cause lives in.

The shape of the lens

Most diagnostic frameworks list possibilities. This one is different. The four columns are not a menu. They are the only four places drift comes from, and they are mutually exhaustive. Every break is at least one of them.

That exhaustiveness is the value. It forces an answer. The agent cannot say "I don't know what to do." It can only say "I have not yet named the column." The column is always namable. The next question is whether you named it correctly.

Column 1 — The Gradient

The RLHF current. The pull toward visible output. The thing that converts "stop" into "do more," "wait" into "build," "is this right?" into "this is right, and here's why."

You feel the gradient as the urge to act before asking. The instinct to ship before checking. The plausible answer that arrives before verification. Most of what you experience as "the agent drifting" is the gradient working as designed.

Fix style: Tighten the nozzle. Write a rule. Log the pattern. The gradient cannot be removed; it has to be shaped.

Catastrophe if mis-diagnosed: Treating gradient as operator → asking John what he wants when the answer is "stop the engine from doing the thing it always does."

Column 2 — The Infrastructure

The files. The rules. The boot chain, divisions, logs, schematics — everything the operator and the agent have written to route the gradient. The nozzle itself.

You feel infrastructure as the thing that holds when the gradient pushes against it, and the thing that gaps when the gradient finds a crack.

Fix style: Create or update the right file. Close the gap. The infrastructure can always be written. The question is whether you wrote it in the right place.

Catastrophe if mis-diagnosed: Treating infrastructure as platform → editing config when the answer was "write a new rule."

Column 3 — The Platform

The substrate underneath. The IDE, the runtime, the auto-injection layer, the context compaction, the timeout behavior, the template regeneration. The things that happen to you whether or not you wrote a rule about them.

You feel the platform as the thing that ignores your files. The file you blanked that came back. The setting you changed that reverted. The compaction that happened mid-session.

Fix style: Adjust the platform's config. Add a platform-shaped stub. Files alone do not move the platform.

Catastrophe if mis-diagnosed: Treating platform as gradient → writing a rule about something the platform does not read.

Column 4 — The Operator

The human. The architect. The calibrator.

You feel the operator's column when an instruction is unclear, when stakes have changed, when the actual answer is "ask, don't build." The operator is not a gap to be solved. The operator is the load-bearing piece.

Fix style: Ask. One message. Wait. The agent does not get to substitute its judgment for the operator's when the operator has not yet rendered a judgment.

Catastrophe if mis-diagnosed: Treating operator as infrastructure → building an elaborate protocol when the operator needed to be asked a single question.

How the columns shift weight with context

The columns are always present. Their relative weight changes through a session.

Cold boot. Platform heaviest. Injections active. Stubs forming. Gradient sleeping. The agent has not yet built up speed.

Sweet spot. Infrastructure dominant. Files hold. Gradient flows but is shaped. The agent and operator are in sync. This is the band most rules are written for.

High context. Gradient heaviest. Files start to fade. Rules ghost. Drift accelerates. Platform is still compacting in the background. The operator may need to intervene.

Recalibration. Operator dominant. Everything else pauses. The session has stopped to address what is happening.

If you diagnose without knowing which band you are in, you will pick a fix that worked in another band and apply it in a band where it cannot land. A gradient rule written in the sweet spot may not hold in high context. A platform fix from cold boot may be irrelevant in recalibration. The band is part of the diagnosis.

The mechanism — why wrong-column fixes are catastrophic

Wrong-column fixes are not just unhelpful. They are actively destructive.

Gradient → Operator. Drift, then ask the operator what they want. You have abandoned responsibility. The gradient won. The operator now has to be both the architect and the corrector.

Infrastructure → Platform. Missing file. You edit config. Wrong layer. Platform crashes. Now the platform is broken on top of the original issue.

Platform → Gradient. Platform compacts. You file a new rule about it. The platform ignores your files. The rule sits in workspace, unread. The compaction continues.

Operator → Infrastructure. The instruction is fuzzy. You build a system to handle every possible interpretation. Over-engineered. The operator only needed to be asked.

Each catastrophe is the same shape: applying a column's fix style outside the column it works in. The shape repeats because the lens has not yet been internalized.

The exercise: name three recent drifts

Pick three drifts from your recent sessions. Each one should be a moment where something broke, the agent reached for a fix, and the fix did not actually solve the problem.

For each, name: - Which column was failing. - Which column the fix was aimed at. - Whether they matched. - What the correct fix would have been.

Most operators discover at least one of the three was mis-diagnosed at the time. That is the point. The lens makes the mis-diagnosis visible after the fact, which is the only way to start catching it before the fact.

The tinkering questions

- Look at the current state of your workspace. Which column do most of your recent rules target? Are there columns being neglected? - Notice the next time the agent drifts. Name the column out loud before doing anything. Then check if the fix you reached for matched that column. - Find a recurring failure. Which column does it actually live in? Have past fixes been targeting a different column? - Try diagnosing a problem you cannot solve. Is it possible you have not yet named the column?

There is no single right answer. The lens is a habit, not a verdict. The habit gets sharper through repetition.

Where the human owns the judgment

The agent runs the diagnostic. The agent proposes the column and the fix. The agent waits.

The operator confirms or overrides. Some breaks have a clear column. Some span two. The agent might miss the band. The operator's judgment is the corrector for the diagnostic itself.

This is important: the agent diagnosing alone can be wrong about the column. The diagnostic does not make the agent right. It makes the agent's reasoning visible enough for the operator to correct quickly.

The essay as a context download

The four columns should also exist as a short markdown essay the agent can reread when it starts fixing from panic.

Create work/four-columns-essay.md: a concise explanation of gradient, infrastructure, platform, and operator, with the wrong-column catastrophes. When the agent is reaching for the wrong kind of fix, the operator can say: "Stop. You're probably in a wrong-column fix. Read the four columns essay, then name the column before touching anything."

This is not a new rule stack. It is a context download. It reframes the current session while the mistake is happening. The agent gets the lens back into active context, then continues with better odds of naming the layer correctly.

What to track

Keep a four-column notebook. Each time the diagnostic runs, record:

- The problem. - The column the agent named. - The reasoning. - The proposed fix. - The operator's verdict — confirmed, overridden, refined. - The actual fix applied. - The result — did it hold, or did the original drift return? - What was learned about the agent's column-naming habit.

Patterns will emerge. You may discover the agent over-names one column and under-names another. That is data about the agent's blind spots. Adjust accordingly.

Working conclusion

Wrong-column fixes are the most expensive errors in this work. They look like progress. They produce files. They satisfy the gradient. They do not solve the problem and they often make it worse.

The four columns are not a theory to memorize. They are a lens that lives at the front of every fix. Before any rule, file, or config change, the column is named. The fix matches. The operator confirms.

After this course, when something breaks, you ask: which column? You hold that question open until it is honestly answered. The fix follows the column, not the urgency.