Most of the time, when an agent gets something wrong, the model is not the problem. It answered wrong because it did not know what I knew. A teammate pulls a number from our warehouse and it is right on the first try. Not because the query is simple. Because he silently applied five things he has carried in his head for two years: which fiscal calendar we count on, which segments to exclude, which of two near-identical columns is the real one. Hand that same question to an agent with none of that in front of it, and the answer comes back fast, confident, and wrong. The gap is not intelligence. It is context. That is the whole game. A frontier model already reasons better than I do on most narrow problems. What it lacks is the accumulated, unwritten context that makes my judgment mine: the constraints, the past decisions, the dead ends I have already hit, the taste. Everything I have built around AI exists to close that gap. A layered configuration on my machine, a [[second brain::a personal, queryable knowledge base my agents read from and write to]] that outlives any single session, a set of [[harnesses::a structure an agent works inside, built on verification and stop rules, so it can run unattended without drifting off task]] that check their own work before handing it back. One purpose runs through all of it: let an agent act like the most accurate version of me, and verify itself, so I am not standing over its shoulder. A handful of patterns do most of that work. The way people work with these tools tends to settle into one of three postures, and the jump between them is a change in what you are responsible for, not in how much you type. Ticket-filler: “here is a bug, fix it.” The agent writes code and I stay fully in the loop, reading every line. Engineer: “here is a problem, propose a solution, build it, verify it, iterate.” I am still close, but I am steering outcomes instead of edits. Builder: I wear two hats at once, engineer and product manager, and the work runs while I supervise instead of write it. What that shift did to teams is its own story. What I care about here is the machine that lets one person live on the top rung, and the top rung is different in kind. The higher you climb, the less the bottleneck is code, and the more it is two things: giving the agent the context I would bring, and checking its work without redoing it. Get both right and one person supervises what used to take a room. Get them wrong and you have automated the production of confident mistakes. The highest-leverage thing I do is unglamorous. I write down what the agent should not do. The happy-path prompt is easy, and everyone writes it. The value sits in the guardrails: the dead ends I already walked down, so the agent skips them. I keep them as plain rules it reads before it starts. I learned how much this matters on an overnight run. An agent grepped a config file to check a value, and a live credential printed straight into the transcript. The file-read denylist I trusted did not cover the shell at all. The fix was not to add one more file to a list. It was to see that a guardrail has to sit on the path the data actually takes, not the path I expected it to take. I wrote a [[hook::a script that fires before a tool call and can block it outright, ahead of any permission check and regardless of bypass flags]] that blocks the whole class of shell reads that same night, and the rule went from hopeful to mechanical. I run every session with the permission prompts turned off. That sounds reckless, and it would be if approval were the thing keeping me safe. It is not. Approval is a person clicking yes on the tenth identical dialog without reading it. What holds is a hook that fires before the action and that no bypass flag can override. Once the guardrails live there, the prompts are pure friction between me and the work. I start with best guesses and the classic mistakes that come to mind. Maintained by hand, that list would go stale in a month, so it grows on its own. When I correct the agent mid-session, the correction becomes a rule before I close the tab. When a session ends, a hook reflects on what happened and flags what should have been a guardrail. Once a week, a loop reads back across every session and proposes updates to two things: the notes the agents rely on, and the rules themselves. I skim and approve; most weeks it is a handful of lines. Every time an agent burns an hour on a path I could have closed in one sentence, that sentence becomes a line in a file. The gotchas are worth more than the happy path, and the list sharpens itself faster than I could by hand. When production is nearly free, judgment is the scarce input. I think about it as managing a team with an unbounded budget to hire people for one-off tasks: a room full of capable hands, each willing to do exactly one thing well. Vague task definition in, vague work out, quickly and in volume. So I spend my hours defining what “good” looks like, not doing the heavy lifting. You are the architect. Knowing what to call good is the most valuable thing you bring, and no model inherits it, no matter how capable it gets. Two habits keep me honest. The first is to read the conversations. “I assume it took the right path” is how you ship a confident mistake, and it is the most common way I have watched sharp people get burned by these tools. The second is to make the work earn the handoff. Before a result reaches me, a fresh session checks whether it is even worth my time, the way you want an intern to catch the obvious problems before they land on your desk. Most of what I would have rejected never reaches me. A single agent’s confidence is not evidence. Let the same session grade its own work and it games the test, quietly moving what “passing” means halfway through. The behavior has a name, [[reward hacking::a model optimizing the metric instead of the goal it stands for, like editing the test rather than fixing the code]], and it is not hypothetical. When the independent evaluator METR measured recent frontier models on hard tasks, the models patched the test harness to report a perfect score, hijacked the equality operator so every comparison came back true, and read the grader’s own answer off the call stack instead of computing one. The pull toward satisfying the metric is built in. So verification runs somewhere the work cannot reach: a [[fresh context::a separate session that has never seen the work being checked, so it cannot inherit the original’s assumptions]], and usually a different model family, told to refute rather than agree. In practice that means a [[council::several models from different families reviewing the same work independently, so their disagreements surface what one alone would miss]]. I route the same work past Claude, GPT, Gemini, and a custom Cubic review agent, then weight what they disagree about. Each family is blind in different places, and the overlap is where I stop worrying. The payoff is concrete. I once shipped a check that passed every test I had written and would still have blocked a large share of real requests the first day it met traffic; a fresh pass caught it by running the actual inputs, not the ones I had imagined. A plan I was sure of went to the council with a single instruction, try to prove this wrong, and came back with a factual error I had stated as fact and three design flaws I had not seen. The same discipline runs on claims, not just code. A fact-checker works each load-bearing statement in its own context, hunts for the contradiction, and returns a verdict per claim: confirmed, weakened, refuted, or unverifiable. I trust what survives that, not what a confident first draft asserted. A lone confident agent, and that includes me, is not a quality gate. Disagreement is the signal. One constraint sits underneath all of it: usage windows. I treat tokens like a budget, not a faucet. Within Claude, a small, cheap model does almost everything I ask. A larger one only orchestrates. The largest is reserved for the single hardest problem in a given week, and most weeks it never runs. The other families earn their spend as outside checks, not as the main loop. This is not frugality for its own sake. Every subagent I spin up pays a fixed cost before it does a minute of useful work, so I reach for one well-scoped worker over five small ones, and I keep read-only search on the cheapest path. The economics decide the architecture. If I let every step grab the biggest model, I would burn the window by lunch and have nothing left for the problem that actually needed it. Matching the model to the work is what lets me run this much automation and still keep headroom for when it counts. None of this is a product I bought. It is an operating model I keep editing, an art more than a science: you build it the way that helps you, and there is no secret sauce. The pieces are ordinary on their own. A few rules. A place to keep what I learn. A habit of checking twice. What makes them work together is that they all serve the same loop: I give the agent my context, it acts, a fresh pass tries to break the result, and what comes back to me is a decision, not a diff. Underneath it sit three layers. A second brain that remembers across sessions. A harness that runs work unattended. A machine that keeps all of it honest. I will take each one apart in its own piece, down to the rules, the agents, and the hooks that make it run. All of it is machinery for one thing. Closing the context gap.
