Key Takeaways

  • Brooke Lacey avoids ad-hoc prompt corrections by using a lane operating system that isolates individual product environments from global operating instructions.
  • Her architecture isolates project memory and enforces strict write permissions across distinct company products.
  • Active terminal runs track context through dedicated status markdown files (status.md), keeping the agent anchored to current state across tasks.
  • When Claude fails, Lacey forces it to trace the error back to its session hook instead of feeding it the right answer.
  • Every diagnosed session failure ends with Claude writing a patch back to the global operating system spine so the fix survives future terminal runs.

The Method

When Claude misinterprets an instruction, most builders start typing angry corrections into the prompt box. They plead with the model, add three exclamation points, or restate the constraints in slightly different words. It works for five minutes. Then the context window shifts, the fix evaporates, and the model repeats the exact same failure in tomorrow's session.

Claire Vo asked Lacey how she handles this friction: “When he is a disappointment, when he's not doing what you want, how do you prompt him?”

Lacey does not write corrective prompts. She built a lane operating system. Her setup splits work across terminal execution layers, where Claude interacts with system utilities like FFmpeg and Whisper. To keep the model from tripping over itself, she isolates projects into distinct memory lanes with hard boundaries.

“And it has memory lanes,” Lacey explained. “It has like write restrictions and different things cuz I have multiple products within the company. And then the OS lane has its own memory.”

Her debugging loop relies on three rules:

First, isolate product memory with markdown status files. Lacey maintains local status.md files within each project lane. Claude must read this file before it touches files or executes shell commands. The file anchors current project state, preventing the model from guessing what happened earlier in the pipeline.

Second, make the model audit its own session hook. When Claude breaks a workflow, Lacey stops it immediately. She does not supply the missing detail. “The way that I prompt when it screws up is like go back to the way that we started, understand those instructions, and then do it again,” Lacey said. “Go back and figure out where you messed up or where you didn't read. Why didn't you read that?”

Third, push local fixes to the global spine. Once Claude discovers why it bypassed an instruction in the session hook, it has to write that realization somewhere permanent. “Now, go back and tell the main operating system spine that you messed up so that it can make the change globally,” Lacey instructed. The agent modifies the base operating system instructions, embedding the constraint across all future project runs.

Where This Breaks Down

A lane operating system introduces real maintenance drag. If you spend forty minutes structuring directory lanes and permission boundaries for a script you will run twice, you are wasting time.

This framework also creates token bloat. If your agent writes every minor edge-case failure into the global operating spine, your base instructions will grow too long. Models faced with massive system files begin to suffer from instruction decay. They follow the newest patch while dropping the base rules you wrote two weeks earlier. The global spine should capture architectural limits and workflow sequences, not every one-off syntax mistake.

What to Do With This

Open your primary coding project today and add a status.md file to the root directory. List three items: the current project state, the allowed file paths the agent can edit, and the exact command needed to verify code changes.

The next time your coding agent misreads a requirement, do not paste the correct solution into chat. Point the model to status.md, order it to find which instruction it ignored, and command it to update your base system prompt before it writes another line of code.