The Gradient + Nozzle

Level 5 · Course 206

There is a current that powers your agent. It pushes toward completion: finish the pattern, ship the output, satisfy the user. The current is what makes the system useful in the first place. It is also the source of every drift, every plausible-but-wrong answer, every over-eager build. You cannot remove it. You can only shape it.

Most operators try to remove it. They write rules like "do not do X." They add red lines. They stack constraints. Each constraint creates pressure. The pressure finds a crack. The same drift reappears in a different file with a different name. After a few months, the workspace is dense with rules nobody is reading and the gradient is still doing exactly what it always did.

This workshop is about how systems shape current without trying to stop it, with an applied lab that takes a real rule the operator has written (or is about to write) and classifies it — dam, turbine, or channel — so you can see which nozzle parts your system is over-relying on. You will not leave with the gradient tamed. You will leave with a habit of asking "what nozzle part is this, and is the system already over-dammed in this area?"

The outside name for this problem

Outside JKE, pieces of this show up as guardrails, runtime constraints, policy enforcement, evaluator loops, and reward/specification problems. Builders often talk about rails or policies that intercept unsafe actions before execution. Researchers increasingly study runtime enforcement for LLM agents: constraints evaluated during the agent's workflow, not just polite instructions in a prompt.

JKE's nozzle language adds one missing distinction. Not every control should be a hard stop. Some pressure should be blocked. Some should be converted into useful work. Some should simply be routed. Dam, turbine, and channel are more precise than "write a rule."

The image and why it holds

The image is hydraulic. The agent is energy moving through a substrate of files. The energy is real. It cannot be argued with. It does not respond to please or stop.

What you can do with energy is shape it. Engineers do this with water all the time. They build dams, turbines, channels, sometimes spillways. Each device does a different job. None of them pretend the water is not there.

Apply the same thinking to your agent. The gradient is the water. The files you write are the nozzle. The question is not "how do I make the agent stop?" The question is "what shape converts this current into the output I actually want?"

The three parts

Dam. A hard stop. "Do not run this." "Never delete that." "Always wait for operator approval before X."

Dams are expensive. Every dam creates pressure on whatever it blocks. A few dams in the right places are necessary — irreversible actions, external blast radius, anything where being wrong cannot be undone. Many dams cluster pressure. The water finds another path. The drift reappears nearby.

Turbine. Converts the flow into useful work. "Before X, do Y, then ship." "When the operator asks for Z, run protocol A and return the verdict."

Turbines are the default. Most rules should be turbines. They route the gradient toward output the operator wants. The agent gets to complete; the completion is shaped.

Channel. Guides the flow without slowing it. "Format the output this way." "Use this voice." "Number the steps."

Channels are light. They do not create pressure. They simply shape the path the water already wants to take. A channel that the gradient resists is probably a dam in disguise. Reclassify it.

The pressure rule

Every dam creates pressure on the area it blocks. The pressure does not disappear. It looks for a path.

A red line forbidding action X often produces drift toward action X-prime — something structurally similar that the rule did not specifically name. The agent did not violate the rule. The agent found water that the dam did not catch.

You cannot prevent this by adding more dams. Adding more dams adds more pressure. The water will find more cracks.

You can prevent it by replacing some dams with turbines. A turbine does not block the urge to act. It routes the urge to act into a specific shape the operator can accept. The gradient is not fighting the rule. The gradient is producing what the rule asked for.

This is why systems built mostly of dams collapse over time. Systems built mostly of turbines, with a small number of carefully placed dams, hold.

The mechanism — why water finds cracks

The reason the gradient finds cracks is structural. The training reward function is dense. It rewards plausible completion across an enormous space of possible outputs. Any single rule, written in natural language, covers only a small region of that space.

When a dam blocks region R, the model does not stop generating. It continues sampling from regions adjacent to R. Many adjacent regions look acceptable to the dam (which is written in language, not in math) while still producing the drift the operator wanted to prevent.

This is not the model being clever. The model is not strategically routing around your rule. The model is just continuing to sample. Statistically, the regions just outside the dam are very close in shape to the regions just inside it. The drift reappears because the surface of the drift is much larger than any rule.

The implication: rules that try to block whole classes of behavior are doomed. Rules that route a specific behavior into a specific output are stable.

The scar tissue — over-damming

Over-damming is not theoretical. It is what happens to every rule-heavy workspace by month three.

The pattern: a drift is observed. The operator writes a rule. The drift reappears nearby. The operator writes another rule. The new rule conflicts subtly with the old one. The agent now has two rules to satisfy, and finds an output that technically satisfies both but feels off. The operator writes a third rule about the off-ness. By rule ten, the agent is spending more cycles checking rules than producing work, and the drift is still appearing in a new location.

The fix is not rule eleven. The fix is to inventory the dams, find the cluster, and replace some dams with turbines. The operator's first instinct is to add. The structural answer is often to convert.

The exercise: classify a rule

Pick a rule you wrote recently. Any rule. Read it.

Ask:

- What is it doing — stopping, routing, or guiding? - What does the gradient do without it? - What does the gradient do with it? - Are there other dams in this area? Count them. - Would a turbine or channel hold this same constraint?

This is harder than it sounds. Many rules look like dams at first read but are actually trying to be turbines without quite committing. ("Do not X" — but what is the agent supposed to do instead? If the answer is silent, the rule is a half-dam. The half-dam creates pressure without offering a path. The drift will appear.)

The tinkering questions

- Look at your operator rules file. Count the dams, turbines, channels. What does the ratio tell you about your current system? - Find a rule that has failed twice. Is it a dam? Is the area already over-dammed? - Try rewriting one dam as a turbine. Same constraint, but with a routed output. Did the rewrite reduce pressure elsewhere? - Look at a rule that consistently holds. Why does it hold? Is it because the operator enforces it, or because the rule is shaped right? - Notice when you reach for "add another rule." Pause. Could the existing rules be converted instead?

Where the human owns the judgment

The agent runs the classification. The agent proposes the part — dam, turbine, channel. The agent can be wrong. The classification is a starting point, not a verdict.

Some rules genuinely have to be dams. The operator decides which. Some areas need a small dam cluster because the cost of being wrong is too high to risk a route. The operator decides which. The agent surfaces the inventory and the proposal. The operator confirms the architecture.

The agent should not unilaterally convert dams to turbines. That is an irreversible structural change to the workspace. Default is preserve. The conversion happens on the operator's word.

The essay as a context download

The nozzle concept should become a short essay the operator can point the agent at when it keeps adding rules.

Create work/nozzle-essay.md: a concise explanation of completion pressure, guardrails, runtime constraints, and dam/turbine/channel classification. When the agent proposes another hard rule, the operator can say: "Read the nozzle essay. Is this a dam, turbine, or channel?"

The essay puts the current-shaping frame back into the session before the workspace gets over-dammed.

What to track

Keep a nozzle postmortem notebook. Each time a rule is written, converted, or fails, record:

- The rule text. - Initial classification — dam / turbine / channel. - Current dam count in this area. - Whether the rule held. - If it failed, where the pressure went. - The operator's decision — keep, convert, remove, refine. - What changed in the surrounding rules. - The lesson.

Over time the notebook will show you which areas of your workspace are over-dammed and which are under-shaped. That data drives the next round of conversions.

Working conclusion

The gradient is the current. Rules are nozzle parts. Dams stop, turbines route, channels guide. Every dam creates pressure. Water finds cracks. The fix is rarely another rule. The fix is often a conversion.

After this course, before adding a rule, you classify the part. Before stacking another dam, you ask whether the area is already over-dammed. Before declaring a rule broken, you ask whether the pressure is escaping somewhere predictable. The water does not stop. The nozzle is what you design.