The question people ask me is: what do you ask the AI? It's the wrong one. A good prompt gives you a good answer, once. The next session, the AI has forgotten everything: your project, your constraints, your rules. What makes an AI reliable over time isn't the magic formula, it's the frame you hand it every single time.
That frame isn't some personal find: structuring the context you give an AI is exactly what the official guides recommend, under the name context engineering. Even the word "harness" isn't mine: Anthropic talks about "harnesses" for framing its agents. I just built my own.
Not a prompt, a system
The harness isn't a file, it's several layers I reuse on every project.
A constitution. Who the AI is to me and how it works: a senior peer, not a yes-man; understand before implementing; explain the why before touching the code; the smallest change that fixes the problem. These rules don't change from one project to the next, so I write them once and for all.
A guardrail on destructive commands. A written instruction, the AI can miss. So the guardrail is mechanical: it isn't allowed to run a delete command, and a hook blocks any rm -rf before it fires. The rest I can fix after the fact; that, I can't. It's the one rail I never leave to plain text.
Context, not generic knowledge. The AI already knows what Terraform is. What it doesn't know is my ground. And that ground, I've split into three.
The triple vault
I split my context into three repositories, because three different things have to stay aligned:
- What I know (knowledge vault): my learning notes, the concepts I've got down. It's the system I described here.
- The frame I work in (context vault): the project, the organization, the decisions and their reasons. The "why" behind a choice, not just the "what".
- The technical stack (code vault): the constraints, what depends on what, what a change might break.
Keeping them separate lets me recombine them: my knowledge, applied to my frame, on my stack. The AI no longer reasons about an average project, it reasons about mine.
Feeding the vault, and keeping it clean
A vault is only worth something if it's alive. Mine is fed and maintained continuously, almost like hygiene. To keep it from becoming a chore, I've automated a few tasks:
- Ingest: turn a source (an article, a decision, an incident) into an atomic note, linked to the rest.
- Recap: a regular summary of what moved, which I adapt to the tool or the topic.
- Audit: a pass that checks the vault's hygiene, spots dead links and notes that have drifted.
These three are only examples. Whenever I want to automate something, I wrap it in a skill, or a simple script the AI runs. Written once, reused after, and along the way it saves tokens: the AI runs the script instead of redoing the whole reasoning every time.
But nothing goes in on autopilot. Every addition goes through a review I approve, like a PR. My rule: a wrong note is worse than no note. Automation feeds the system, the judgment stays mine. Same principle as with code: I delegate the execution, not the validation.
The harness learns from my corrections
This frame isn't fixed, and above all it learns. When I correct the AI, the correction isn't lost: it becomes a rule it keeps. The mistake I called out once, it doesn't make again. Well, usually: it can also turn out stubborn. Over the weeks, it makes fewer and fewer of the errors I've already flagged. The frame tightens from my feedback, without my having to re-explain everything.
Several roles, never the same one approving
On the tasks that matter, I don't orchestrate by hand. I use one agent, but one that leans on different sub-agents: one that designs, one that executes, one that reviews. It's the agent that decides to launch them; I just hand it the keys. With a rule I take from teamwork: whoever produces never approves. The sub-agent that wrote the change isn't the one that approves it, the way a dev doesn't review their own PR. It keeps it from proving itself right, and it catches what a single pass would let slip.
What it taught me
Building this harness forced me to write down what I actually want: my rules, my context, my limits. Half the value is right there, in that clarity. You think you're configuring an AI, you end up clarifying your own way of working.
And it isn't perfect. Some rules I'd set, I don't follow (I'd promised myself spaced-out reviews, I dropped them fast for hands-on practice). The harness isn't a fixed method, it's something I iterate on.
A good prompt gives you a good answer once. A good harness gives you an AI that works the way you want, every time, and that anyone could pick up. Mine is public, if you want to draw from it.