Obedience Is Futile: The Guardrail You Build Against Your Own Limited Context Window

Part 6 of Building My Agentic Workflow in Public. Part 5 settled which engine runs my loop. This one is about a different bottleneck, and it is not in the machine. It is in my chair.

Way back in Part 0 I said the bottleneck in all of this is human. You can spin up two hundred agents, but you cannot keep up with two hundred agents, because your attention does not scale the way agent count does. That was the first face of the limit. This post is about the second face, and it is quieter and more dangerous: my context window.

The question I could not answer

Here is the shape of the problem. I run one of my own commands, something like “design the architecture for this module,” and it points at a folder with five spec files in it. Each file is around four hundred lines. The agent reads all two thousand lines, holds every one of them, and finds a real contradiction buried in two or three of them. Then it stops and asks me.

The question comes back looking like this: “C from use case blah needs one two three, and it conflicts with the logging rule. What do you think?”

And I am stuck. Not because I am slow, and not because I never understood the material. I wrote those specs. But I wrote them weeks ago, and I have since run the whole flow from Part 1 to Part 5 without holding any of it in my head. I do not remember which file that rule is in. I do not remember what “C” refers to. I cannot see the two lines out of two thousand that the question is actually about. The agent has all of that context. I have almost none of it.

Why I cave, and why that is the real bug

So what did I do with that question? I accepted the recommendation. Of course I did. The alternative was to stop the whole session, open five files, hunt for the two relevant lines, re-read enough of the surrounding specs to understand the conflict, and only then form an opinion. That is ten or fifteen minutes of work for one question, and there are five more behind it.

This is the failure, and it is worth being precise about where it lives. The failure is on my side. My brain has a small context window and the agent has an enormous one, and when the question assumes I can hold what it holds, I cannot, so I default to yes. The record then says I decided. I did not decide. I waved it through.

That is not a small thing. When I stop actually deciding, I am no longer in the loop, and the design starts drifting away from what I intended, one accepted recommendation at a time. Not with a bang. Just a slow slide where the thing being built stops being the thing I meant to build, and I signed off on every step of the drift without ever really seeing it.

To be clear, the agent is usually not doing anything wrong here, and it is almost never doing anything malicious. It could be, and that matters more as these systems get more capable, but that is a different guardrail for a later post. The danger I am describing happens even when the agent is perfectly well behaved. I hand away the decision simply because I cannot hold the context to keep it.

Trust, but verify, especially yourself

The instinct the whole industry pushes is to trust the model and move fast. I think the correct posture is the old one: trust, but verify. Not obedience. And the thing I most need to verify against is not the agent. It is my own limitation.

I know my context window is small. That is not a maybe. So I have to build a guardrail around that known weakness, or it will quietly steer everything I make. This is where the framing clicked for me. A workflow that lets a human rubber-stamp what they cannot see is not really a workflow with a human in the loop. It just looks like one.

So I stopped thinking of this as a workflow and started thinking of it as a guarded workflow. The guard is not mainly against the machine. It is against me, against the very human urge to cave to a limitation instead of engineering around it. This is the first of several guardrails I want to write about. It happens to be the foundational one, because it is the one that keeps me genuinely in the loop at all.

The fix: make every question carry its own context

The guardrail itself is simple, almost dumb. If I cannot hold the context, the question has to bring the context to me. Every decision question my tools ask now has to be self-contained: everything I need to rule on it lives inside the question, not in the prose scrolling by above it.

I wrote that down as a fixed format. Six blocks, every time.

Where you are
  The command and argument as I typed it, the agent/phase, the step,
  and the file about to change.
Sources
  file §section Lline
    "the load-bearing line, quoted verbatim, never paraphrased"
What breaks
  the concrete mechanism of the failure, not its category
  Example:
    real paths, calls, or output showing the symptom
Recommend
  the choice and a one-line why; the alternative and what it costs
Confidence
  High = mechanical, safe to accept. Low = what deserves my eyes.

The load-bearing block is Sources. It is not enough to say “the spec requires this.” The question has to name the file, the section, the exact line number, and quote the line verbatim, so I can verify it in one jump instead of a ten-minute hunt. A section name alone still sends me searching, and searching mid-interview is exactly when I give up and accept. A paraphrase is worse, because a summary is the very thing I am being asked to check.

Here is the same kind of question, rebuilt to the format:

The other quiet killer is labels. A question that says “C3 turned out better than expected” means nothing to me, because C3 was a handle the agent coined three messages ago, or inside a sub-agent I never saw. So the rule is: expand every label at first use, every time.

Making it actually stick

Writing a format down does not make anything follow it. I have watched myself write good instructions and then watched the model quietly ignore them under pressure. So this guardrail has three layers, weakest to strongest.

The first layer is the format document itself, referenced by the commands that interview me. The second is a single line in my global config that applies to every session and every project, including questions asked as plain prose. The third is the one with teeth: a hook.

The hook fires right before the agent is allowed to ask me a structured question. It reads the question, checks that all the blocks are there and that Sources actually cites a line number, and if anything is missing it blocks the question and tells the model to rewrite it instead of putting it in front of me. It fails open on purpose: if anything about it breaks, it gets out of the way rather than wedging my session.

#!/bin/bash
# PreToolUse hook wired to AskUserQuestion.
set -uo pipefail
REQUIRED=("Where you are" "Sources" "What breaks" "Recommend" "Confidence")
payload=$(cat) || exit 0
[ -z "$payload" ] && exit 0
command -v jq >/dev/null || exit 0
tool=$(jq -r '.tool_name' <<< "$payload")
# Only ever act on AskUserQuestion; wave everything else through.
[ "$tool" != "AskUserQuestion" ] && exit 0
count=$(jq -r '.tool_input.questions | length' <<< "$payload")
missing=()
# Validate each question on its own.
for ((i=0; i<count; i++)); do
  q=$(jq -r ".tool_input.questions[$i].question" <<< "$payload")
  for block in "${REQUIRED[@]}"; do
    grep -qi -- "$block" <<< "$q" || missing+=("$block")
  done
  # Sources must cite a line number unless it is explicitly "none".
  if grep -qi "Sources" <<< "$q" && ! grep -qiE "Sources.{0,40}none" <<< "$q"; then
    grep -qE "\bL[0-9]+" <<< "$q" || missing+=("line number L<n>")
  fi
done
# Nothing missing, allow. Something missing, block (exit 2) and say why.
[ ${#missing[@]} -eq 0 ] && exit 0
echo "BLOCKED: question not self-contained. Missing: ${missing[*]}" >&2
exit 2

I also wired the same rule into the parts of my toolkit that ask the most questions: the one that designs a solution, the one that writes the contract, and the one that breaks work into features. One sentence each, pointing at the same format, so the heaviest interviewers all ask the same way.

Where this leaves the series

Part 0 said the bottleneck is human and pointed at attention. This post points at the other half: context. Both are limits I cannot wish away, so both need guarding, not willpower.

That is the real idea here, bigger than one format or one hook. The goal is not to approve everything, and it is not to drop out of the loop. It is to stay in the loop only for the decisions that actually need me, and only in a form I can judge in a minute. Getting there is not about trusting the machine more. It is about being honest that I am the weak link in specific, predictable ways, and building guards around exactly those.

More guardrails to come. This one had to be first, because without it I am not really deciding anything. I am just signing.

If you have felt this, the question you could not answer so you clicked approve and moved on, I would like to hear how you handle it. Mine is one guardrail against one limit, and I know I am not the only one hitting it.