The Loop: Human → Protocol → AI → Human
The canonical H‑Edges pattern
Most AI problems don’t show up in the dramatic moments. They show up in the tiny ones. You ask the model to clean up a customer note or rewrite a short announcement, and it quietly shifts your intent. Maybe it adds a reason you never gave or adjusts the tone in a way that doesn’t fit the situation. These small changes tend to spread if you don’t catch them.
My sense is that this happens because the model is guessing. And guessing is probably the worst thing you can allow inside a workflow that needs to be repeatable.
The Loop is meant to stop that.
Human: Define Intent
The human sets the direction. It’s the part where you decide what the work is actually supposed to accomplish. For example, imagine a support lead preparing a message about a service outage. The intent might be: “Explain what happened, keep the tone steady, and avoid anything that sounds defensive.” That’s enough to anchor the work. This is the one place where judgment really matters, and AI doesn’t have much of it.
Another example: a product manager writing a feature announcement. The intent could be: “Describe the new capability without overselling it, and keep the explanation short enough for a customer to read in under a minute.” Again, the human decides what matters.
Protocol: Encode Behavior
A protocol turns intent into guardrails. One useful way to think about a protocol is to treat it like a function. If you’ve ever written code or remember your math classes, you probably recall how a function works. You give it an input, it follows a defined set of rules, and it produces an output. It doesn’t improvise. It doesn’t wander. It does exactly what the rules allow.
A protocol works the same way. In the outage example, the protocol might say: “Don’t mention staffing. Don’t speculate about root cause. Don’t offer compensation.” These rules keep the model away from areas that create legal or operational problems.
In the feature announcement example, the protocol might say: “Avoid future promises. Avoid technical jargon unless it’s already familiar to customers. Avoid adding examples that weren’t provided.” I’ve seen this help because it removes the model’s urge to fill gaps with invented details.
Micro‑Mechanics: How Intent and Protocol Behave
This is where things get more technical. I’ve noticed that intent behaves a bit like a type signature. It tells the model what shape the output should have. If the intent is unclear, the model tends to guess the type, and that’s usually where drift begins.
Protocols behave more like pure functions. They define allowed operations and forbidden operations. If the protocol is well written, the model’s output becomes more predictable. If the protocol is vague, the model starts adding side effects you never asked for.
Validation behaves like a test harness. You check whether the output matches the intent and the protocol. If it doesn’t, you drop it and re‑run. It’s a simple loop, but it keeps the workflow stable.
AI: Execute Inside Boundaries
Once intent and protocol are in place, the model usually behaves better. It writes quickly, stays inside the frame, and doesn’t wander into areas you never asked it to touch. You might still need to adjust tone or phrasing, but the structure tends to hold.
A real example: a sales engineer asked an AI to rewrite a proposal summary. Without a protocol, the model added a discount that didn’t exist. With a protocol, the model stayed inside the approved language and produced something usable on the first pass.
Another example: a compliance team used a protocol to prevent the model from adding interpretations of policy. The output became more predictable, and the review cycle got shorter.
Human: Validate the Output
This is where the loop closes. You look at the result and decide whether it stayed true to the intent and the protocol. If it drifted, you drop it and run the loop again. I’ve noticed that this step is the best way to keep the model from slowly rewriting your workflow over time.
A small example: a recruiter asked the model to rewrite a job description. The intent was clarity. The protocol said to avoid changing requirements. The model followed most of it but softened one qualification. The recruiter caught it, dropped it, and re‑ran the loop. That’s the rhythm.
Protocol as Function: A Deeper Look
Since a protocol behaves like a function, it helps to think about the pieces that make it work.
Input
The human intent. This is the raw material.
Allowed operations
These are the behaviors the model is permitted to use. For example: “Keep the tone steady,” or “Use customer‑friendly language.”
Forbidden operations
These are the rules that prevent drift. For example: “Don’t add commitments,” or “Don’t introduce new requirements.”
Output
The model’s attempt to follow the rules.
Error handling
This is the human validation step. If the output violates the protocol, you drop it.
Boundary conditions
These are the edges where the model tends to wander. You usually discover them over time.
Side‑effect prevention
This is the whole point. You want the model to avoid adding anything that wasn’t part of the intent.
Thinking about protocols this way makes them easier to write and easier to reuse.
Reflection: What I Keep Seeing
I’ve been watching teams adopt The Loop for a while now, and I keep seeing the same pattern. The people who write clear protocols get better results. The people who skip validation end up cleaning up messes later. It’s not that The Loop is complicated. It’s that it forces the model to stay inside the boundaries you actually care about.
I suspect this is why The Loop keeps showing up in teams that want predictable output. It’s simple, but it’s probably the best way to keep AI from rewriting your workflow behind your back.
Why The Loop Works
From what I can tell, drift happens when the model tries to infer intent. Collapse happens when it tries to infer constraints. The Loop removes both by giving the model a clear job and giving the human the final say. It’s not fancy, but it’s reliable.
Mini‑Protocol
A small version you can reuse anywhere:
DEFINE intent
VALIDATE boundaries
CHECK execution
DROP drift
Identity
Humans define intent.
Protocols encode behavior.
AI executes inside boundaries.
Closing Line
AI guesses. The Loop keeps that guess from becoming your problem.



The framework is right in principle. The validation step is where it quietly breaks down at scale. When AI executes across hundreds of lines or thousands of decisions, the human validator is being asked to do the most cognitively expensive part of the loop at a pace the loop was never designed for. Intent is clear. Protocol is defined. But validation assumes the human has the time and context to genuinely compare output against intent. At volume, that assumption doesn’t hold.