The_ritual

Every session starts with a negotiation you've stopped noticing.

You open the tool. New context window. You decide, in a few seconds or a few minutes, what the agent needs to know to work with you. The project, yes. The background, yes. But also: how you want it to write. What you mean by done. Which commands are safe. How precise the testing needs to be. What kind of explanation you're looking for when something goes wrong.

That negotiation is so familiar that it has stopped feeling like a problem. It feels like the setup cost of using AI - the natural tax you pay before the real work starts.

It isn't. It's a design gap. And the fact that it's become invisible is part of what makes it expensive.

The gap has a name: procedural debt. It's what accumulates when the instructions that govern how you work are implicit, fragmented, or locked inside whatever tool you were using last. It doesn't announce itself. It shows up as re-explanation, as inconsistency, as the slow erosion of reliability you can't quite trace to any one decision. It's the difference between the agent doing what you meant and the agent doing what you said in the one prompt it has access to right now.

Four_ways_procedural_debt_shows_up

Prompt bloat is the most visible symptom. The instinct, once you've been burned by an agent that missed something obvious, is to put everything into the instructions. Every rule, every preference, every edge case and exception. The instructions get longer. After a certain point, the length stops being clarity and becomes noise. Every new rule competes with the others. The agent's behaviour gets worse, not better, as the instructions get denser.

The re-explanation tax is the everyday version. Every new session, every tool switch: re-establish the voice, the testing standard, the project patterns, the safe commands, the definition of done. It feels like work. It isn't work. It's setup work dressed up as work, and it resets every time.

Instruction fragmentation is what happens once you're using more than one tool regularly. Multiple tools means multiple places where your instructions live. One gets updated when something goes wrong. The others still carry the old version. Nobody maintains all of them simultaneously. The copies drift apart, and the longer the tools are in use, the further they diverge. The agent in Tool A and the agent in Tool B are working from different understandings of what you expect.

Weak verification is the subtlest version. The agent says done. The link is stale. The mobile view is broken. The change was never tested against what you actually defined as the standard. The agent didn't remove the review burden - it moved it, and made it less predictable. You still have to inspect everything, you just don't always know what you're inspecting for.

These four patterns are not separate problems. They're the same problem in different costumes. The instruction layer that governs how you work is implicit - held in your head, scattered across prompts, copied between tools inexactly - and it degrades every time it's transferred.

What_portable_procedures_actually_look_like

A procedure is not a prompt. The distinction matters.

A prompt is something you say once. It requests a behaviour. The agent infers what you mean, applies it to this session, and the inference evaporates when the session closes. A procedure is something the agent knows how to execute from now on: when to start, what it needs, what the output should be, what the proof standard is. The procedure defines done. A prompt asks for something. A procedure governs how it gets done.

The difference shows up in reliability. If you say "write this in my voice," the agent guesses. It guesses well or it guesses badly, and you find out at the end. If you have a voice procedure, it reads the samples, runs through the prohibited phrases, applies the sentence-length patterns, strips the AI register. Same request. Different accountability.

If you say "test this page," the agent might tell you it looks fine. If you have a browser QA procedure, it opens the actual route, checks the mobile rendering, captures screenshots, reports what it found. Same task. Different evidence.

The procedure is the valuable artefact. The prompt is a request that exists for the duration of one session. The procedure travels.

Portable procedures are small and specific. Each one has a job, a scope, a trigger, and a proof standard. The voice procedure handles voice. The testing procedure handles testing. They don't try to cover everything - they cover their one thing completely enough that the agent can execute without reconstruction.

How_I_built_this_before_I_had_a_name_for_it

I didn't design a portable procedure layer. I built one because the alternative was obviously worse.

The problem that kept appearing: I was running multiple agents across multiple tools, and the instructions each tool had access to were diverging. Something would change - a decision about how testing should work, a rule about voice, a pattern I'd settled on - and I'd update one place. The others still said the old thing. Sometimes I'd notice. More often I'd encounter the consequence of it: an agent operating from a stale instruction, producing output that was subtly wrong in a way I couldn't immediately attribute.

The fix I arrived at was a file structure. A single layer of tool-agnostic instructions - the standards, the patterns, the procedures that should hold regardless of which agent or tool is reading them. On top of that, thin tool-specific extensions: the configuration, the permissions, the adaptations that only one tool needs. The general layer lives in one place. The specific layers are cheap to maintain because they contain only what genuinely differs.

What that structure actually solved was drift. When a rule changes, it changes in one place. When a new tool enters the setup, it reads the same source as everything else. When I move from one agent to another, the portable layer comes with me. I'm not starting from scratch - the agent reads what's already there and starts from a higher base.

The technical details don't need to be replicated exactly. The principle is what's portable: separate what holds across all tools from what's specific to one. Keep the former in one place. Keep the latter thin.

I'm still not sure I have all of this right. There are procedures I haven't written down yet, instructions that are probably still implicit in ways I'll discover when they fail. But the gap between what I had before the structure existed and what I have now is not subtle. Before: every tool was working from its own partial account of how I operate. After: there's a ground truth, and the tools read it.

The_compounding_argument

Each procedure you define and maintain compounds.

Every session starts from a higher base than it would without it. Every tool switch costs less. Every time a new agent enters the setup, it reads the same source and arrives at the same standard. The work of writing the procedure once pays out across every session that runs after it.

The opposite is also true, and the asymmetry is worth sitting with. Every procedure you leave implicit bleeds. It accumulates as subtle inconsistency: instructions that say slightly different things in different tools, agents working from context they've had to reconstruct from the current session's prompts, standards that erode because no one version of them is authoritative.

The bleeding is quiet. You don't notice it as a discrete failure. You notice it as a creeping sense that the reliability isn't there, that the agent's output requires more review than it used to, that the setup keeps taking longer. Procedural debt compounds in the wrong direction exactly as portable procedures compound in the right one.

The compounding doesn't announce itself either. You feel it in what the work costs.