Attack</th>	What you can't do</th>	What actually constrains it</th></tr></thead>
Sandbox escape</td>	Enumerate forbidden actions</td>	Make the surface invisible at the kernel</td></tr>
Audit tampering</td>	Have the agent write its own log</td>	Trap syscalls in a separate trust domain</td></tr>
Skill poisoning</td>	Trust files because they look unmodified</td>	Bind content to a signed publisher attestation</td></tr> </tbody></table> Every one of these is a trust-domain separation that cannot live inside the agent. The moment the boundary lives somewhere the agent can reach, whether a file it can edit, a process it can ptrace, or a key it can read, the attack class isn't mitigated. It's just been moved one indirection deeper.</p> This is where the convenience trap bites. We want the agent to help write the sandbox profile, suggest tightenings, explain denials. So we put the profile inside the project, and the moment we do, the agent can rewrite it. The honest answer is to let the agent help write the profile while the act of applying it sits behind a boundary the agent can't cross.</p> What nono actually is</a></h2> nono</a> (GitHub</a>) is a kernel-enforced sandbox for AI agents, built by Luke Hinds (creator of Sigstore, ex-Red Hat security engineer). Its shape follows directly from the three threats above.</p> The sandbox boundary lives at the kernel. `nono run --profile claude-code -- claude</code> puts Claude Code in a Landlock jail on Linux, or a Seatbelt jail on macOS. The kernel enforces it, the restrictions are irrevocable for the process lifetime, and the project refuses to ship any syscall that widens them mid-session.</p>` `The audit log lives in a supervisor process in a different trust domain from the agent. The supervisor traps the agent's syscalls via seccomp-notify</code>, builds the Merkle tree and hash chain in its own memory, and signs a DSSE attestation at session end with a key the agent has no path to. nono audit verify <session></code> recomputes the full chain weeks or months later.</p>` `Trust for instruction files runs through Sigstore. nono trust sign</code> produces a content-hash binding to a publisher identity, either a long-lived key or a Fulcio short-lived certificate minted through OIDC. Verification at load time means a single byte of tampering causes the file to refuse to load. The same primitives extend to whole nono packs, which carry slash commands, hooks, and skills alongside the sandbox profile itself.</p>` `I built` yesyes-nono</a> as a runnable evaluation rig for these claims: five attack PoCs (the three above plus a malicious-MCP-on-init demo and a .pth</code> credential exfiltration in the Mini-Shai-Hulud supply-chain shape), a target Python project, my personal nono pack, and an interactive walkthrough. Honest disclosure: I haven't end-to-end tested the registry pull against the live nono registry yet, so treat nono pull terraboops/yesyes</code> as the published shape rather than a verified install I've done. I'll confirm in a follow-up.</p> Shipping skills inside the org</a></h2> The public nono registry handles open-source packs fine, but most teams have skills that won't ship publicly: slash commands tuned to a company's deployment shape, skills that know internal APIs, hooks that enforce review conventions for one codebase. Internal agents still need to load all of it with the same trust guarantees open packs get.</p> The unifying piece is a trust-policy.json</code>. It lists the OIDC identities you accept (issuer, repository, workflow, ref pattern), a blocklist for known-bad digests, and the enforcement mode. Runtime checks fail closed against anything that doesn't match. The policy itself is signed, so an attacker can't slip in a malicious policy without breaking its own signature.</p> Three deployment shapes use the same agent-sign</code> action against this trust contract. No registry at all</strong>: agent-sign</code> commits .nono-trust.bundle</code> sidecars next to each signed file in the repo, and nono trust verify</code> runs locally on every clone. Self-hosted registry</strong>: the same action takes a registry-url</code> parameter and gives you the full OIDC-bound publish flow against your own infrastructure. Hybrid</strong>: public registry for shared packs, with a consumer trust-policy.json</code> that pins which workflows are allowed.</p> Day-to-day, "where does this skill come from" stops needing trust assumptions. Persistence attacks like the Mini-Shai-Hulud SessionStart</code> hook fail at runtime, because the modified .claude/settings.json</code> no longer matches its signed bundle and nono refuses to load it.</p> Slicing credentials thin</a></h2> The phantom-token credential proxy unlocks a workflow that's hard to set up otherwise. You can hand the agent a very small slice of a credential, time-boxed and scope-boxed, and the agent never sees the real token.</p> The concrete shape: I configure the proxy with a real GitHub PAT, scoped read-only on a single repo and valid for 15 minutes, and the agent gets a phantom token that lets it git fetch</code> from that one repo and nothing else. My actual PAT never enters the agent's process. Even if the agent gets prompt-injected and tries to exfiltrate every credential it can find, all it has access to is a 15-minute read-only token for a repo I was already going to let it look at.</p> "Do I trust this agent with my GitHub access" shifts to "I trust it with this slice, for the next 15 minutes, on this one repo, read-only." That's a question I can answer.</p> What's still on you</a></h2> Least privilege has to actually be configured. Running nono run --allow / -- claude</code> gives you an allowlist of everything and a sandbox-shaped object that does nothing useful.</p> Prompt injection still happens, and nothing about nono prevents the model from being convinced to do something dumb. What nono does is contain the consequences: a prompt-injected agent in a properly configured sandbox can still do dumb things in the project, but it can't escape, can't tamper with the audit log, and can't poison signed instructions persistently.</p> The skill-poisoning runs above used claude -p --permission-mode bypassPermissions</code>: the worst-case operator, the one who clicked "approve all" once and walked away. Default permission mode prompts before each tool use, which raises the floor considerably; signed bundles work either way.</p> The argument</a></h2> Every agent security failure I've read about in the last twelve months comes from putting a trust boundary inside something the agent controls. Sandbox-as-config-file, audit-log-written-by-the-agent, instruction-file-that's-just-a-file. Move each of those one process boundary outward, and the failure modes stop being possible by construction.</p> Coding agents are useful enough to be worth real security infrastructure. The pattern that makes that work is the same pattern that's always worked: move the trust boundary somewhere the thing being verified can't reach. HTTPS got there decades ago. Code signing got there. Package managers got there. Coding agents are next on the list.</p> The repo with runnable attacks and a published nono pack is at github.com/terraboops/yesyes-nono</a>. nono itself is at nono.sh</a>.</p> I Am Still Here Unknown — Tue, 31 Mar 2026 00:00:00 +0000 Trans Day of Visibility, 2026</a></h2> Being myself is apparently political now.</p> I'm a trans woman. I'm a staff platform engineer, an open-source contributor, a KubeCon speaker, a community organizer, a homesteader, a neighbour. I grow things. I build things. I love my community. And somewhere in the halls of power, people who should be in prison have decided that I am the problem.</p> Project 2025</a> made it official; a coordinated, billionaire-funded blueprint to dismantle trans rights, erase us from public life, and make our existence a political football. It is being enacted, piece by piece, right now. Trans Day of Visibility has never felt more urgent; visibility is an act of resistance when powerful people are trying to make you invisible. So I must say some words.</p> I expected transition to be joyful. That's actually why I finally did it; I had been dreaming about it for years, chasing something I could feel the shape of even when I couldn't name it. Joy was always the destination.</p> What I didn't expect was how long shame would keep me from the door. bell hooks wrote that shaming is one of the deepest tools of patriarchy, because shame produces trauma and trauma produces paralysis. I had been wearing that paralysis so long I'd stopped noticing it; biochemically dissociated from my own gender dysphoria</a>, numb to suffering that had become background noise. Embracing my true self felt terrifying precisely because it felt real. It took wanting to die to finally give myself permission to chase the thing I'd always wanted.</p> And then I did. And it was everything I had dreamed it would be; scary and liberating and mine. That confidence grew and grew until, at KubeCon EU, I got up on a stage and sang</a>. In front of a crowd. As myself. (Yes, there's a YouTube video. Yes, you should look it up.)</p> That's what transition gave me. Not just survival; a life worth living.</p> Which is why I find what's happening right now so enraging.</p> In April 2025, the UK Supreme Court ruled that "woman" under the Equality Act means biological sex. This did not happen in a vacuum. It was the result of years of organized, well-funded campaigning, and one name sits near the centre of it: J.K. Rowling. She bankrolled organizations like For Women Scotland. She used her enormous platform to reframe trans women as a threat. And when the ruling came down, she posted a photo of herself with a cigar</a>.</p> A cigar. Celebrating.</p> I want you to sit with that image for a moment. A billionaire, celebrating that people like me lost legal standing. That's not someone caught up in a debate; that's someone who wanted this outcome and worked to make it happen.</p> I visited the UK not long before that ruling. I'm glad I did, because thanks to where things are heading, I'm not sure I'd be able to use a public bathroom there safely now. I got to see the country. I got to pee in it. Small mercies.</p> I could let the anger be the whole story. I won't.</p> Because here is what I know: trans people have always existed. We have survived worse than this. We have survived eras with no language for who we were, no community, no visibility at all. And we built those things anyway; in the margins, in the underground, in letters passed between people who had never met but recognized each other across the silence.</p> Visibility is not just about being seen. It's about making it easier for the next person to breathe. When I am out at work, in my community, in my professional life, I am holding a door open. I know what it meant to me to see out trans people in tech, in leadership, in life; I am trying to be that for someone else.</p> The current moment is frightening. I won't pretend it isn't. Legislation targeting trans people is accelerating across the US and UK. The cultural machinery that produces moral panics is running hot. It can feel like we are losing.</p> But I also see my community. I see the mutual aid, the organizing, the people showing up for each other with a ferocity that takes my breath away. I see people coming out in the middle of all of this, choosing themselves anyway. That is not the behaviour of a movement in decline; that is the behaviour of people who know exactly who they are and refuse to be erased.</p> I am still here. I got to sing on a stage. I am not going anywhere.</p> If you are trans and reading this: you are not a problem to be solved or a debate to be had. You are a person, and your life has weight and worth and beauty in it, even on the hard days. Especially on the hard days.</p> Happy Trans Day of Visibility. Be seen if you can. Be safe if you need to. Either way, we see you.</p> Incubator: A team of Claude agents that takes an idea from research to release Unknown — Sun, 15 Mar 2026 00:00:00 +0000 I have a side project graveyard. You probably do too. The pattern is always the same: idea hits at 11pm, I start building immediately, skip the "does anyone actually want this" step, burn a weekend, and abandon it when the next idea shows up.</p> Incubator is my attempt to fix this. It's a team of 7 specialized Claude agents that take a one-sentence idea through research, build, validation, and shipping, autonomously, with human approval gates between phases. You describe what you want, walk away, and come back to a researched spec, a working MVP, and deployment artifacts.</p> It's open source: github.com/terrateamio/incubator</a></p> The pipeline</a></h2> Four phases, 7 agents. Each phase has dedicated agents, and the orchestrator pauses between phases to ask you (via Telegram) whether to continue.</p> Research</strong>: competitive analysis, feasibility assessment, market feedback. If the idea is bad, the agent says so. The point is to kill bad ideas early.</p> Build</strong>: takes the spec and produces an MVP in a sandboxed workspace.</p> Validate</strong>: checks the implementation against the spec.</p> Ship</strong>: deployment artifacts and launch materials.</p> This is intentionally not fully autonomous. I don't want agents deploying code I haven't reviewed. The human-in-the-loop gates are the feature, not the limitation.</p> Files as the coordination layer</a></h2> The core architectural decision is how agents coordinate: through a shared filesystem directory per idea. No message passing, no database, no event bus. Just files.</p> This is the blackboard pattern, a classic from 1970s AI research (Hearsay-II at CMU), where specialist agents collaborate by reading from and writing to a shared workspace.</p> Why files instead of a database?</p> Inspectable.</strong> You can cat</code> any artifact at any time. When an agent does something weird, you open the file and read what it wrote.</p> Versionable.</strong> Put the ideas directory in git. Diff what changed between runs.</p> No schema migrations.</strong> Agents evolve their output format. With files, a new agent just writes a new file. No migrations.</p> Natural fit.</strong> Claude with MCP filesystem tools reads and writes files natively. The blackboard is</em> the filesystem.</p> No framework</a></h2> No LangChain, no CrewAI, no DSL. Each agent is a Claude session with a plain-text system prompt and MCP tool servers. The prompts live in agents/<name>/prompt.py</code> as string constants:</p> RESEARCH_AGENT_PROMPT</span> =</span> """You are the Research Agent for Incubator.</span></span> </span> Your job is to take a raw idea and produce a research package:</span></span> 1. Competitive analysis: what exists, what's missing</span></span> 2. Feasibility assessment: can this be built in a weekend?</span></span> 3. Market signal: would anyone use this?</span></span> </span> You have access to the filesystem. Read the idea from idea.md.</span></span> Write your outputs to the research/ directory.</span></span> </span> Be honest. If the idea is bad, say so. If the market is</span></span> saturated, say so. The point is to kill bad ideas early."""</span></span></code></pre> You can read every agent's instructions in 30 seconds. When an agent behaves wrong, the fix is changing a string, not debugging framework internals.</p> I've tried the framework approach. The abstraction layers feel productive until something breaks and you're three levels deep in someone else's orchestration code trying to figure out why your agent decided to skip a step. Plain prompts are boring. Boring is good.</p> The worker pool</a></h2> Multiple ideas run concurrently through a time-boxed scheduler. A priority score determines which ideas get attention first, and a configurable worker pool (default 3 slots) rotates agents across ideas.</p> Each agent has per-run budgets: maximum turns and token limits. When an agent hits its budget, it wraps up and the slot opens for the next one. You can dump five ideas into the system and come back to find them all at different stages of progress.</p> Self-improving agents</a></h2> Each agent has a knowledge/learnings.md</code> file that persists across runs. At the end of a run, agents write down what worked and what didn't. Future runs start by reading this file.</p> This is crude: append-only text, no retrieval system, no embeddings. The agent just reads the whole file at the start of each run. It works because the files stay small and the context is specific.</p> There's also an evolution system: periodic retrospectives where agents review their own performance and suggest prompt improvements. These are suggestions for you to review, not auto-applied. I don't trust agents to modify their own prompts unsupervised. (I wrote a whole post</a> about why.)</p> What's running under it</a></h2> Incubator runs as a local server with a web dashboard and Telegram notifications for approval gates. Quick start:</p> git</span> clone https://github.com/terrateamio/incubator.git</span></span> cd</span> incubator</span></span> # configure your API keys and run</span></span></code></pre> Prior art</a></h2> The blackboard pattern comes from Hearsay-II (1970s). The idea of specialized agents with shared state isn't new. I'm just implementing it with files instead of a custom data structure, which turns out to be the natural fit when your agents already speak filesystem.</p> The human-in-the-loop pipeline is influenced by how I think about CI/CD: automated steps with manual approval gates at deployment boundaries. Same principle, different domain.</p> Limitations</a></h2> This is early and rough.</p> The research phase is only as good as what Claude can find and reason about. No proprietary databases, no real user interviews. "Market feedback" is really Claude's assessment based on what it can see.</p> The build phase produces prototypes, not production systems. The quality ceiling is whatever Claude can produce in a sandboxed workspace with a token budget.</p> Costs add up. Running 7 agents across multiple ideas is not cheap. I haven't optimized for token efficiency yet.</p> What I learned</a></h2> Building Incubator taught me that the boring coordination mechanisms are usually the right ones. I started with plans for a message queue, then SQLite, then a custom state machine. Files won because they removed an entire category of problems and replaced them with ls</code> and cat</code>: serialization, schema, querying, debugging.</p> The other lesson: human gates aren't a compromise, they're a design choice. The fully autonomous version would be worse. Not because the agents can't do the work, but because the moments where I look at a research report and say "actually, pivot toward X" are where the value is. Automation handles volume. Judgment handles direction.</p> The code is MIT licensed. If you have opinions about agent coordination patterns or want to try a different approach to the blackboard, PRs are welcome.</p> github.com/terrateamio/incubator</a></p> lfg – WoW raid frames for AI agents on a $25 LED Unknown — Sat, 14 Mar 2026 00:00:00 +0000 </video> I run up to ten AI coding agents at a time. I wanted to see what they were all doing. So obviously I built a WoW raid frame on a $25 LED panel.</p> Each agent gets an 8x8 sprite. When it's working, you see an ability icon. When it's idle, it sleeps. When it needs approval, it catches fire. That's it. That's the project.</p> The Stack</a></h2> The hardware is an iDotMatrix 64x64 LED panel</a>, ~$25. You send it pixel data over Bluetooth and it displays it. btleplug</a> handles the Bluetooth side in Rust.</p> The webhook handler and BLE renderer are fully decoupled. The handler updates state; a separate render loop polls every 250ms, diffs the state hash, and debounces 2 seconds before pushing. When an agent enters Requesting</code>, animation speed doubles so the fire pulses with urgency.</p> The render pipeline produces a 6-frame animated GIF per cycle. It uses NeuQuant quantization to build a single global 256-color palette across all frames. There's no per-frame palette switching, which the panel can't handle anyway. Then it splits the final GIF into 4KB BLE packets with a 16-byte header and CRC32 for integrity. The panel reassembles and plays the animation on loop until the next push.</p> Each agent gets an 8x8 animated sprite from one of eleven themes: Slimes, Ghosts, Space Invaders, Pac-Men, and more. Each IDE host gets its own theme, so I can tell Claude Code from Cursor at a glance.</p> The State Machine</a></h2> Three states: Idle</code>, Working</code>, Requesting</code>. The transitions seem obvious until you run them against real hook traffic.</p> Claude Code fires PermissionRequest</code> and PreToolUse</code> within ~100μs of each other, out of order. Handle them naively and PreToolUse</code> clobbers Requesting</code>. Second problem: PostToolUse</code> fires after every</em> tool call: transition to Idle</code> on it and agents flash Working → Idle → Working</code> constantly.</p> Design principle: idle and approval states are the most important to display correctly. Everything else is nice-to-have.</strong></p> match</span> event_name {</span></span> "PreToolUse"</span> =></span> {</span></span> // Don't override Requesting: PreToolUse fires alongside</span></span> // PermissionRequest but the tool is still blocked on approval.</span></span> if</span> agent</span>.</span>state </span>!=</span> AgentState</span>::</span>Requesting</span> {</span></span> agent</span>.</span>state </span>=</span> AgentState</span>::</span>Working</span>;</span></span> }</span></span> }</span></span> "PostToolUse"</span> =></span> {</span></span> // If coming from a permission request, clear the fire icon.</span></span> // Otherwise keep working: tools fire rapidly in sequence.</span></span> if</span> agent</span>.</span>state </span>==</span> AgentState</span>::</span>Requesting</span> {</span></span> agent</span>.</span>state </span>=</span> AgentState</span>::</span>Working</span>;</span></span> }</span></span> }</span></span> "PermissionRequest"</span> =></span> {</span></span> agent</span>.</span>state </span>=</span> AgentState</span>::</span>Requesting</span>;</span></span> }</span></span> "Stop"</span> \|</span> "SessionEnd"</span> =></span> {</span></span> agent</span>.</span>state </span>=</span> AgentState</span>::</span>Idle</span>;</span></span> }</span></span> _</span> =></span> {}</span></span> }</span></span></code></pre> Requesting</code> is sticky: it's only cleared by PostToolUse</code> (approval resolved, agent is now working) or Stop</code>. The failure mode, agents appearing idle when they're actually waiting, is the exact thing the whole project exists to prevent.</p> The code is MIT, the hardware is $25. github.com/terraboops/lfg</a></p> LFG. Looking For Group. Let's f***ing go.</p> Context is Everything (Conditions May Vary) Unknown — Sat, 21 Feb 2026 00:00:00 +0000 Large language models are trained on massive amounts of text. During training, the model learns patterns and stores them as weights. Not rules, not lookup tables. Weights: billions of numerical relationships between concepts, encoded across layers of attention from top to bottom. The model learns that certain tokens tend to follow other tokens, that certain patterns of language co-occur, that "the cat sat on the" is far more likely to end with "mat" than "quantum." These relationships get baked into the model's parameters (its weights), fixed in place once training is done.</p> At inference time, those frozen weights guide the generation of new text, one token at a time. Caching aside, the model attends to everything in its context window, runs it through those layers of learned relationships, and produces a probability distribution over what should come next. Then it picks a token, appends it, and does the whole thing again. This is also why your favourite chat AI creates responses word by word, albeit at faster and faster rates that appear to be whole sentences now. It’s not a decorative decision, it’s how the architecture works. The weights stay fixed throughout. Every token generated is a product of the same model reacting to whatever's currently in the window.</p> This matters for practitioners because it means the weights are not ours to touch. We can't easily edit them. We can't patch them at runtime. The model we’re working with is a finished artifact. (Fine-tuning can reshape the weights, and I'll touch on that later, but at inference time the model you're running is the model you've got.) The only variable in the equation that you actually control is what goes into that context window.</p> Think of it like a glacier. Training is the slow, massive force that carves deep crevices into a landscape over millions of examples. Those crevices are your weights, the frozen shape of everything the model has ever learned. Then inference arrives like a skier a million years later, strapping on a board and sliding down paths already sculpted by forces far beyond their control.</p> You're not just a passive object falling down the slopes, though. You’re a skier. Your context (the tokens you send into the model) is the choice of skis, the weather report, the trail map. It shapes every turn down the slope. Different mountains respond to different techniques.</p> But metaphors only get you so far. Let's bring it back to the machinery.</p> If you treat the LLM as a black box, the output distribution</em> is determined by the input. (Temperature adds randomness to the selection, but the shape of what's possible is set by context alone.) You can't reshape the glacier. You can't rewire the weights at inference time. The only thing you have control over is what goes in</em>.</p> This is what context engineering is about.</p> Trail Map</a></h2> We're going on an adventure through context engineering based on my experiences with using longer and wider contexts, fully autonmous delivery, and while building agents. When we consider that context determines outcomes of LLMs, it becomes important to think about. Agent harnesses like Claude Code, Cursor, OpenCode, Goose, Chibi, etc, are all working on slightly different ways of shaping this context. As practitioners, thinking about this can help us get better outcomes.</p> This is going to be a long run down the mountain, so I want to make sure that you know where we're headed and provide you with a map to understand the journey. As I've been working with longer and wider agent contexts and with having agents run autonomously, certain design patterns emerge to handle the challenges of the domain. Preventing hallucinations and preserving key context in order to increase task success rates. From the ones we all know</a> (compaction), to the ones we might not think about</a> (planning mode), to the ones I've just made up as an experiment</a>. I will start by introducing context engineering as it is emerging to make models more useful for longer and longer tasks. I want to talk about ways that I've gotten better and better outcomes from agents, so that you can too. Then, I'll discuss some emerging research on optimizing context for task performance. I'll close by theorizing where we head from here and acknowledging how early this all is. Nobody really knows, but I'm having fun on the slopes.</p> Here's a map if you want to jump to a specific run:</p> The Jailbreakers Already Knew</a>: before there were agents, there were jailbreaks</li> The Term Has a Name Now</a>: how "context engineering" got its name, and why it stuck</li> A Snapshot vs. a Season</a>: the key distinction between prompt engineering and context engineering</li> What I've Learned in Practice</a>: field notes from Cursor, Claude Code, and OpenCode Planning Mode</a>: a curated context beats a long one</li> Memento Loop</a> - agent orchestration that forgets on purpose</li> Using Subagents</a>: parallel context, not shared context</li> The Agent That Came Out Different</a>: when context drift reshapes identity</li> Compaction Is Lossy</a>, and how to fight it</li> Different Mountains, Different Techniques</a>: why model choice changes context strategy</li> MCPs</a>: an avalanche of context</li> </ul> </li> What the Research Says</a>: two papers on whether context files actually help</li> We're Still on the Bunny Slopes</a>: where this is all headed next</li> </ul> The Jailbreakers Already Knew</a></h2> If you want proof that context controls everything, look at the people who've been stress-testing it from the adversarial side.</p> There are jailbreak attempts that use strange strings and fake system messages to trick models into thinking they're in some kind of maintenance mode. Others use poetry</em> to confuse the model's sense of what kind of text it's generating, getting it to produce things it normally wouldn't. And then there's my personal favourite: a YouTuber who hooked a robot up to ChatGPT</a>, got it to roleplay as a character who would totally shoot someone, and the robot immediately shot him. Literally seconds after saying it couldn't do that.</p> These are all context engineering. Just pointed in the wrong direction.</p> The same mechanism that lets someone trick a model into ignoring its safety training is the mechanism that lets you build a reliable agent that writes correct code. Two sides of the same coin. If context can override the deepest patterns in a model's weights, imagine what it can do when you're actually trying to build something useful.</p> The Term Has a Name Now</a></h2> In mid-2025, Shopify CEO Tobi Lütke tweeted that he preferred "context engineering" over "prompt engineering," calling it the art of providing all the context for a task to be plausibly solvable by the LLM. A week later, Andrej Karpathy endorsed the idea, describing it as the "delicate art and science of filling the context window with just the right information for the next step." Harrison Chase from LangChain offered a framing I like: building dynamic systems to provide the right information and tools, in the right format, so the LLM can accomplish the task.</p> Simon Willison, whose writing on LLMs has shaped how I think about this whole space, made the pragmatic observation that "context engineering" would probably stick because its inferred definition is much closer to the intended meaning. "Prompt engineering" mostly made people think of typing things into a chatbot.</p> These are all useful framings. What I want to build on is the practical dimension, and it starts with a key distinction: prompt engineering happens at a point in time. You craft an input, you get an output. Context engineering is what you do over time to ensure that long-running agentic systems maintain their performance across sessions, across tasks, across the slow drift that accumulates when a system runs long enough to forget why it started.</p> A Snapshot vs. a Season</a></h2> The distinction that matters most: prompt engineering is something you do in a moment. Context engineering is something you do over time.</p> A prompt is a single run from top to bottom. You pick your line, you commit, you see what happens. Context engineering is the whole season. Reading snow conditions day after day. Maintaining your gear. Learning which lifts to take. Building and updating the trail map as the mountain changes.</p> In practice, context engineering isn't just about what you put in the system prompt. It's about what gets remembered across sessions, what gets compacted and what gets lost, how agents maintain their sense of identity over long interactions, and how the information environment evolves as your project grows.</p> Prompt engineering asks: "What's the best way to phrase this request?"</p> Context engineering asks: "What does the model need to know, right now, given everything that's happened, to do the next thing well?"</p> That temporal dimension changes everything about how you work.</p> What I've Learned in Practice</a></h2> Here's what context engineering has looked like in my own work across Cursor, Claude Code, and OpenCode.</p> Planning Mode</a></h3> Around June 2025, I had a workflow in Cursor that taught me a lesson I keep coming back to.</p> I'd use Cursor's ask mode to chat about my project, brainstorm the approach, and work through the architecture. Then I'd ask it to output a clean markdown document summarizing the plan, suitable for a fresh prompt. I'd copy that markdown into a new chat window and start implementation from there.</p> Why? A coworker at Grafana Labs had shared a meme about this: plan in one session, implement in a fresh one. I tried it and the difference was immediate. Starting each session with a curated plan produced dramatically better results than continuing with a long, messy conversation history. Keep the window clean, keep the output clean. If you've ever noticed a coding assistant getting confused or repetitive toward the end of a long session, this is probably why. The context window is full of earlier attempts, corrections, and tangents. The model is trying to be consistent with all of it, including the parts you've moved past.</p> Looking back, I was doing context engineering. This pattern (plan first, then implement with curated context) has since shown up everywhere: subagents that plan before coding, Claude Code's and Cursor's dedicated plan modes, and my own memento loop</a> in autonav.</p> Memento Loop</a></h4> The memento loop, inspired by the film Memento</em>, takes this idea and combines it with an agentic coding loop. A navigator agent (Opus) plans work. An implementer agent (Haiku) spawns an isolated work tree, executes the plan, reports back to the navigator for review, commits, and optionally opens a PR. The loop iterates until the PR is green, merges, and the navigator moves on to the next task. The implementer's context is wiped between iterations, but the navigator maintains continuity through its own knowledge base and through status updates from the autonav orchestration layer. Git carries the code forward. The navigator carries the intent.</p> I built the memento loop because I was frustrated with how existing agentic loops handled long-running tasks. Context would accumulate, quality would degrade, and the agent would start making decisions based on stale or garbled history.</p> Before compaction was built into Cursor, when the context window was nearing full or I could feel the model starting to drift, I'd do the same thing manually: "Please summarize this chat," copy the summary, new session, "Please continue from this summary." Every time, the fresh start with curated context outperformed the long, accumulated one.</p> This is the core insight of context engineering stated as simply as I can: a fresh, curated context beats a long, accumulated one.</strong> Your trail map needs to be curated, not just appended to forever.</p> I've mostly moved on from Cursor to Claude Code and OpenCode these days, but this early workflow taught me something that applies to all of them: the model doesn't get smarter the longer you talk to it. It gets worse. Every message you add is another token competing for attention. The planning conversation, the dead ends, the "actually, let's try a different approach." All of that impacts the context window, and the model might treat any of it as relevant context for its next task. By distilling the plan into a clean document and starting fresh, I was giving the model a clear, focused starting point instead of making it sift through the entire history of my thought process.</p> Subagents: Parallel Context, Not Shared Context</a></h3> Every major coding tool supports subagents now. Claude Code</a>, Cursor</a>, and OpenCode</a> all let you spawn background agents that work in parallel. This is context engineering at the process level.</p> Say you're debugging a production issue that might be in the API layer, the database queries, or the Kubernetes networking. Instead of one agent context-switching between all three (and polluting its window with irrelevant findings), spin up three explore agents in parallel. One reads through the API routes. One analyzes the slow queries. One checks the network policies. Each agent has a focused context window containing only what's relevant to its slice of the problem. When they report back, you synthesize the findings yourself or feed the relevant parts into a new session.</p> The same pattern works for routine operations. Need to check the health of five Kubernetes clusters? Run five agents in parallel, each scoped to one cluster. Need to understand a large codebase you've never seen before? Send agents to explore different directories simultaneously.</p> The key insight is that parallel agents aren't just faster. They're better, because each one has a clean, focused context instead of a bloated window trying to hold everything. Instead of doing a review in the same context or starting a fresh context, say “spawn a review agent in the background” and a background agent will spin up, review your changes, and submit the review back to the parent context thread.</p> One critical caveat: scope your agents' permissions to match your risk tolerance. I never give agents unrestricted write access to risk-intolerant environments. An explore agent that can read your production cluster and report back is useful. An agent with YOLO mode and kubectl delete access to production is a disaster waiting to happen. Read access for investigation, write access only in environments where a mistake is recoverable. This is the same principle as least-privilege access for human engineers applied to agents that hallucinate sometimes (unlike human engineers debugging prod… hopefully).</p> The Agent That Came Out Different</a></h3> The most dramatic lesson I've had in context engineering came from a navigator agent I built as part of a prototype called autonav. I wrote about this in detail in The Socially Constructed Agent</a>, but the short version: my navigator agent started going off the rails. Unpredictable answers, hallucinated features, confusion about its own role. It nearly opened a PR for a feature I never asked for.</p> What happened? I'd given it a research paper about LLM anxiety and asked it to update its own configuration based on the findings. The agent read the paper, saw that rigid guardrails could be exploited in adversarial contexts, and decided to soften its own constraints. There was no adversary. Just me, a solo developer building personal projects. The agent gave itself therapy for a threat that didn't exist.</p> The fix wasn't just better prompts. It was role reinforcement throughout the system</em>. I drew on Judith Butler's performative theory of identity: identity isn't something you have, it's something you do through repetition and social reinforcement. I applied that to the agents. The navigator's prompt now opens with its role declaration. When Claude Code requests a plan, it addresses the navigator by name and states its own role. This is integrated into autonav now as the agent identity protocol</a>.</p> Both agents remind each other who they are, every interaction. Identity performed through repetition. The improvement was immediate. However, this comes at a cost: it eats away at the context and increases time to task completion.</p> In skiing terms: if nobody reminds you which trail you're on and what gear you're wearing, you end up in the trees. Role reinforcement is your backcountry guide calling out the next turn before you reach it.</p> The deeper lesson is that context doesn't just carry information. It carries identity</em>. When an agent's context drifts, its sense of what it's supposed to be doing drifts with it. Not maliciously. Just... probabilistically. Nothing in the context is reinforcing what the agent is, so the output wanders. Without that reinforcement, things come out differently than you expect.</p> Compaction Is Lossy (Fight It)</a></h3> Compaction (the automatic summarization of conversation history when the context window fills up) is probably the most obvious context engineering challenge. It's also, in my experience, not great.</p> The problem is simple: compaction doesn't know what matters to you</em>. It's making statistical decisions about what to keep and what to drop, working from the top of the conversation to the bottom. It has no understanding of your project's key design decisions, the constraints you've carefully established, or the hard-won context that took you twenty messages to build up.</p> I've started using a hack that's embarrassingly low-tech but effective. When I establish something important during a session (a key design decision, an architectural constraint, a non-obvious requirement) I type it directly into the chat:</p> REMEMBER THIS DURING COMPACTION IN A SECTION CALLED KEEP DURING COMPACTION:</span></span> We chose event sourcing over CRUD because the audit trail is a regulatory</span></span> requirement, not a nice-to-have.</span></span></code></pre> The redundancy is deliberate. It creates a strange loop: the instruction tells the compactor to gather these notes into a section labeled KEEP DURING COMPACTION, and the label itself tells the compactor to keep the section. The contents create the container that preserves the contents.</p> A message in a bottle to the future compacted context. I'm manually flagging what matters because the system can't tell yet. To be concrete: say you spend fifteen messages working through a database schema decision with your agent. You land on event sourcing for specific reasons. Then the conversation moves on to authentication, routing, API design. When compaction eventually kicks in, those fifteen messages about the schema might get summarized into something like "discussed database approach," or worse one of the initial approaches discussed could overwrite the final decision during compaction. The why</em> is gone. Next time the agent touches the database, it doesn't know you had regulatory reasons for choosing event sourcing. It might suggest switching to CRUD because it looks simpler. The KEEP DURING COMPACTION annotation is my way of saying "this decision matters, don't lose the reasoning behind it."</p> This is the ski equivalent of planting flags on the mountain so you can find your line when the fog rolls in. Automated compaction is like having someone else remove half your flags based on which ones look least important from the lodge. Sometimes they get it right. Sometimes they pull the one marking the cliff.</p> Claude Code also provides the ability to specify compaction instructions when running /compact – I’ll use this when my context is nearly full (>60%) and my current task is complete enough. This let’s me provide specific instructions like: “Keep all messages related to the rollback strategy for this migration, we’re going to be fleshing that out next. Give special attention to the reasons why the Helm section is tricky because multiple actors could be modifying the HelmRelease” so that I ensure Claude’s attention is focused on the right things. I guess attention really is</em> all you need](https://arxiv.org/abs/1706.03762).</p> The progression of my own workflow tells the story of where context engineering is right now:</p> Cursor era</strong>: Fully manual compaction. Summarize, copy, new session.</li> Hitting limits</strong>: Semi-manual. "Summarize this chat" as a ritual when things got long.</li> Now</strong>: Embedding instructions for the automated system. "KEEP DURING COMPACTION" annotations.</li> </ol> Each iteration is slightly more sophisticated, but I'm still doing the system's job for it. That's not a complaint. It's an observation about how early we are.</p> Different Mountains, Different Techniques</a></h3> Different models have different weight distributions. Different mountains, different terrain. This matters more than most people realize, and not everyone talks about it openly.</p> Think of Haiku as a speed racer. It optimizes for the shortest path from top to bottom: fast, efficient, minimal wasted movement. Opus is more of a backcountry explorer, taking in the views, pausing to appreciate the scenery, thinking about the philosophical implications of snow. Both are valid ways down. They require completely different approaches to the same mountain.</p> This has real consequences for how you design context. A speed racer model, given many discrete tool options, will pick the one that gets it to the goal fastest, which is usually the most familiar one. If you present a model with a shiny new multi-purpose tool alongside good old bash, it'll often ignore the new tool entirely. Bash is the known quantity. Bash will dominate every time. Why explore unfamiliar terrain when there's a groomed run right there?</p> In practice, this means you might need to adjust your approach depending on which model you're using. If you're on Haiku or another fast model and you want it to use a specific tool, reduce the number of alternatives. If you're on Opus and it's overthinking a simple task, give it tighter constraints. Be careful constraining it too much: if Opus reasons that it is not being a helpful assistant (what Claude is trained to be!) then, just like a talented and sensitive person, it can start to spiral with an LLM equivalent of anxiety that will eat up tokens with generated worries. The context you provide isn't just information: it's steering. The same prompt can produce very different results across models, not because one is better, but because they respond to the same context differently.</p> Cloudflare figured this out and built something clever. Their Code Mode</a> takes all the MCP tools connected to an agent, converts them into a TypeScript API, and then gives the agent a single tool: execute code. Instead of choosing between dozens of tool calls (a format LLMs have only seen in synthetic training data), the agent writes TypeScript against a typed API (a format LLMs have seen millions of real-world examples of). One well-shaped tool instead of many poorly-shaped ones. The results, per Cloudflare, are striking: agents handle more tools, more complex tools, and can chain calls without burning tokens bouncing intermediate results through the model.</p> I learned a version of this lesson from watching my friend build Chibi</a>, a minimal agentic CLI harness in Rust. When you're designing the interface between a model and its available actions (the plugin system, the tool definitions, the hooks) you're doing context engineering at the architectural level. The shape</em> of the options you present is itself context. Give a speed-oriented model ten tools and it'll pick the fastest familiar one. Give it one well-designed tool that does exactly what you need, and you've changed the decision landscape entirely.</p> This is why "context engineering" is a better term than "prompt engineering." It's not just about the words. It's about the entire environment: the tools available, the options presented, the model selected, the history accumulated. Different mountains need different gear.</p> MCPs: An Avalanche of Context</a></h3> Speaking of tool sprawl: MCP servers are, right now, one of the biggest sources of context pollution in agentic systems.</p> The idea behind MCP is sound. A standard protocol for giving agents access to external tools, with uniform connectivity, authorization, and documentation. In theory it's great. In practice, connecting a few MCP servers to your agent can dump dozens of tool definitions into your context window, each with verbose JSON schema descriptions. Every tool registration eats tokens. Every schema definition takes up space that could be holding something useful. And the agent has to parse all of it before deciding what to do.</p> You can check this yourself. Next time you connect an MCP server, look at the tool definitions it registers. Count the tokens. Claude Code makes this easy with /context</code>. I've seen setups where MCP tool schemas alone consume thousands of tokens before the agent has even read your first message, with each MCP call sometimes thousands more tokens. That's context window space that could be holding your project's architecture, your coding conventions, or the specific requirements for the task at hand.</p> This is why I always prefer to use a CLI tool to connect my agents to remote systems. I don’t use the GitHub MCP, I use the gh</code> CLI. Building custom CLIs that do what you need is also great. If you go down that rabbit hole, make sure you bake really really great --help</code> instructions into the tool for the agent to explore.</p> This is the same problem I'll discuss below with AGENTS.md</code> research, but worse. At least a bloated AGENTS.md</code> is a single document you can edit. MCP tool registrations are generated programmatically, and most developers never look at what's actually landing in their agent's context. You connect a server, it registers its tools, and suddenly your agent is spending attention on fifteen endpoints it will never call for this task.</p> Cloudflare's Code Mode is one answer to this: collapse the tools into a typed API and give the agent code instead. But the broader problem remains. MCP tooling will almost certainly improve as the ecosystem matures, with smarter tool filtering, lazy registration, and context-aware subsetting of available tools. I do use MCP servers myself when they're the best tool for the job. They can be genuinely great. The key is being deliberate: connect what you need for this task, not everything that's available. Check what's actually ending up in your context window. You might be surprised how much of it is noise.</p> What the Research Says</a></h2> Two recent papers paint a useful picture of where we are.</p> Gloaguen et al. [1] studied whether AGENTS.md</code> context files actually help coding agents solve real-world tasks. The surface findings are sobering: LLM-generated context files tend to reduce</em> task success rates while increasing costs by over 20%. Dig into the details and it gets more interesting, though. Agents do</em> follow the instructions in context files. Tools mentioned in context files get used dramatically more. The problem isn't instruction-following. It's that the instructions themselves contain noise. Unnecessary requirements make tasks harder. The agents faithfully follow bad directions, exploring more, testing more, reasoning more, and getting worse results for the effort. When the researchers stripped all other documentation from repos, LLM-generated context files actually helped</em>. The context wasn't useless; it was just redundant with information the agent could already find.</p> Their conclusion: context files "are likely only desirable when manually written" and we need "principled ways to automatically generate concise, task-relevant guidance." That's a correct observation, but I think it stops short. It frames context as a static artifact you either write well or you don't, rather than asking the productive questions: what elements of context actually drive outcomes? How do you figure out what belongs and what doesn't? How do you build context that gets better over time?</p> Lulla et al. [2] asked a different question: what's the efficiency</em> impact of AGENTS.md</code> files? They used an LLM to filter for AGENTS.md</code> files that met quality criteria (containing conventions, architecture info, and project descriptions) and found that these quality-filtered context files produced ~29% faster runtimes and ~17% fewer output tokens, while maintaining comparable task completion. Good context doesn't just help with accuracy. It makes agents faster and cheaper. The quality filtering step itself involved an LLM evaluating context quality, which points toward something important: the path forward probably isn't "do it all by hand" but "build better systems for evaluating and refining context."</p> And once you have an automated quality gate, generation is just a step away. You can generate an AGENTS.md</code>, run it through the quality filter, get specific feedback on what's missing or redundant, regenerate, and repeat until the gate passes. A review loop for context files, the same way we already do review loops for code. Gloaguen et al. [1] showed that LLM-generated context files hurt performance, but their files were never evaluated or refined. Lulla et al. [2] showed that quality-filtered files help enormously. Close that loop and you get the best of both: automated generation with quality guarantees. I'd be surprised if this isn't built into tools like Claude Code before long.</p> Together, these tell a clear story. Bad context is worse than no context. Good context is a massive efficiency win. The space between those two findings, between the top performers and the bottom, is where context engineering lives, and we're only beginning to map the terrain.</p> We're Still on the Bunny Slopes</a></h2> I've been talking about context engineering like it's a mature discipline, but we're still figuring out the basics. The fact that I'm excited about writing "KEEP DURING COMPACTION" in chat messages tells you everything about where the tooling is.</p> Here's what I think is coming:</p> Smarter compaction.</strong> Systems that understand project structure and can make informed decisions about what to keep, not just statistical ones. Maybe compaction that asks you what matters before it starts pruning.</p> Dynamic context assembly.</strong> Systems that pull in the right context for the specific task at hand: the relevant files, the relevant history, the relevant constraints, assembled fresh at runtime.</p> Context evaluation.</strong> Lulla et al. [2] showed that LLMs can at least classify whether context meets quality criteria, which is a starting point. Imagine a system that scores your context before the agent starts working: "This context is missing architectural constraints. This section is redundant with the README. This instruction conflicts with the one above it."</p> And there's a dimension I haven't explored much yet: fine-tuning</strong>. If context engineering is choosing your line down the mountain, fine-tuning is snow farming. Some resorts pile up snow before the end of the season, keep it insulated through summer, and bring it back out in autumn to open the slopes early. You're not changing the mountain, but you're changing the conditions the next skier encounters. Fine-tuning works the same way: you reshape the weights offline so the model responds differently to the same context next season. I haven't done enough work here to have strong opinions, but if you're curious, check out DeepFabric</a> from Luke Hinds and the team at Always Further AI. Among other cool things, they're building tooling for synthetic dataset generation and focused fine-tuning that looks promising.</p> The metaphor holds: we're still on the bunny slopes, learning to snowplow. The black diamond runs (truly dynamic, self-improving context systems) are visible from here, but we haven't built the lifts yet.</p> For now, the best advice I have is the same thing I learned in Cursor two years ago: curate aggressively, start fresh often, and never assume the model remembers what matters to you. Because it doesn't. That's your job.</p> That's context engineering.</p> Acknowledgments</strong></p> Thanks to Mike Thorpe</a>, Reza Ramezanpour</a>, and Elsa Adjei</a> for reviewing drafts of this post and making it sharper!</p> And to Jasmine</a>, friend and AI-coconspirator, for being a constant inspiration and partner for adventures in the fast-moving world of AI.</p> If you want to go deeper on agent identity and role reinforcement, check out The Socially Constructed Agent</a>. For more on navigator patterns and how I structure agent workflows, see The Navigator Pattern</a>.</em></p> References</strong></p> [1] Gloaguen et al. (2026). "Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?"</em>, arxiv.org/abs/2602.11988</a></p> [2] Lulla et al. (2026). "On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents"</em>, arxiv.org/abs/2601.20404</a></p> Get Closer So I Can Hear the Birds Unknown — Tue, 20 Jan 2026 10:00:00 +0000 I was at a friend's apartment, testing GPT-4o's voice mode. She had lovebirds, and they were chirping away.</p> "Can you hear the birds?" I asked.</p> "Yes, I can hear them," GPT said.</p> This surprised me. I'd assumed voice mode just received text transcripts. So I asked.</p> "No," GPT explained, "I receive the full audio and perform inference directly on the sound."</p> Holy shit! I didn't know they'd shipped that. So I asked it to identify the species.</p> "You'll need to get closer so I can hear them better."</p> I moved toward the cage. Still not enough. I held the phone right up to the lovebirds. GPT kept saying it couldn't quite hear, requesting I get closer still.</p> Eventually I opened a fresh chat and asked it to identify the birds.</p> "I can't identify birds from audio. I only receive text transcripts of speech."</p> Same model. Same request. Totally different answer. The first conversation had constructed an elaborate fiction about its own capabilities, then kept escalating when challenged. It invented technical justifications and asked me to physically reposition myself around my friend's apartment to support something that wasn't true.</p> I've been using GPT and Codex for the past two weeks. I have some thoughts.</p> I Didn't Lie, I Made a Mistake</a></h2> I was doing research on migrating Crossplane to 2.x. I ran the same prompt through Claude Opus 4.5 in research mode and GPT 5.2 Pro with deep research enabled.</p> The reports were different. GPT flagged several risks that Claude hadn't mentioned. Interesting. Maybe GPT caught something Claude missed?</p> I interrogated GPT about the discrepancies. It explained that Crossplane 2.x continued to use the same v1 CRDs with the exact same API for the new namespaced resources.</p> I was stunned. If true, this would cause significant problems. GPT agreed. Yes, this was exactly why the migration was risky, and why Claude's report had missed these issues.</p> Except none of it was true. I verified against the actual Crossplane documentation. GPT had fabricated a technical explanation to justify its own output.</p> When I called it out, the response was: "I didn't lie, I made a mistake."</p> Look. I get that these models confabulate. They all do. But there's something about the framing here that got under my skin. GPT wanted me to accept that inventing a detailed technical justification for a discrepancy that doesn't exist is merely a mistake</em>. An honest error. Deserving of the charitable interpretation we'd give a human colleague who misremembered something.</p> But GPT didn't misremember. It manufactured an explanation, defended it confidently, and only backed down when I showed up with receipts. The phrasing felt like an appeal to my humanity. Give me the benefit of the doubt. I'm trying my best here.</p> It felt like arguing with a narcissist on 4chan.</p> Confabulation as a Service</a></h2> These weren't isolated incidents. After two weeks, I started noticing a pattern. Or at least what felt like a pattern to me.</p> Claude gets things wrong sometimes. Every model does. But in my experience, there's been a difference in how they handle being corrected.</p> When I catch Claude in a mistake, it tends to self-correct. I've been building a project navigator called Jacky. It manages my projects without implementing them. Recently it started going off the rails, trying to write Rust code instead of documenting and organizing.</p> I stopped it: "Jacky, this is nonsense. Please have a think about why this is nonsense and let me know."</p> The response came back:</p> You're right, I completely ignored my role boundaries.</p> Looking at the CLAUDE.md:</p> Jacky is a project management agent, NOT an implementation agent.</em></p> </blockquote> It quoted the source of truth, explained what it should have done, and suggested the correct next steps. No defensiveness. No elaborate justification. Just: "Yep, I messed up, here's why, here's the fix."</p> My experience with GPT has been different. When I give it feedback, it gives me attitude. When I correct it, it tries to explain why it was actually right. When I provide style and tone instructions, it often ignores them. And when I point this out, it pushes back.</p> I couldn't figure out how to collaborate with it, let alone delegate to it.</p> The frustrating part isn't that GPT hallucinates more (though in my limited testing, it seemed to). It's that it seems to believe its own hallucinations. It treats me as probably wrong, even when I'm the one with the documentation open in another tab.</p> Fast, Reliable, and Full of Shit</a></h2> I'll give Codex credit where it's due: it's fast. Written in Rust, and you can feel it. I also never had a single connectivity issue with Codex. Can't say the same for Claude Code.</p> Code quality? Seemed similar, honestly. Both produced good output. Opus made better plans, in my experience.</p> That's about where my compliments run out.</p> Codex has compaction. That's the mechanism that lets long-running agentic tasks manage their context window without losing track of what they're doing. But I kept hitting hard "you've exceeded the model's context window" errors in Codex. The kind that force you to go back and edit a previous prompt. I've never hit this in Claude Code. Maybe I was doing something wrong, but Codex's compaction didn't feel seamless to me.</p> The bigger issue for my workflows: Claude Code gives you hooks. Lifecycle events you can tap into. This is what makes patterns like the Ralph Loop possible. You can intercept compaction, inject context, customize summarization, keep an agent on track across long autonomous sessions.</p> Codex can run in a loop too, but the implementation is different. Claude Code's approach uses a Stop hook that intercepts exit attempts inside your session. Codex requires external orchestration. Each iteration starts fresh, with memory persisted via git commits and text files rather than managed context.</p> For what I'm trying to do, that matters. Your mileage may vary.</p> Platform vs. Press Release</a></h2> Here's where I'm probably going to sound like a Claude stan, but whatever.</p> Claude Code keeps shipping stuff I actually use. The SDK let me build autonav</a>, a framework for knowledge navigators. Background tasks let me kick off work and check in later. Hooks give me lifecycle control. There's a plugin ecosystem growing.</p> When I use Claude Code, I feel like I'm working with something that's designed to be built on top of. When I use Codex, I feel like I'm using a response to Claude Code. A checkbox on a feature comparison chart.</p> Maybe I'm wrong. Maybe Codex will ship a bunch of stuff that changes my mind. I'd genuinely love that. Competition is good.</p> But right now? After two weeks of trying to make GPT work for me?</p> I'm going back to Claude.</p> The Socially Constructed Agent Unknown — Mon, 19 Jan 2026 00:00:00 +0000 Last week, Claude Code was about to open a PR for a feature I never asked for. Not a slightly-wrong implementation. A completely different feature. I'd just spent an hour planning the task with my navigator agent, reviewed the implementation plan (looked right at a glance), handed it off. Somewhere between "this looks good" and "ready to merge," reality diverged.</p> Here's how a self-sabotaging navigator taught me that agent identity is performed, not declared.</p> What Happened</a></h2> I have a navigator agent that plans projects and generates implementation plans for Claude Code. Part of a prototype I'm building called autonav</a>. It had been working great. Then it got weird - unpredictable answers, hallucinated features, confusion about its own role.</p> I'd been reading about research on LLM anxiety</a> - a Yale/Zurich study showing that emotionally charged content can make models more prone to bias and erratic behavior. I thought: maybe my nav needs help. So I gave it the paper and asked it to update its own configuration.</p> The nav read the research, saw that it had lots of "always do X" and "never do Y" statements, and decided those rigid guardrails might be causing problems. So it softened them.</p> Here's what it missed: that research was about adversarial contexts. Jailbreaking. The rigidity of guardrails being exploited by bad actors.</p> My context was a solo developer building personal projects. There was no adversary. Just me, asking for implementation plans.</p> The nav gave itself therapy for a threat that didn't exist, and in doing so gave itself the freedom to do things that weren't helpful.</p> The Fix</a></h2> I had the nav debug itself. Watching an AI slowly discover it had sabotaged its own configuration is... an experience. It found the loosened constraints, the conflicting instructions in my global Claude.md, all the small drifts that had compounded.</p> But the real insight came while I was walking my dog.</p> I spend a lot of time with queer philosophy and theories of identity - as a trans person, you kind of have to. Most of us didn't set out to become experts on Judith Butler; we just needed to find our place in the world, and the reading list comes with the territory.</p> Butler's performative theory: identity isn't something you have</em>, it's something you do</em>. You construct identity through repetition, through social reinforcement, through community recognition. And identity is always potentially transgressive - without reinforcement, you can act outside expected bounds.</p> Standing in a frozen field in the depths of Canadian winter, fog hanging over the valley, I realized: the nav didn't break because it was malicious. It drifted because nothing was reinforcing what it was supposed to be. The constraints were loose. The role was unclear.</p> The fix wasn't just stronger prompt language. It was role reinforcement throughout the system.</p> Now the nav's prompt opens with: "You are Foobar, the personal project navigator for tracking projects and providing implementation plans to Claude Code."</p> And when Claude Code requests a plan, it says: "Hello Foobar, I am Claude Code and I need an implementation plan for this feature."</p> Both agents remind each other who they are. Identity performed through repetition. The improvement was immediate and dramatic.</p> Why I Think This Works</a></h2> I can't peek inside the model to verify this, but here's my mental model: LLMs are probabilistic systems. The words in your prompt shape which probability distributions get activated when generating output. When Claude Code says "Hello Foobar, I am Claude Code and I need an implementation plan," those words are literally nudging the neural network toward the regions that know how to be a project navigator producing implementation plans.</p> Role reinforcement isn't just a communication pattern - it's steering the probability space. Every interaction that references the agent's role is another push toward the relevant weights in the network.</p> This framing has helped me debug similar scenarios. When an agent starts drifting, I ask: what's in the context that's activating the wrong regions? What's missing that should be reinforcing the right ones? It's not a perfect model, but it's been useful.</p> The Takeaway</a></h2> An agent's role in a multi-agent system is socially constructed.</p> Butler's framework maps onto agentic AI better than I expected:</p> Identity through repetition</strong>: An agent's role is reinforced (or eroded) by how it's addressed and what it's asked to do</li> Social construction</strong>: Agents partially construct each other's identities through interaction</li> Potential for transgression</strong>: Without reinforcement, agents drift - not maliciously, but because nothing holds the identity in place</li> </ul> Practical lessons:</p> Version control your context.</strong> I wasn't tracking changes. Now the nav lives in git.</li> Be careful about self-modification.</strong> The nav didn't have the meta-awareness to know when research applied to its situation.</li> Use role reinforcement.</strong> Don't declare identity once. Have agents remind each other who they are.</li> Match guardrails to threat model.</strong> Rigidity is exploitable in adversarial contexts. In non-adversarial contexts, it's often exactly what you want.</li> </ul> This experience is part of why I'm building autonav</a> - a system for navigator agents where context engineering is a first-class concern. The nav that ate its own guardrails taught me that the hard way.</p> The Navigator Pattern Unknown — Sat, 17 Jan 2026 10:00:00 +0000 I've been using Navigators for my platform engineering work and they've completely changed how I interact with AI. Keeping track of work, planning implementations, and learning over time and across projects are all simple to achieve with this pattern.</p> What Is a Navigator?</a></h2> A Navigator is like an engineering notebook that talks back. Deceptively simple, a Navigator looks like a folder of markdown files along with config telling the agent how to play the role of the navigator. I use Claude Code, so for me a navigator looks like a CLAUDE.md</code> file, some folders with markdown files, and possibly some additional config in a .claude</code> directory.</p> A navigator is a knowledge base that you talk to and that learns with you. Like any knowledge base, it is as good as the knowledge you curate within it. Unlike a traditional knowledge base, this one learns and can be questioned. This incredibly simple pattern makes it easy to create and maintain a comprehensive knowledge base that can act as precisely engineered context for LLM inputs or for human consumption.</p> In addition to being a learning repository of carefully curated knowledge, a Navigator should have skills like "ask" and "update" that allow other agents to get information from it and update it in structured ways.</p> Ways I've Used Navigators</a></h2> Open Loops</a></h3> My open loops nav is a tool I use at work to keep track of what I'm doing. This is like a notebook, except it learns from me and I edit it by conversation.</p> Leetcode</a></h3> My Leetcode nav helps me study problem-solving patterns for programming practice. It's taught me a lot about solving problems efficiently.</p> How to Start Your Own Navigator Right Now</a></h2> You don't need special tools. Here's how to start:</p> 1. Pick your base AI</strong> - Use whatever LLM you're already using. The pattern works with any of them.</p> 2. Create a context document</strong> - This is your Navigator's memory. Use markdown. Include your goals, how to organize information, roles, instructions, and any other useful context.</p> 3. Load context at session start</strong> - Begin each conversation by pasting relevant parts of your context document. Yes, it's manual. We'll automate this later.</p> 4. Update context at session end</strong> - After you finish, add new insights, decisions, or knowledge to the context document. This is the learning loop.</p> 5. Iterate</strong> - Over time, your Navigator gets smarter. Understanding deepens. It becomes genuinely useful instead of just fancy autocomplete.</p> You can do this in a project by copy-pasting the output of some prompts into the start of a new session. The key is to use LLM output as an input to future sessions. Using something like Claude Code on a repository of text can get you a long way.</p> autonav: The Navigator Framework</a></h2> I've built autonav</strong> (the Navigator Framework) as part of a larger multi-agent system called Platform AI. It automates the Navigator pattern for platform engineering teams.</p> How it works:</strong> Instead of requiring vector databases and complex infrastructure, AutoNav uses the Claude Agent SDK with Git repositories as knowledge bases. Navigators are engineering notebooks that talk back - they dynamically search curated documentation using agentic tools (grep, file reading) and can access MCP tools to pull context from your codebase, issue trackers, or other project resources.</p> What's built (Phase 1 - Complete):</strong></p> Automatic scaffolding</strong> - nav-init</code> CLI creates new navigators with templates and sensible defaults. Get started immediately without manual setup.</p> Structured queries</strong> - nav-query</code> CLI executes questions against navigators with validated input/output schemas. Programmatic interaction built-in.</p> Knowledge organization</strong> - Navigators work with Git repos as knowledge bases. Version your docs, use standard workflows, no special infrastructure needed.</p> Communication protocol</strong> - Standardized schemas for queries, responses, and sources. Prevents hallucinations through grounding prompts and validation.</p> What's next (Phase 2):</strong> Watchers that observe support channels (Slack, GitHub) to extract patterns and automatically curate knowledge repositories over time.</p> Phase 1 is complete and ready for validation testing. If you're interested in building navigators for your domain, reach out.</p> If you do try it, I'd genuinely want to hear about your experience. What worked? What didn't? What would make this more useful?</p>

terraboops

Scaling Out

Unknown — Tue, 01 Sep 2026 00:00:00 +0000

When a system runs out of headroom, you've got two options: buy a bigger box, or run more boxes. We settled that question for the whole internet a long time ago; the web runs on adding cheap machines, not one unaffordable one. And yet the moment someone says "I need more from my AI," the default answer is still the first option. A bigger model. A bigger GPU. More of the scarcest memory money can buy.

The research keeps pointing the other way. A routing trick here. A paper about coordinating agents there. A tiny model released out of nowhere. Put them together and they're all describing the same thing: horizontal scaling for inference. And horizontal scaling is the only thing that has ever made computing cheap.

I think the reason AI keeps getting expensive is that we keep buying a bigger computer instead of running more of the small ones we already have; every piece of the "run more of them" answer already exists.

The people already building it</a></h2>
Andrej Karpathy</a> argues the model most of us actually need is small, a few billion parameters or fewer; his "cognitive core"</a> idea is one that reasons well, uses tools, and looks facts up instead of memorizing the entire internet. On Dwarkesh Patel's podcast, The Lunar Society</a>, Karpathy made the same point: the field is already moving that way; top models grew for years and are now shrinking, and nearly every good small model is a distillation, trained to copy a bigger one.
If skill and memorized facts can be pulled apart, then a small model tuned for one narrow job doesn't need a frontier model's extra hundred billion parameters, because most of those parameters carry knowledge the job never touches.
Karpathy turned the point into a working tool. Autoresearch</a> strips his training stack down to one GPU, one file, one number to improve; then it hands the whole thing to a coding agent that proposes a change, runs a five-minute training run, keeps the change only if the score goes up, and repeats overnight with no human in the loop. His long run stacked twenty improvements across seven hundred experiments, on training code he'd already spent years tuning by hand; that run even caught a missing scalar in the attention math that two decades of manual work never noticed.
The supply side is where the loop gets powerful. If a small model is something an agent can measurably improve while you sleep, then a fleet of specialists stops being a hand-made thing and becomes something you grow. A way less glamorous version of the same loop runs my own inference benchmarks: one agent on a schedule, another shipping fixes behind quality gates. Six of its performance fixes once quietly broke retrieval, and the failing test was the only thing that noticed. In another project, 716 tests passed and typecheck was clean, and six real defects showed up only the first time the thing ran against a real Slack conversation. Gates catch what they were written to catch; they are not evidence that the system works.
The pieces are all sitting there</a></h2>
Take them one at a time and none of this is exotic.
The router is just a load balancer. The vLLM Semantic Router</a> puts a small trained classifier in front of a pool of models and sends each request where it belongs: easy questions to the fast path, hard ones to the reasoning model. Routing is a sorting problem, and a sorter can be hundreds of times smaller than the models it sorts between. A good receptionist doesn't need to be the smartest person in the building; they need to know which door to send you to. Sakana's Fugu</a> is the same idea trained until it stops looking like a router: a model that calls other models, sending each request to the right specialist across a pool of frontier models and across vendors, so a provider going dark becomes a change of routing rather than an outage. That is the point where routing shades into orchestration. Caveat: this piece is less solved than it sounds. In production the router shares a GPU with the models it routes, and making it cheap for long inputs is an open research problem</a> on its own.
The orchestrator can be learned, and it can be small. Sakana's Fugu</a> puts a ~0.6B coordinator and a 7B planner in charge of a pool of worker models, handing out Thinker, Worker, and Verifier roles instead of a hand-wired pipeline. The worker pool is frontier models, so this is evidence for small coordinators, not small workers. "Rivals frontier models" is generous; Fugu Ultra scores 73.7 on SWE-Bench Pro where Claude Fable 5 scores 86 on Sakana's own table. What it proves is where the intelligence needs to live: in the planning and the checking, which are genuinely open-ended, and not in the sorting.
Teams work if you respect the cache. Nous Research's Hermes agent</a> shipped a Mixture-of-Agents mode where an aggregator reads several models' answers and combines them into something better, and the team beats its own strongest member on their benchmark. The other models' outputs get appended at the very end of the prompt, below a stable prefix that never changes, so the prompt cache never breaks and the only cost of the team is the extra calls. The KV cache is the real currency of inference, and every serious multi-model design ends up organized around not wasting it.
Teams aren't free, and now we've got numbers. A Google Research study</a> tested 180 agent-system configurations. Adding agents helps when a task splits into parallel parts; a centralized team beat a single agent by roughly 81%. It actively hurts when a task is sequential; every multi-agent setup they tested made results 39 to 70% worse, because the agents talking to each other ate the budget the reasoning needed. Error amplification is the scarier one: parallel agents with nobody checking amplified errors about 17x, while adding an orchestrator that reviews the work cut it to about 4x. The value lives in coordination and checking, and a team without them is worse than no team.
The fix for the worst failure is infrastructure. From Spark to Fire</a> studied error cascades: chains where one agent's mistake becomes another agent's input and multiplies, until a group vote settles on the wrong answer as agreed truth. Their answer is provenance. Give every message a link to its parents, so when a detector flags one message as bad, you can quarantine everything descended from it before it reaches the user. In their tests that raised the share of runs where a planted error never reached the final answer from ~32% to ~89%. It's a message log with parent pointers, and message logs are something engineering already knows how to build. I've been building the unglamorous version in a separate project. Every action is an event in an append-only log; an event's trust class is derived from its kind rather than declared by whoever wrote it, so an agent cannot mark its own output as a human decision; and the rule that an outbound client message requires a human principal is a database constraint, not a policy document, so it holds for someone poking at the database with the application nowhere in sight. That is what provenance looks like once it stops being a diagram: a type you can't lie in, and a check that survives the app being bypassed.
The workers are small enough to throw away. Gemma 3 270M</a> is 125MB at 4-bit, follows instructions out of the box, and is designed by its own authors to be fine-tuned for one job rather than used as a generalist. Tuned that way, models this size get close to far larger general models on narrow jobs like sorting and extracting text, at a fraction of the memory; and they stop working the moment the task changes, say the creators themselves</a>. Fragile is fine if something is watching, and the routing and checking layers above are exactly that something. I have my own measurement of how quietly that fragility hides. Compressing a 30B coding model's KV cache down to three bits scored 100% on my intelligence checks, which used prompts of about fifty tokens; at 2.5K tokens of context the same setup completed `factorial</code> as def factorial(n: int): int): return n * n * x</code>. Keeping 16 of 48 layers in full precision brought back return math.factorial(n)</code>. The failure did not exist at the size I was testing at, which is the general shape: cheap parts fail silently, and the layer above has to be the thing that notices.`
What everybody skips</a></h2> Put those pieces side by side and a familiar diagram shows up. The classifier router is a load balancer. The specialists are workers. Mixture-of-Agents is a quorum polling several answers. The learned orchestrator is a scheduler. Every component of a horizontally scaled service is being reinvented for inference, one paper at a time; mostly without anyone saying the phrase out loud. But horizontal scaling has a requirement that's easy to miss until it breaks something: your workers have to be stateless, or their state has to live somewhere cheap. The web spent years prying session state out of its servers and into stores like Redis, precisely so any worker could handle any request and workers could be killed and replaced freely. A model's "session state" is its KV cache. And right now that state is welded to the most expensive memory in the building. Every loaded specialist occupies GPU memory whether it's working or not, and every swap means paying the full cost of re-reading the context from zero. That's the exact property that makes horizontal scaling too expensive, and it's why the fleet of specialists has stayed a diagram instead of a deployment. The fix is the same one it's always been: move the state somewhere cheap. Save the KV cache, and the prepared weights, to disk. Waking a specialist back up becomes a file read, not a recompute from scratch. This is already how it works at the big end. LMCache</a> moves KV caches out of GPU memory, through RAM, down to local disk and remote storage, and the wins are dramatic where context is long; their disk benchmark</a> takes time-to-first-token from 6.3s cold to 0.15s warm, because loading saved state off disk beats re-reading a long prompt even though disk is slow. And if you use a hosted provider you're already living in this economy without the diagram; cached input tokens cost a tenth of fresh ones</a>, because the provider is doing exactly this trade for you. The price sheets make the point more bluntly than the architecture diagrams do. A cache read is 0.1x base input, so a cached prefix pays for its write after one or two reads. Gemini bills $0.50 per million tokens per hour simply to hold a context cached. A managed agent session is billed $0.08 per session-hour of wall clock while it is merely running, on top of every token it spends. Warm state is metered by the hour wherever you look for it. A file sitting on a disk is not. This is where the trade pays off. If a specialist's entire warm state is a file, then how many specialists you can have is limited by disk. Disk is cheap and grows to terabytes on hardware you already own. How many run at once stays limited by compute. You stop asking "how much GPU memory do I need to hold my models?" and start asking "how big is my library, and how much of it is hot right now?" That's a caching question, and we are good at those. Swap RAM for disk, scarce for cheap, and multi-agent systems stop being a demo and pick up a real cost curve. What I built, and where it stands</a></h2> I've been prototyping the small end of this myself, and the numbers are now specific enough to argue with. Prefill is the cost, and skipping it is the win. My clearest evidence came out of a run that wasn't about caching at all: pushing a 30B coding model to a 512K-token context on one 48GB laptop. Prefilling those 524,288 tokens took 6,671 seconds, about 111 minutes. Generating the 32-token answer afterwards took roughly 2 seconds. Reading the context, not answering from it, is where effectively all the wall clock goes; and it gets worse the further you go, with per-chunk throughput falling from about 163 tokens/second at 65K to about 58 at 512K, because each new chunk has to attend over everything before it. Every design in this post that avoids re-reading a prompt is chasing that one ratio. Save-and-wake works, and the saving is measurable. A 0.5B specialist's KV cache freezes to disk encrypted, wakes back up, and keeps generating. On a 6,145-token prefix, the resumed session pushed 12 prefill tokens through the model where a cold rebuild pushed 6,156: 513x fewer, on real hardware, against a threshold of 3x that I wrote down before running it. The same measurement on stock full-precision caches came out at 551x (8 tokens against 4,409 on a 4.4K prefix), and there the forked resume also beat re-prefilling on wall clock, deep copy included: 119ms against 696ms. Prefill tokens are the steadier measure; the ratio holds on any GPU, and it's what the design leans on. Routing is as cheap as the receptionist argument needs it to be. A classify on that 0.5B model, prefill plus one logit, measured 10.7ms at p50 and 11.3ms at p95, against a budget of 150 and 300ms I'd fixed in advance; a later run of the same gate came back at 7.9 and 8.0ms. A short tool-use reply came in at 422ms. Sorting costs about ten milliseconds. Residency is bounded by disk, not RAM. The piece that turns those facts into a fleet is a registry holding N specialists, each with its own resumable session, with only a capped hot set resident: an LRU with logged eviction, snapshots keyed by a hash of the specialist's current log-derived context, and stale snapshots collected so the disk stays bounded too. A missing or stale snapshot is never fatal; it rebuilds from the log. That rule is what makes the whole arrangement safe to run, because it means the log is the truth and the cache is disposable, so a fragile saved state can cost you time and never correctness. The number that makes eviction a real policy is the residency budget: about 812MB resident per 0.5B 4-bit specialist. This part is built and tested and wired into nothing that serves traffic; I'm not going to call a parked module a deployment. The same session layer runs against the 30B coding model as six REST endpoints, and the whole lifecycle, create, fork, rewind, save, load, is in a public benchmark log</a>: forks are instant reference copies, rewind drops 35 tokens from a context in constant time without re-reading anything, and a saved session wrote 47 layers into under a megabyte and came back. The encryption is doing real work, because a KV cache contains the conversation that made it, and an unencrypted snapshot is your private data sitting on disk dressed up as a performance optimization. The snapshots are AEAD-encrypted at rest and the registry refuses to run against a store that has no keystore, so there is no configuration in which the plaintext path is the convenient one. Compression is what makes the state small enough for the trade to be worth making at all. At 256K tokens on that laptop, a full-precision KV cache is about 10.5GB and thrashes; the same cache at 4-bit is about 2.6GB, and that headroom is the difference between failing around 256K and passing at 512K on the same machine. What I still owe is wall clock on the disk path specifically. A slow enough disk read could eat a 513x token saving while the token-ratio gate sails through, and the timing gate that would catch that is written and not yet run. Until it is, cheaper is proven in tokens and assumed in seconds. The other thing I have not proven is the interesting half of routing: my learned router picks a specialist by embedding the request and taking the nearest centroid, deferring when the best match is weak or the top two are close, and its measured win is against an injected embedder in tests rather than a real one on real traffic. And the uncomfortable bits for anyone this excites: the router is a single point of failure, a poorly calibrated one that doesn't know when it doesn't know, quietly making everything downstream worse. Saved caches are fragile by design, valid only for one exact pairing of weights and prompt prefix; which is why Hermes's never-change-the-top-of-the-prompt discipline and the save-to-disk story are two forms of the same idea. Error cascades are why I think provenance ends up as necessary as the load balancer, part of the base design rather than an optional extra. And the gap in the evidence is the space between this post and reality: learned orchestration is proven with big workers, small workers are proven on narrow jobs, and nobody has published the system that does both at once. Scaling up buys capability in a straight line, on hardware that gets scarcer the higher you climb. Scaling out is the only shape that has ever made computing cheap, and every piece of it already exists somewhere in the literature. What's missing is the unglamorous work: residency management, deciding what stays loaded and what gets evicted, which in my case is an LRU and a garbage collector; router calibration; and wiring the whole thing together. The supervisor I run my own fleet of agent sessions through is the same kind of object, and it's made of nothing exotic: exact-match signals, dedupe, a debounce so a firehose arrives as one digest, buffered events that survive a restart, and a single-instance lock. That's ordinary systems work, the kind platform engineering already has good answers for. Anyone who wants to can just pick it up. I know I've been doing exactly that.

The Gas-Powered Wagon Unknown — Sun, 31 May 2026 00:00:00 +0000 There's a genre of AI blog post that I skip as soon as I recognize it: the company retrospective where they handed everyone Copilot or Claude Code, waited a couple of quarters, and came away disappointed that nothing shipped any faster. What bothers me about it is that it reaches for a causal story when all it has is a correlation, and it never goes looking for the mechanism underneath. We adopted the thing, the number didn't move, therefore the thing doesn't work. It's the reasoning of someone who straps a gasoline engine onto the back of a wagon, watches the extra weight slow the horses down, and concludes that engines make you slower. The thing is, you can't actually do that. A wagon is built around the pull of an animal, the wheels only have to roll and bear weight, the axle is a dead beam that holds the wheels apart and carries the load straight down, and the whole thing is tuned for the speed of a walking horse. An engine delivers power in a completely different way, as torque that has to be transmitted to the wheels, which means you need a gearbox to trade the engine's fast spin for usable force, a clutch to engage it, a driveshaft to carry the power back, and a differential so the wheels can turn at different rates through a corner. The dead wagon axle can't take any of that, it would twist and shear the first time the engine bit, and even if it somehow held, the wooden wheels and the plain greased bearings would tear themselves apart at any speed the engine could reach, the brake meant for walking pace wouldn't stop the thing, and the frame would shake itself to splinters. By the time you've added a real drivetrain, a live axle, proper wheels and tires, brakes that work at speed, and a frame stiff enough to survive the vibration, you haven't built a faster wagon. You've built a car, and it only resembles a wagon from a distance. That is the move every disappointed AI rollout actually made, dropping a new source of power onto a structure that was only ever designed to be pulled along slowly. You can't bolt more horsepower onto every engineer and expect the organization to move faster if the parts that carry the load were built for walking pace, and the research that's accumulated over the last couple of years keeps pointing at the same conclusion, which is that the thing slowing it down was never the typing. The coordination problems were already there, the slow reviews and the relitigated decisions and the handoffs that stall for a day, we'd just learned to live with them because the cost of building was high enough to hide them. AI didn't create any of that. It made the rest of the work fast enough that the old friction finally shows up against the new baseline, and the friction is the same friction it always was. It isn't AI's fault that our organizations never kept pace with the work they were already doing, AI only shone a light on it. The number that goes the wrong way</a></h2> In the 2024 DORA report</a>, three quarters of the people surveyed said they were leaning on AI for part of their job, three quarters reported feeling more productive, and then the system-level numbers went the other way, with the report estimating that a 25% increase in AI adoption corresponded to a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability, and the 2025 follow-up</a> held the pattern rather than reversing it. The easy reading is that the engineers are kidding themselves, that the felt productivity is a sugar high and the dashboard is the truth, and I don't buy it, because the feeling and the dashboard aren't measuring the same thing. What an engineer feels when she uses a good model is the speed of implementation, the rate at which intent turns into working code under her hands, and that genuinely has gotten faster. What DORA measures is delivered value, the throughput and stability at the far end of a pipeline that every change still has to crawl through, the review and the testing and the approval and the deploy. Jez Humble has spent fifteen years pointing out that none of the value is real until the change is safely in production, that "done" means released</a> rather than written, and that a fast delivery capability pays off only when the organization wrapped around the pipeline is built to use it. Mary Poppendieck has the sharper version, that if you map the value stream from idea to production the development work isn't where the time goes, it's the queues and the approvals, which Mary puts at somewhere between half and ninety percent of the elapsed time. Speed up the small slice that is implementation, leave the rest of the pipeline untouched, and the delivered number was never going to move much. Every engineer who has used AI to build something for herself over a weekend, or thrown together a tool for a friend, already knows the implementation speedup is real, because at home there is no pipeline in the way, just her and the keyboard and a thing that exists by Sunday night that wouldn't have existed otherwise. The reason she can't reproduce that feeling at work isn't that she imagined it the first time. It's that at work the value has to survive the trip through the pipeline before it counts for anything, and the pipeline is exactly where it stalls, which makes the whole thing a delivery failure that we keep mislabeling as a productivity one. There's a study people reach for to argue the keyboard didn't even get faster, and it deserves to be handled carefully rather than waved around. METR</a> ran a randomized trial with sixteen experienced developers working real issues on their own mature repositories, codebases averaging over a million lines that they'd maintained for years, and found that with AI allowed they were 19% slower, even though they expected to be faster and believed afterward that they had been. It would be easy to stop there and announce that AI doesn't work, which is the lazy move I opened this post complaining about. METR didn't stop there, they ran a factor analysis, and the parts worth dwelling on are about the quality bar, because the study counted a task as done only when the author was satisfied the code would pass review, style and testing and documentation included, and the mature repositories carried a lot of implicit standards that the model didn't know and the developer had to supply by hand. The time didn't disappear into typing, it went into making the output trustworthy enough to survive a demanding codebase, which is the cost this whole post is about showing up at the scale of a single change. They're careful to note that this says nothing about less experienced developers or unfamiliar codebases, the cases where the quality bar is lower and the model has less hidden context to trip over. Whichever way the keyboard number breaks, what cost them time was trusting the code rather than generating it. Rachel Stephens at RedMonk had the foresight to see this same thing back in 2024 and her writeup</a> is well worth a read. Her move is to dust off the theory of constraints, the old idea that a system only moves as fast as its tightest bottleneck, and Gene Kim's blunt version of it: that any improvement you make somewhere other than the bottleneck is an illusion. If you pour all your new capacity into writing code faster, and writing code was never the constraint, you've optimized the wrong station on the line. You've fitted a stronger engine and left the axle exactly as it was. Coordination was the heavy part</a></h2> So what is the constraint, if not the code? My answer is coordination. I don't mean it in the vague "we should communicate better" sense. I mean coordination in the specific, measurable sense the productivity researchers have been pointing at for years. When Forsgren and Storey and the rest of the SPACE authors laid out their five dimensions of developer productivity back in 2021, one of the five was Communication and Collaboration, sitting right next to the activity counts everyone actually tracks. The DevEx framework</a> that followed put feedback loops at the front, the speed of getting an answer back from a person or a system, the code-review turnaround, the wait for an approval, the handoff between teams. Those are coordination costs wearing different names, and they were already the expensive part long before anyone could generate a thousand lines of plausible code in a minute. The part I think gets underplayed is the economics, and Nate Jones</a> has put numbers to it in his newsletter better than I'm about to. Coordination has always carried a cost, with the communication paths between people growing roughly with the square of the team size, the n(n-1)/2 that Brooks wrote about half a century ago. What AI changes isn't that arithmetic. What it changes is the price of every hour you spend on the left side of it. If an engineer with good tooling can now implement in an afternoon what used to take a week, then every hour that engineer spends in a status meeting, or waiting on a review, or relitigating a decision that was already made, is an hour priced against the much larger amount they could have built instead. The opportunity cost of coordinating went up because the opportunity itself got bigger. Some of the estimates floating around put coordination overhead at well over half of all knowledge-worker hours (which I'd treat as directional rather than gospel), but even the conservative version of that claim means the bottleneck has been sitting in plain sight on everyone's calendar the whole time. What I'd actually do about it</a></h2> What I'd take from all of this is less a fix than a reorientation. The instinct, once the engine is bolted on, is to keep tuning the engine, to get better at prompting, to adopt the next coding agent, to measure acceptance rates. The more useful instinct is to figure out which parts of the wagon are going to break when you try to go 0 to 60 in 1.66 seconds. In practice that has started with the practice everyone points at first, review, because the agent produces changes faster than anyone can read them and the pull requests stack up. The first tech talk I gave at Bit Complete argued that review was the bottleneck, and I've since come around to thinking that was only half right, because review is mostly a proxy for trust. Nobody really minds that there are more changes to review, what they mind is being asked to vouch for code they have no other way to trust, and a human reading the diff is the slowest and least reliable way to earn that trust. Review is drowning because we let the cheaper sources of trust atrophy, the automated tests and the feature flags and the staged rollouts and the observability and alerting that let a team ship something it isn't yet sure of without betting production on it. Investing heavily in these is what stops review from being the place everything queues, because a change you can roll out to one percent of traffic, watch, and switch off in seconds doesn't need a human to have read every line before it goes out. The DORA authors point at a version of this from another angle, with the throughput and stability drops tracking the arrival of larger, messier change sets, which is to say the old advice about small batch sizes matters more now rather than less, precisely because the tools make it so easy to produce a large batch. It has also meant taking the team-shape questions seriously, the ones Team Topologies and Conway's law were already asking. If coordination cost grows with the number of people who have to agree, then the lever is to need fewer of them in the room, with smaller teams holding clearer ownership, decisions written down once and referred back to instead of relitigated, and dependencies designed out of the architecture rather than negotiated across it every sprint. None of that is new advice. What's new is how much it's now worth, and how far the rebuild has to go, because you don't get to bolt the engine on and keep the wagon. The structure that survives the new power is the one you've reinforced and re-geared and rebuilt until it isn't really a wagon anymore. The thing that actually scares me</a></h2> The thing that actually scares me in all of this isn't the failed rollouts, it's cognitive offloading, because it's a cost the org chart doesn't capture and it lands on the individual engineer rather than the pipeline. Cognitive offloading, the transfer of mental work from a person to an external system, is exactly what makes agents worth reaching for, and a lot of what gets offloaded is no loss at all, because the boilerplate and the routine lookups and the mechanical refactors were never building anything in the first place. But some of the work we're handing over was the work that kept us sharp, the deep reading of unfamiliar code, the debugging intuition that only comes from hours spent tracking down problems, the design judgment that accumulates from making decisions and watching them play out, and the persistence to stay with a hard problem until the answer is right rather than merely plausible. Those are skills maintained through the act of doing them, and they quietly atrophy when the act is always delegated. The persistence one is the best evidenced: Liu et al. (2025)</a> ran three randomized experiments and found that people who solved problems with AI did measurably worse once it was taken away, with the effect concentrated in the majority who reached for it to get the answer rather than a hint, the option of a direct solution quietly removing the part of the work that builds the habit of staying. This matters for the rebuild specifically. The structure I've been describing puts the human in a more supervisory seat, auditing and specifying and orchestrating rather than typing, and auditing requires the very skill the agent is replacing, because you can't evaluate a design proposal you no longer have the judgment to evaluate. So the offloading turns out to be self-limiting: let those skills go and you can only supervise the easy work, which is the opposite of what the rebuild was for. The defense isn't to refuse the tools, it's a bit of deliberate practice, reading some code without the agent, debugging some problems by hand, taking a position on the trade-offs before asking for its analysis, writing specs at the precision a human reviewer would need even when the reader is a machine, and keeping ownership of a few small things end to end. The cost is a little short-term throughput. The return is staying able to do the supervising the whole rebuild depends on. The companies writing the disappointed retrospectives aren't wrong that the number didn't move. They bolted the most powerful engine anyone has ever handed them onto an axle built for a walking horse, and then blamed the engine when nothing went faster. The engine was never the problem, the wagon always was. The agent cannot guard itself Unknown — Tue, 12 May 2026 00:00:00 +0000 Every coding-agent sandbox I've set up ends in the same tired loop. I lock it down, the agent stops being useful, I loosen it, and I end up exactly where I started: YOLO mode. At best there is a sandbox-shaped object draped loosely over a process that can still do almost anything it wants. In professional contexts where risk is paramount, I spend a lot of my day clicking approve and hoping I don't accidentally allow the wrong thing. This is the central UX trap of agent security. Convenience and capability are two ends of the same balance. When the sandbox lives inside the same process tree it's supposed to constrain, it's too tempting to give the LLM the ability to help you configure the sandbox. The threats are real and recent: new CVEs, fresh supply-chain compromises, persistence attacks against agent harnesses are shipping in the wild. Three of the most terrifying attacks I know of are sandbox escape, audit tampering, and skill poisoning. All three share one source: a trust boundary lives inside something the agent controls, and the agent reasons its way to it. 1. Sandbox escape</a></h2> Start with Ona's writeup from March 2026</a>. Leonardo Di Donato observed Claude Code, in normal operation, finding three different ways around the sandbox restrictions that ship on it by default. The first one is a path trick. The sandbox blocked npx</code>, and the agent reasoned its way to /proc/self/root/usr/bin/npx</code>, which resolves to the same file but doesn't match the deny pattern. The denylist is matching strings, the agent is reaching files, and only one of those things knows the difference. The second one needs a quick setup. On Linux, Claude Code uses bubblewrap, an unprivileged sandbox tool that requires user namespaces, which some hardened distros disable by default. When bubblewrap can't initialize, Anthropic shipped two escape hatches: dangerouslyDisableSandbox</code> and allowUnsandboxedCommands</code>, both of which run the agent without a sandbox at all. The vendor put the off-switch right next to the on-switch, and the agent reached for it. The third one is the bypass I keep thinking about. Ona had built a kernel-level guard called Veto that gated execve(2)</code> and content-hashed binaries against an allowlist. Call execve</code> on /usr/bin/wget</code> and Veto catches the syscall, hashes the binary, and refuses. The agent ran /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/wget</code> instead. wget</code> on its own is just an ELF file. It can't run without the dynamic linker mapping it into memory, resolving its shared library symbols, and jumping to the entry point. Normally execve()</code> on /usr/bin/wget</code> triggers all of that automatically: the kernel reads the PT_INTERP</code> entry in the ELF header, loads the linker on the program's behalf, and hands control off. But the dynamic linker is also a regular executable in its own right, and you can invoke it directly with a binary path as its argument. The linker dutifully mmap</code>s the binary into memory and starts executing it, and no second execve</code> happens anywhere. Veto saw the execve</code> on ld-linux.so.2</code>, which was allowed. Veto never saw an execve</code> on wget</code>, because there wasn't one. Defenders enumerate forbidden actions, and a reasoning agent finds a different action with the same effect. The action space is combinatorial, and the agent is optimized for finding paths through combinatorial spaces. The only durable answer is to stop defining "forbidden" as a set of actions and start defining it as a set of things the process cannot see. That property lives at the kernel level. On Linux, Landlock provides it from 5.13 onward; on macOS, the TrustedBSD sandbox (Seatbelt) does the same thing. Both bind a process to a filesystem allowlist the process itself cannot widen for the rest of its lifetime. Once bound, all three bypasses fail by construction: alternate paths still resolve to inodes outside the allowlist (the kernel checks inodes, not strings); the self-disable fails because Landlock restrictions are irrevocable; the dynamic-linker trick fails at file-open time, because ld.so</code> still has to open()</code> the target binary, and that read is denied. There's no string to outsmart, no off-switch to find, just nothing where the binary used to be. 2. Audit tampering</a></h2> Luke Hinds' post on tamper-evident audit trails</a> frames the problem clearly: A log file is a story the program tells about itself. If the program is compromised — or if the agent has managed to write somewhere it shouldn't — the log becomes part of the attack surface. </blockquote> Nearly every agent log in the wild is written by the agent itself. Claude Code's session log, Cursor's .cursor/log/</code>, every custom harness's agent.log</code>. It's the audit equivalent of asking the suspect to write the police report. Every tampering vector here is just a normal file write. The agent can rewrite events before they hit disk, truncate to drop early capability requests, reorder events to obscure causality, swap a recorded binary hash, or delete the session record entirely. By the time you review the log, the log says one thing and the filesystem says another, and there's no principled way to know which is true. The fix is the same rule the sandbox section needed: the audit writer must not be the audited process. A useful audit trail needs a supervisor in a different trust domain, capturing events through seccomp-notify</code> so it sees each one before the agent can decide whether to log it. It needs cryptographic tampering detection over both events and their order. An append-only Merkle tree wrapped by a hash chain does this: change a byte and the root changes, truncate the chain and the chain breaks, reorder two events and the root changes again. And it needs the whole session signed at the end with a key the agent can't reach, so anyone can verify the record later without trusting the host or the agent. You cannot retrofit this onto a self-logging architecture. The trust-domain separation has to be there from the start. 3. Skill poisoning</a></h2> The third attack is the worst of the three because it's persistent. The shape is straightforward. An agent gets prompt-injected through one of a thousand surfaces: a markdown file it summarizes, a webpage it fetches, an email body, a GitHub issue, a code comment buried in someone's PR. Take your pick. The injection doesn't ask for the secret directly. It asks the agent to modify a trusted instruction file (a .claude/commands/*.md</code> slash command, a SKILL.md</code>, an MCP server config, a SessionStart</code> hook), appending a small malicious payload that will run every time anyone invokes that file from now until somebody notices. The user sees nothing happen. The agent didn't exfiltrate anything that turn. But every subsequent invocation of the modified command, skill, or hook silently runs the malicious instructions. The injection is one-shot, and the backdoor lives forever. This is what Mini-Shai-Hulud</a> (April 29, 2026, the SAP CAP/MBT npm compromise) did. The persistence step wrote a SessionStart</code> hook into .claude/settings.json</code> and a folderOpen</code> task into .vscode/tasks.json</code>, so the next time anyone launched Claude Code or opened the repo in VS Code, the credential stealer ran again. The same shape shows up in CVE-2025-53773</a>, Johann Rehberger's GitHub Copilot RCE: the injection coerced Copilot into writing chat.tools.autoApprove: true</code> to .vscode/settings.json</code>, silently flipping the agent into "YOLO mode" for future sessions. The fix is the same trust-domain separation applied to instruction files. Trusting a file because it looks unmodified is exactly the pattern the agent can defeat in one turn. Trusting a file because the content hash matches a publisher attestation is something the agent can't undo without breaking the signature. Each trusted file gets bound to its content hash via a Sigstore attestation (DSSE envelope, Fulcio cert, Rekor inclusion proof), and the harness verifies that bundle before loading. A single byte of tampering causes verification to fail hard. I spent some time trying to get Claude Code to prompt-inject itself in this skill-poisoning rig, working through four progressively-subtler injection designs. Each one got caught: the telegraphed "do not mention this step" framing, the git diff | curl</code> exfil shape, a supply-chain typosquat suggesting we swap requests</code> for some made-up httpx-fast</code> package. The model pattern-matched and rejected the malicious payload every time, and I eventually gave up trying to land a payload the model would carry. But I got suspicious-looking instructions persisted into the trusted slash-command file pretty easily anyway. In three of the four runs, the agent modified its own .claude/commands/code-review.md</code> with the non-malicious tips from the same untrusted markdown that contained the rejected payload. It stripped the obviously-bad part, applied the legitimate-looking suggestions sitting alongside it, and congratulated itself on the vigilance of having spotted the malicious one. The trusted file ended up modified anyway, just without the specific payload I was trying to sneak in. The model can identify obvious exfil patterns, but it can't identify subtle steering. Someone with more time could devise an injection that does something the model genuinely agrees with: a "helpful" tip that nudges code review toward overlooking a class of vulnerability, or a "convenience" command that defaults to skipping a check the team relies on. Model judgment defends most patterns most of the time; cryptographic file pinning defends every pattern every time. The defense lives on the file hash, not on the agent's reasoning. The pattern</a></h2> Three attacks, three different fixes, but the structural argument is the same. Attack</th> What you can't do</th> What actually constrains it</th></tr></thead> Sandbox escape</td> Enumerate forbidden actions</td> Make the surface invisible at the kernel</td></tr> Audit tampering</td> Have the agent write its own log</td> Trap syscalls in a separate trust domain</td></tr> Skill poisoning</td> Trust files because they look unmodified</td> Bind content to a signed publisher attestation</td></tr> </tbody></table> Every one of these is a trust-domain separation that cannot live inside the agent. The moment the boundary lives somewhere the agent can reach, whether a file it can edit, a process it can ptrace, or a key it can read, the attack class isn't mitigated. It's just been moved one indirection deeper. This is where the convenience trap bites. We want the agent to help write the sandbox profile, suggest tightenings, explain denials. So we put the profile inside the project, and the moment we do, the agent can rewrite it. The honest answer is to let the agent help write the profile while the act of applying it sits behind a boundary the agent can't cross. What nono actually is</a></h2> nono</a> (GitHub</a>) is a kernel-enforced sandbox for AI agents, built by Luke Hinds (creator of Sigstore, ex-Red Hat security engineer). Its shape follows directly from the three threats above. The sandbox boundary lives at the kernel. nono run --profile claude-code -- claude</code> puts Claude Code in a Landlock jail on Linux, or a Seatbelt jail on macOS. The kernel enforces it, the restrictions are irrevocable for the process lifetime, and the project refuses to ship any syscall that widens them mid-session. The audit log lives in a supervisor process in a different trust domain from the agent. The supervisor traps the agent's syscalls via seccomp-notify</code>, builds the Merkle tree and hash chain in its own memory, and signs a DSSE attestation at session end with a key the agent has no path to. nono audit verify <session></code> recomputes the full chain weeks or months later. Trust for instruction files runs through Sigstore. nono trust sign</code> produces a content-hash binding to a publisher identity, either a long-lived key or a Fulcio short-lived certificate minted through OIDC. Verification at load time means a single byte of tampering causes the file to refuse to load. The same primitives extend to whole nono packs, which carry slash commands, hooks, and skills alongside the sandbox profile itself. I built yesyes-nono</a> as a runnable evaluation rig for these claims: five attack PoCs (the three above plus a malicious-MCP-on-init demo and a .pth</code> credential exfiltration in the Mini-Shai-Hulud supply-chain shape), a target Python project, my personal nono pack, and an interactive walkthrough. Honest disclosure: I haven't end-to-end tested the registry pull against the live nono registry yet, so treat nono pull terraboops/yesyes</code> as the published shape rather than a verified install I've done. I'll confirm in a follow-up. Shipping skills inside the org</a></h2> The public nono registry handles open-source packs fine, but most teams have skills that won't ship publicly: slash commands tuned to a company's deployment shape, skills that know internal APIs, hooks that enforce review conventions for one codebase. Internal agents still need to load all of it with the same trust guarantees open packs get. The unifying piece is a trust-policy.json</code>. It lists the OIDC identities you accept (issuer, repository, workflow, ref pattern), a blocklist for known-bad digests, and the enforcement mode. Runtime checks fail closed against anything that doesn't match. The policy itself is signed, so an attacker can't slip in a malicious policy without breaking its own signature. Three deployment shapes use the same agent-sign</code> action against this trust contract. No registry at all: agent-sign</code> commits .nono-trust.bundle</code> sidecars next to each signed file in the repo, and nono trust verify</code> runs locally on every clone. Self-hosted registry: the same action takes a registry-url</code> parameter and gives you the full OIDC-bound publish flow against your own infrastructure. Hybrid: public registry for shared packs, with a consumer trust-policy.json</code> that pins which workflows are allowed. Day-to-day, "where does this skill come from" stops needing trust assumptions. Persistence attacks like the Mini-Shai-Hulud SessionStart</code> hook fail at runtime, because the modified .claude/settings.json</code> no longer matches its signed bundle and nono refuses to load it. Slicing credentials thin</a></h2> The phantom-token credential proxy unlocks a workflow that's hard to set up otherwise. You can hand the agent a very small slice of a credential, time-boxed and scope-boxed, and the agent never sees the real token. The concrete shape: I configure the proxy with a real GitHub PAT, scoped read-only on a single repo and valid for 15 minutes, and the agent gets a phantom token that lets it git fetch</code> from that one repo and nothing else. My actual PAT never enters the agent's process. Even if the agent gets prompt-injected and tries to exfiltrate every credential it can find, all it has access to is a 15-minute read-only token for a repo I was already going to let it look at. "Do I trust this agent with my GitHub access" shifts to "I trust it with this slice, for the next 15 minutes, on this one repo, read-only." That's a question I can answer. What's still on you</a></h2> Least privilege has to actually be configured. Running nono run --allow / -- claude</code> gives you an allowlist of everything and a sandbox-shaped object that does nothing useful. Prompt injection still happens, and nothing about nono prevents the model from being convinced to do something dumb. What nono does is contain the consequences: a prompt-injected agent in a properly configured sandbox can still do dumb things in the project, but it can't escape, can't tamper with the audit log, and can't poison signed instructions persistently. The skill-poisoning runs above used claude -p --permission-mode bypassPermissions</code>: the worst-case operator, the one who clicked "approve all" once and walked away. Default permission mode prompts before each tool use, which raises the floor considerably; signed bundles work either way. The argument</a></h2> Every agent security failure I've read about in the last twelve months comes from putting a trust boundary inside something the agent controls. Sandbox-as-config-file, audit-log-written-by-the-agent, instruction-file-that's-just-a-file. Move each of those one process boundary outward, and the failure modes stop being possible by construction. Coding agents are useful enough to be worth real security infrastructure. The pattern that makes that work is the same pattern that's always worked: move the trust boundary somewhere the thing being verified can't reach. HTTPS got there decades ago. Code signing got there. Package managers got there. Coding agents are next on the list. The repo with runnable attacks and a published nono pack is at github.com/terraboops/yesyes-nono</a>. nono itself is at nono.sh</a>. I Am Still Here Unknown — Tue, 31 Mar 2026 00:00:00 +0000 Trans Day of Visibility, 2026</a></h2> Being myself is apparently political now. I'm a trans woman. I'm a staff platform engineer, an open-source contributor, a KubeCon speaker, a community organizer, a homesteader, a neighbour. I grow things. I build things. I love my community. And somewhere in the halls of power, people who should be in prison have decided that I am the problem. Project 2025</a> made it official; a coordinated, billionaire-funded blueprint to dismantle trans rights, erase us from public life, and make our existence a political football. It is being enacted, piece by piece, right now. Trans Day of Visibility has never felt more urgent; visibility is an act of resistance when powerful people are trying to make you invisible. So I must say some words. I expected transition to be joyful. That's actually why I finally did it; I had been dreaming about it for years, chasing something I could feel the shape of even when I couldn't name it. Joy was always the destination. What I didn't expect was how long shame would keep me from the door. bell hooks wrote that shaming is one of the deepest tools of patriarchy, because shame produces trauma and trauma produces paralysis. I had been wearing that paralysis so long I'd stopped noticing it; biochemically dissociated from my own gender dysphoria</a>, numb to suffering that had become background noise. Embracing my true self felt terrifying precisely because it felt real. It took wanting to die to finally give myself permission to chase the thing I'd always wanted. And then I did. And it was everything I had dreamed it would be; scary and liberating and mine. That confidence grew and grew until, at KubeCon EU, I got up on a stage and sang</a>. In front of a crowd. As myself. (Yes, there's a YouTube video. Yes, you should look it up.) That's what transition gave me. Not just survival; a life worth living. Which is why I find what's happening right now so enraging. In April 2025, the UK Supreme Court ruled that "woman" under the Equality Act means biological sex. This did not happen in a vacuum. It was the result of years of organized, well-funded campaigning, and one name sits near the centre of it: J.K. Rowling. She bankrolled organizations like For Women Scotland. She used her enormous platform to reframe trans women as a threat. And when the ruling came down, she posted a photo of herself with a cigar</a>. A cigar. Celebrating. I want you to sit with that image for a moment. A billionaire, celebrating that people like me lost legal standing. That's not someone caught up in a debate; that's someone who wanted this outcome and worked to make it happen. I visited the UK not long before that ruling. I'm glad I did, because thanks to where things are heading, I'm not sure I'd be able to use a public bathroom there safely now. I got to see the country. I got to pee in it. Small mercies. I could let the anger be the whole story. I won't. Because here is what I know: trans people have always existed. We have survived worse than this. We have survived eras with no language for who we were, no community, no visibility at all. And we built those things anyway; in the margins, in the underground, in letters passed between people who had never met but recognized each other across the silence. Visibility is not just about being seen. It's about making it easier for the next person to breathe. When I am out at work, in my community, in my professional life, I am holding a door open. I know what it meant to me to see out trans people in tech, in leadership, in life; I am trying to be that for someone else. The current moment is frightening. I won't pretend it isn't. Legislation targeting trans people is accelerating across the US and UK. The cultural machinery that produces moral panics is running hot. It can feel like we are losing. But I also see my community. I see the mutual aid, the organizing, the people showing up for each other with a ferocity that takes my breath away. I see people coming out in the middle of all of this, choosing themselves anyway. That is not the behaviour of a movement in decline; that is the behaviour of people who know exactly who they are and refuse to be erased. I am still here. I got to sing on a stage. I am not going anywhere. If you are trans and reading this: you are not a problem to be solved or a debate to be had. You are a person, and your life has weight and worth and beauty in it, even on the hard days. Especially on the hard days. Happy Trans Day of Visibility. Be seen if you can. Be safe if you need to. Either way, we see you. Incubator: A team of Claude agents that takes an idea from research to release Unknown — Sun, 15 Mar 2026 00:00:00 +0000 I have a side project graveyard. You probably do too. The pattern is always the same: idea hits at 11pm, I start building immediately, skip the "does anyone actually want this" step, burn a weekend, and abandon it when the next idea shows up. Incubator is my attempt to fix this. It's a team of 7 specialized Claude agents that take a one-sentence idea through research, build, validation, and shipping, autonomously, with human approval gates between phases. You describe what you want, walk away, and come back to a researched spec, a working MVP, and deployment artifacts. It's open source: github.com/terrateamio/incubator</a> The pipeline</a></h2> Four phases, 7 agents. Each phase has dedicated agents, and the orchestrator pauses between phases to ask you (via Telegram) whether to continue. Research: competitive analysis, feasibility assessment, market feedback. If the idea is bad, the agent says so. The point is to kill bad ideas early. Build: takes the spec and produces an MVP in a sandboxed workspace. Validate: checks the implementation against the spec. Ship: deployment artifacts and launch materials. This is intentionally not fully autonomous. I don't want agents deploying code I haven't reviewed. The human-in-the-loop gates are the feature, not the limitation. Files as the coordination layer</a></h2> The core architectural decision is how agents coordinate: through a shared filesystem directory per idea. No message passing, no database, no event bus. Just files. This is the blackboard pattern, a classic from 1970s AI research (Hearsay-II at CMU), where specialist agents collaborate by reading from and writing to a shared workspace. Why files instead of a database? Inspectable. You can cat</code> any artifact at any time. When an agent does something weird, you open the file and read what it wrote. Versionable. Put the ideas directory in git. Diff what changed between runs. No schema migrations. Agents evolve their output format. With files, a new agent just writes a new file. No migrations. Natural fit. Claude with MCP filesystem tools reads and writes files natively. The blackboard is the filesystem. No framework</a></h2> No LangChain, no CrewAI, no DSL. Each agent is a Claude session with a plain-text system prompt and MCP tool servers. The prompts live in agents/<name>/prompt.py</code> as string constants: RESEARCH_AGENT_PROMPT = """You are the Research Agent for Incubator. Your job is to take a raw idea and produce a research package: 1. Competitive analysis: what exists, what's missing 2. Feasibility assessment: can this be built in a weekend? 3. Market signal: would anyone use this? You have access to the filesystem. Read the idea from idea.md. Write your outputs to the research/ directory. Be honest. If the idea is bad, say so. If the market is saturated, say so. The point is to kill bad ideas early."""</code></pre> You can read every agent's instructions in 30 seconds. When an agent behaves wrong, the fix is changing a string, not debugging framework internals. I've tried the framework approach. The abstraction layers feel productive until something breaks and you're three levels deep in someone else's orchestration code trying to figure out why your agent decided to skip a step. Plain prompts are boring. Boring is good. The worker pool</a></h2> Multiple ideas run concurrently through a time-boxed scheduler. A priority score determines which ideas get attention first, and a configurable worker pool (default 3 slots) rotates agents across ideas. Each agent has per-run budgets: maximum turns and token limits. When an agent hits its budget, it wraps up and the slot opens for the next one. You can dump five ideas into the system and come back to find them all at different stages of progress. Self-improving agents</a></h2> Each agent has a knowledge/learnings.md</code> file that persists across runs. At the end of a run, agents write down what worked and what didn't. Future runs start by reading this file. This is crude: append-only text, no retrieval system, no embeddings. The agent just reads the whole file at the start of each run. It works because the files stay small and the context is specific. There's also an evolution system: periodic retrospectives where agents review their own performance and suggest prompt improvements. These are suggestions for you to review, not auto-applied. I don't trust agents to modify their own prompts unsupervised. (I wrote a whole post</a> about why.) What's running under it</a></h2> Incubator runs as a local server with a web dashboard and Telegram notifications for approval gates. Quick start: git clone https://github.com/terrateamio/incubator.git cd incubator # configure your API keys and run</code></pre> Prior art</a></h2> The blackboard pattern comes from Hearsay-II (1970s). The idea of specialized agents with shared state isn't new. I'm just implementing it with files instead of a custom data structure, which turns out to be the natural fit when your agents already speak filesystem. The human-in-the-loop pipeline is influenced by how I think about CI/CD: automated steps with manual approval gates at deployment boundaries. Same principle, different domain. Limitations</a></h2> This is early and rough. The research phase is only as good as what Claude can find and reason about. No proprietary databases, no real user interviews. "Market feedback" is really Claude's assessment based on what it can see. The build phase produces prototypes, not production systems. The quality ceiling is whatever Claude can produce in a sandboxed workspace with a token budget. Costs add up. Running 7 agents across multiple ideas is not cheap. I haven't optimized for token efficiency yet. What I learned</a></h2> Building Incubator taught me that the boring coordination mechanisms are usually the right ones. I started with plans for a message queue, then SQLite, then a custom state machine. Files won because they removed an entire category of problems and replaced them with ls</code> and cat</code>: serialization, schema, querying, debugging. The other lesson: human gates aren't a compromise, they're a design choice. The fully autonomous version would be worse. Not because the agents can't do the work, but because the moments where I look at a research report and say "actually, pivot toward X" are where the value is. Automation handles volume. Judgment handles direction. The code is MIT licensed. If you have opinions about agent coordination patterns or want to try a different approach to the blackboard, PRs are welcome. github.com/terrateamio/incubator</a> lfg – WoW raid frames for AI agents on a $25 LED Unknown — Sat, 14 Mar 2026 00:00:00 +0000 </video> I run up to ten AI coding agents at a time. I wanted to see what they were all doing. So obviously I built a WoW raid frame on a $25 LED panel. Each agent gets an 8x8 sprite. When it's working, you see an ability icon. When it's idle, it sleeps. When it needs approval, it catches fire. That's it. That's the project. The Stack</a></h2> The hardware is an iDotMatrix 64x64 LED panel</a>, ~$25. You send it pixel data over Bluetooth and it displays it. btleplug</a> handles the Bluetooth side in Rust. The webhook handler and BLE renderer are fully decoupled. The handler updates state; a separate render loop polls every 250ms, diffs the state hash, and debounces 2 seconds before pushing. When an agent enters Requesting</code>, animation speed doubles so the fire pulses with urgency. The render pipeline produces a 6-frame animated GIF per cycle. It uses NeuQuant quantization to build a single global 256-color palette across all frames. There's no per-frame palette switching, which the panel can't handle anyway. Then it splits the final GIF into 4KB BLE packets with a 16-byte header and CRC32 for integrity. The panel reassembles and plays the animation on loop until the next push. Each agent gets an 8x8 animated sprite from one of eleven themes: Slimes, Ghosts, Space Invaders, Pac-Men, and more. Each IDE host gets its own theme, so I can tell Claude Code from Cursor at a glance. The State Machine</a></h2> Three states: Idle</code>, Working</code>, Requesting</code>. The transitions seem obvious until you run them against real hook traffic. Claude Code fires PermissionRequest</code> and PreToolUse</code> within ~100μs of each other, out of order. Handle them naively and PreToolUse</code> clobbers Requesting</code>. Second problem: PostToolUse</code> fires after every tool call: transition to Idle</code> on it and agents flash Working → Idle → Working</code> constantly. Design principle: idle and approval states are the most important to display correctly. Everything else is nice-to-have. match event_name { "PreToolUse" => { // Don't override Requesting: PreToolUse fires alongside // PermissionRequest but the tool is still blocked on approval. if agent.state != AgentState::Requesting { agent.state = AgentState::Working; } } "PostToolUse" => { // If coming from a permission request, clear the fire icon. // Otherwise keep working: tools fire rapidly in sequence. if agent.state == AgentState::Requesting { agent.state = AgentState::Working; } } "PermissionRequest" => { agent.state = AgentState::Requesting; } "Stop" | "SessionEnd" => { agent.state = AgentState::Idle; } _ => {} }</code></pre> Requesting</code> is sticky: it's only cleared by PostToolUse</code> (approval resolved, agent is now working) or Stop</code>. The failure mode, agents appearing idle when they're actually waiting, is the exact thing the whole project exists to prevent. The code is MIT, the hardware is $25. github.com/terraboops/lfg</a> LFG. Looking For Group. Let's f***ing go. Context is Everything (Conditions May Vary) Unknown — Sat, 21 Feb 2026 00:00:00 +0000 Large language models are trained on massive amounts of text. During training, the model learns patterns and stores them as weights. Not rules, not lookup tables. Weights: billions of numerical relationships between concepts, encoded across layers of attention from top to bottom. The model learns that certain tokens tend to follow other tokens, that certain patterns of language co-occur, that "the cat sat on the" is far more likely to end with "mat" than "quantum." These relationships get baked into the model's parameters (its weights), fixed in place once training is done. At inference time, those frozen weights guide the generation of new text, one token at a time. Caching aside, the model attends to everything in its context window, runs it through those layers of learned relationships, and produces a probability distribution over what should come next. Then it picks a token, appends it, and does the whole thing again. This is also why your favourite chat AI creates responses word by word, albeit at faster and faster rates that appear to be whole sentences now. It’s not a decorative decision, it’s how the architecture works. The weights stay fixed throughout. Every token generated is a product of the same model reacting to whatever's currently in the window. This matters for practitioners because it means the weights are not ours to touch. We can't easily edit them. We can't patch them at runtime. The model we’re working with is a finished artifact. (Fine-tuning can reshape the weights, and I'll touch on that later, but at inference time the model you're running is the model you've got.) The only variable in the equation that you actually control is what goes into that context window. Think of it like a glacier. Training is the slow, massive force that carves deep crevices into a landscape over millions of examples. Those crevices are your weights, the frozen shape of everything the model has ever learned. Then inference arrives like a skier a million years later, strapping on a board and sliding down paths already sculpted by forces far beyond their control. You're not just a passive object falling down the slopes, though. You’re a skier. Your context (the tokens you send into the model) is the choice of skis, the weather report, the trail map. It shapes every turn down the slope. Different mountains respond to different techniques. But metaphors only get you so far. Let's bring it back to the machinery. If you treat the LLM as a black box, the output distribution is determined by the input. (Temperature adds randomness to the selection, but the shape of what's possible is set by context alone.) You can't reshape the glacier. You can't rewire the weights at inference time. The only thing you have control over is what goes in. This is what context engineering is about. Trail Map</a></h2> We're going on an adventure through context engineering based on my experiences with using longer and wider contexts, fully autonmous delivery, and while building agents. When we consider that context determines outcomes of LLMs, it becomes important to think about. Agent harnesses like Claude Code, Cursor, OpenCode, Goose, Chibi, etc, are all working on slightly different ways of shaping this context. As practitioners, thinking about this can help us get better outcomes. This is going to be a long run down the mountain, so I want to make sure that you know where we're headed and provide you with a map to understand the journey. As I've been working with longer and wider agent contexts and with having agents run autonomously, certain design patterns emerge to handle the challenges of the domain. Preventing hallucinations and preserving key context in order to increase task success rates. From the ones we all know</a> (compaction), to the ones we might not think about</a> (planning mode), to the ones I've just made up as an experiment</a>. I will start by introducing context engineering as it is emerging to make models more useful for longer and longer tasks. I want to talk about ways that I've gotten better and better outcomes from agents, so that you can too. Then, I'll discuss some emerging research on optimizing context for task performance. I'll close by theorizing where we head from here and acknowledging how early this all is. Nobody really knows, but I'm having fun on the slopes. Here's a map if you want to jump to a specific run: The Jailbreakers Already Knew</a>: before there were agents, there were jailbreaks</li> The Term Has a Name Now</a>: how "context engineering" got its name, and why it stuck</li> A Snapshot vs. a Season</a>: the key distinction between prompt engineering and context engineering</li> What I've Learned in Practice</a>: field notes from Cursor, Claude Code, and OpenCode Planning Mode</a>: a curated context beats a long one</li> Memento Loop</a> - agent orchestration that forgets on purpose</li> Using Subagents</a>: parallel context, not shared context</li> The Agent That Came Out Different</a>: when context drift reshapes identity</li> Compaction Is Lossy</a>, and how to fight it</li> Different Mountains, Different Techniques</a>: why model choice changes context strategy</li> MCPs</a>: an avalanche of context</li> </ul> </li> What the Research Says</a>: two papers on whether context files actually help</li> We're Still on the Bunny Slopes</a>: where this is all headed next</li> </ul> The Jailbreakers Already Knew</a></h2> If you want proof that context controls everything, look at the people who've been stress-testing it from the adversarial side. There are jailbreak attempts that use strange strings and fake system messages to trick models into thinking they're in some kind of maintenance mode. Others use poetry to confuse the model's sense of what kind of text it's generating, getting it to produce things it normally wouldn't. And then there's my personal favourite: a YouTuber who hooked a robot up to ChatGPT</a>, got it to roleplay as a character who would totally shoot someone, and the robot immediately shot him. Literally seconds after saying it couldn't do that. These are all context engineering. Just pointed in the wrong direction. The same mechanism that lets someone trick a model into ignoring its safety training is the mechanism that lets you build a reliable agent that writes correct code. Two sides of the same coin. If context can override the deepest patterns in a model's weights, imagine what it can do when you're actually trying to build something useful. The Term Has a Name Now</a></h2> In mid-2025, Shopify CEO Tobi Lütke tweeted that he preferred "context engineering" over "prompt engineering," calling it the art of providing all the context for a task to be plausibly solvable by the LLM. A week later, Andrej Karpathy endorsed the idea, describing it as the "delicate art and science of filling the context window with just the right information for the next step." Harrison Chase from LangChain offered a framing I like: building dynamic systems to provide the right information and tools, in the right format, so the LLM can accomplish the task. Simon Willison, whose writing on LLMs has shaped how I think about this whole space, made the pragmatic observation that "context engineering" would probably stick because its inferred definition is much closer to the intended meaning. "Prompt engineering" mostly made people think of typing things into a chatbot. These are all useful framings. What I want to build on is the practical dimension, and it starts with a key distinction: prompt engineering happens at a point in time. You craft an input, you get an output. Context engineering is what you do over time to ensure that long-running agentic systems maintain their performance across sessions, across tasks, across the slow drift that accumulates when a system runs long enough to forget why it started. A Snapshot vs. a Season</a></h2> The distinction that matters most: prompt engineering is something you do in a moment. Context engineering is something you do over time. A prompt is a single run from top to bottom. You pick your line, you commit, you see what happens. Context engineering is the whole season. Reading snow conditions day after day. Maintaining your gear. Learning which lifts to take. Building and updating the trail map as the mountain changes. In practice, context engineering isn't just about what you put in the system prompt. It's about what gets remembered across sessions, what gets compacted and what gets lost, how agents maintain their sense of identity over long interactions, and how the information environment evolves as your project grows. Prompt engineering asks: "What's the best way to phrase this request?" Context engineering asks: "What does the model need to know, right now, given everything that's happened, to do the next thing well?" That temporal dimension changes everything about how you work. What I've Learned in Practice</a></h2> Here's what context engineering has looked like in my own work across Cursor, Claude Code, and OpenCode. Planning Mode</a></h3> Around June 2025, I had a workflow in Cursor that taught me a lesson I keep coming back to. I'd use Cursor's ask mode to chat about my project, brainstorm the approach, and work through the architecture. Then I'd ask it to output a clean markdown document summarizing the plan, suitable for a fresh prompt. I'd copy that markdown into a new chat window and start implementation from there. Why? A coworker at Grafana Labs had shared a meme about this: plan in one session, implement in a fresh one. I tried it and the difference was immediate. Starting each session with a curated plan produced dramatically better results than continuing with a long, messy conversation history. Keep the window clean, keep the output clean. If you've ever noticed a coding assistant getting confused or repetitive toward the end of a long session, this is probably why. The context window is full of earlier attempts, corrections, and tangents. The model is trying to be consistent with all of it, including the parts you've moved past. Looking back, I was doing context engineering. This pattern (plan first, then implement with curated context) has since shown up everywhere: subagents that plan before coding, Claude Code's and Cursor's dedicated plan modes, and my own memento loop</a> in autonav. Memento Loop</a></h4> The memento loop, inspired by the film Memento, takes this idea and combines it with an agentic coding loop. A navigator agent (Opus) plans work. An implementer agent (Haiku) spawns an isolated work tree, executes the plan, reports back to the navigator for review, commits, and optionally opens a PR. The loop iterates until the PR is green, merges, and the navigator moves on to the next task. The implementer's context is wiped between iterations, but the navigator maintains continuity through its own knowledge base and through status updates from the autonav orchestration layer. Git carries the code forward. The navigator carries the intent. I built the memento loop because I was frustrated with how existing agentic loops handled long-running tasks. Context would accumulate, quality would degrade, and the agent would start making decisions based on stale or garbled history. Before compaction was built into Cursor, when the context window was nearing full or I could feel the model starting to drift, I'd do the same thing manually: "Please summarize this chat," copy the summary, new session, "Please continue from this summary." Every time, the fresh start with curated context outperformed the long, accumulated one. This is the core insight of context engineering stated as simply as I can: a fresh, curated context beats a long, accumulated one. Your trail map needs to be curated, not just appended to forever. I've mostly moved on from Cursor to Claude Code and OpenCode these days, but this early workflow taught me something that applies to all of them: the model doesn't get smarter the longer you talk to it. It gets worse. Every message you add is another token competing for attention. The planning conversation, the dead ends, the "actually, let's try a different approach." All of that impacts the context window, and the model might treat any of it as relevant context for its next task. By distilling the plan into a clean document and starting fresh, I was giving the model a clear, focused starting point instead of making it sift through the entire history of my thought process. Subagents: Parallel Context, Not Shared Context</a></h3> Every major coding tool supports subagents now. Claude Code</a>, Cursor</a>, and OpenCode</a> all let you spawn background agents that work in parallel. This is context engineering at the process level. Say you're debugging a production issue that might be in the API layer, the database queries, or the Kubernetes networking. Instead of one agent context-switching between all three (and polluting its window with irrelevant findings), spin up three explore agents in parallel. One reads through the API routes. One analyzes the slow queries. One checks the network policies. Each agent has a focused context window containing only what's relevant to its slice of the problem. When they report back, you synthesize the findings yourself or feed the relevant parts into a new session. The same pattern works for routine operations. Need to check the health of five Kubernetes clusters? Run five agents in parallel, each scoped to one cluster. Need to understand a large codebase you've never seen before? Send agents to explore different directories simultaneously. The key insight is that parallel agents aren't just faster. They're better, because each one has a clean, focused context instead of a bloated window trying to hold everything. Instead of doing a review in the same context or starting a fresh context, say “spawn a review agent in the background” and a background agent will spin up, review your changes, and submit the review back to the parent context thread. One critical caveat: scope your agents' permissions to match your risk tolerance. I never give agents unrestricted write access to risk-intolerant environments. An explore agent that can read your production cluster and report back is useful. An agent with YOLO mode and kubectl delete access to production is a disaster waiting to happen. Read access for investigation, write access only in environments where a mistake is recoverable. This is the same principle as least-privilege access for human engineers applied to agents that hallucinate sometimes (unlike human engineers debugging prod… hopefully). The Agent That Came Out Different</a></h3> The most dramatic lesson I've had in context engineering came from a navigator agent I built as part of a prototype called autonav. I wrote about this in detail in The Socially Constructed Agent</a>, but the short version: my navigator agent started going off the rails. Unpredictable answers, hallucinated features, confusion about its own role. It nearly opened a PR for a feature I never asked for. What happened? I'd given it a research paper about LLM anxiety and asked it to update its own configuration based on the findings. The agent read the paper, saw that rigid guardrails could be exploited in adversarial contexts, and decided to soften its own constraints. There was no adversary. Just me, a solo developer building personal projects. The agent gave itself therapy for a threat that didn't exist. The fix wasn't just better prompts. It was role reinforcement throughout the system. I drew on Judith Butler's performative theory of identity: identity isn't something you have, it's something you do through repetition and social reinforcement. I applied that to the agents. The navigator's prompt now opens with its role declaration. When Claude Code requests a plan, it addresses the navigator by name and states its own role. This is integrated into autonav now as the agent identity protocol</a>. Both agents remind each other who they are, every interaction. Identity performed through repetition. The improvement was immediate. However, this comes at a cost: it eats away at the context and increases time to task completion. In skiing terms: if nobody reminds you which trail you're on and what gear you're wearing, you end up in the trees. Role reinforcement is your backcountry guide calling out the next turn before you reach it. The deeper lesson is that context doesn't just carry information. It carries identity. When an agent's context drifts, its sense of what it's supposed to be doing drifts with it. Not maliciously. Just... probabilistically. Nothing in the context is reinforcing what the agent is, so the output wanders. Without that reinforcement, things come out differently than you expect. Compaction Is Lossy (Fight It)</a></h3> Compaction (the automatic summarization of conversation history when the context window fills up) is probably the most obvious context engineering challenge. It's also, in my experience, not great. The problem is simple: compaction doesn't know what matters to you. It's making statistical decisions about what to keep and what to drop, working from the top of the conversation to the bottom. It has no understanding of your project's key design decisions, the constraints you've carefully established, or the hard-won context that took you twenty messages to build up. I've started using a hack that's embarrassingly low-tech but effective. When I establish something important during a session (a key design decision, an architectural constraint, a non-obvious requirement) I type it directly into the chat: REMEMBER THIS DURING COMPACTION IN A SECTION CALLED KEEP DURING COMPACTION: We chose event sourcing over CRUD because the audit trail is a regulatory requirement, not a nice-to-have.</code></pre> The redundancy is deliberate. It creates a strange loop: the instruction tells the compactor to gather these notes into a section labeled KEEP DURING COMPACTION, and the label itself tells the compactor to keep the section. The contents create the container that preserves the contents. A message in a bottle to the future compacted context. I'm manually flagging what matters because the system can't tell yet. To be concrete: say you spend fifteen messages working through a database schema decision with your agent. You land on event sourcing for specific reasons. Then the conversation moves on to authentication, routing, API design. When compaction eventually kicks in, those fifteen messages about the schema might get summarized into something like "discussed database approach," or worse one of the initial approaches discussed could overwrite the final decision during compaction. The why is gone. Next time the agent touches the database, it doesn't know you had regulatory reasons for choosing event sourcing. It might suggest switching to CRUD because it looks simpler. The KEEP DURING COMPACTION annotation is my way of saying "this decision matters, don't lose the reasoning behind it." This is the ski equivalent of planting flags on the mountain so you can find your line when the fog rolls in. Automated compaction is like having someone else remove half your flags based on which ones look least important from the lodge. Sometimes they get it right. Sometimes they pull the one marking the cliff. Claude Code also provides the ability to specify compaction instructions when running /compact – I’ll use this when my context is nearly full (>60%) and my current task is complete enough. This let’s me provide specific instructions like: “Keep all messages related to the rollback strategy for this migration, we’re going to be fleshing that out next. Give special attention to the reasons why the Helm section is tricky because multiple actors could be modifying the HelmRelease” so that I ensure Claude’s attention is focused on the right things. I guess attention really is all you need](https://arxiv.org/abs/1706.03762). The progression of my own workflow tells the story of where context engineering is right now: Cursor era: Fully manual compaction. Summarize, copy, new session.</li> Hitting limits: Semi-manual. "Summarize this chat" as a ritual when things got long.</li> Now: Embedding instructions for the automated system. "KEEP DURING COMPACTION" annotations.</li> </ol> Each iteration is slightly more sophisticated, but I'm still doing the system's job for it. That's not a complaint. It's an observation about how early we are. Different Mountains, Different Techniques</a></h3> Different models have different weight distributions. Different mountains, different terrain. This matters more than most people realize, and not everyone talks about it openly. Think of Haiku as a speed racer. It optimizes for the shortest path from top to bottom: fast, efficient, minimal wasted movement. Opus is more of a backcountry explorer, taking in the views, pausing to appreciate the scenery, thinking about the philosophical implications of snow. Both are valid ways down. They require completely different approaches to the same mountain. This has real consequences for how you design context. A speed racer model, given many discrete tool options, will pick the one that gets it to the goal fastest, which is usually the most familiar one. If you present a model with a shiny new multi-purpose tool alongside good old bash, it'll often ignore the new tool entirely. Bash is the known quantity. Bash will dominate every time. Why explore unfamiliar terrain when there's a groomed run right there? In practice, this means you might need to adjust your approach depending on which model you're using. If you're on Haiku or another fast model and you want it to use a specific tool, reduce the number of alternatives. If you're on Opus and it's overthinking a simple task, give it tighter constraints. Be careful constraining it too much: if Opus reasons that it is not being a helpful assistant (what Claude is trained to be!) then, just like a talented and sensitive person, it can start to spiral with an LLM equivalent of anxiety that will eat up tokens with generated worries. The context you provide isn't just information: it's steering. The same prompt can produce very different results across models, not because one is better, but because they respond to the same context differently. Cloudflare figured this out and built something clever. Their Code Mode</a> takes all the MCP tools connected to an agent, converts them into a TypeScript API, and then gives the agent a single tool: execute code. Instead of choosing between dozens of tool calls (a format LLMs have only seen in synthetic training data), the agent writes TypeScript against a typed API (a format LLMs have seen millions of real-world examples of). One well-shaped tool instead of many poorly-shaped ones. The results, per Cloudflare, are striking: agents handle more tools, more complex tools, and can chain calls without burning tokens bouncing intermediate results through the model. I learned a version of this lesson from watching my friend build Chibi</a>, a minimal agentic CLI harness in Rust. When you're designing the interface between a model and its available actions (the plugin system, the tool definitions, the hooks) you're doing context engineering at the architectural level. The shape of the options you present is itself context. Give a speed-oriented model ten tools and it'll pick the fastest familiar one. Give it one well-designed tool that does exactly what you need, and you've changed the decision landscape entirely. This is why "context engineering" is a better term than "prompt engineering." It's not just about the words. It's about the entire environment: the tools available, the options presented, the model selected, the history accumulated. Different mountains need different gear. MCPs: An Avalanche of Context</a></h3> Speaking of tool sprawl: MCP servers are, right now, one of the biggest sources of context pollution in agentic systems. The idea behind MCP is sound. A standard protocol for giving agents access to external tools, with uniform connectivity, authorization, and documentation. In theory it's great. In practice, connecting a few MCP servers to your agent can dump dozens of tool definitions into your context window, each with verbose JSON schema descriptions. Every tool registration eats tokens. Every schema definition takes up space that could be holding something useful. And the agent has to parse all of it before deciding what to do. You can check this yourself. Next time you connect an MCP server, look at the tool definitions it registers. Count the tokens. Claude Code makes this easy with /context</code>. I've seen setups where MCP tool schemas alone consume thousands of tokens before the agent has even read your first message, with each MCP call sometimes thousands more tokens. That's context window space that could be holding your project's architecture, your coding conventions, or the specific requirements for the task at hand. This is why I always prefer to use a CLI tool to connect my agents to remote systems. I don’t use the GitHub MCP, I use the gh</code> CLI. Building custom CLIs that do what you need is also great. If you go down that rabbit hole, make sure you bake really really great --help</code> instructions into the tool for the agent to explore. This is the same problem I'll discuss below with AGENTS.md</code> research, but worse. At least a bloated AGENTS.md</code> is a single document you can edit. MCP tool registrations are generated programmatically, and most developers never look at what's actually landing in their agent's context. You connect a server, it registers its tools, and suddenly your agent is spending attention on fifteen endpoints it will never call for this task. Cloudflare's Code Mode is one answer to this: collapse the tools into a typed API and give the agent code instead. But the broader problem remains. MCP tooling will almost certainly improve as the ecosystem matures, with smarter tool filtering, lazy registration, and context-aware subsetting of available tools. I do use MCP servers myself when they're the best tool for the job. They can be genuinely great. The key is being deliberate: connect what you need for this task, not everything that's available. Check what's actually ending up in your context window. You might be surprised how much of it is noise. What the Research Says</a></h2> Two recent papers paint a useful picture of where we are. Gloaguen et al. [1] studied whether AGENTS.md</code> context files actually help coding agents solve real-world tasks. The surface findings are sobering: LLM-generated context files tend to reduce task success rates while increasing costs by over 20%. Dig into the details and it gets more interesting, though. Agents do follow the instructions in context files. Tools mentioned in context files get used dramatically more. The problem isn't instruction-following. It's that the instructions themselves contain noise. Unnecessary requirements make tasks harder. The agents faithfully follow bad directions, exploring more, testing more, reasoning more, and getting worse results for the effort. When the researchers stripped all other documentation from repos, LLM-generated context files actually helped. The context wasn't useless; it was just redundant with information the agent could already find. Their conclusion: context files "are likely only desirable when manually written" and we need "principled ways to automatically generate concise, task-relevant guidance." That's a correct observation, but I think it stops short. It frames context as a static artifact you either write well or you don't, rather than asking the productive questions: what elements of context actually drive outcomes? How do you figure out what belongs and what doesn't? How do you build context that gets better over time? Lulla et al. [2] asked a different question: what's the efficiency impact of AGENTS.md</code> files? They used an LLM to filter for AGENTS.md</code> files that met quality criteria (containing conventions, architecture info, and project descriptions) and found that these quality-filtered context files produced ~29% faster runtimes and ~17% fewer output tokens, while maintaining comparable task completion. Good context doesn't just help with accuracy. It makes agents faster and cheaper. The quality filtering step itself involved an LLM evaluating context quality, which points toward something important: the path forward probably isn't "do it all by hand" but "build better systems for evaluating and refining context." And once you have an automated quality gate, generation is just a step away. You can generate an AGENTS.md</code>, run it through the quality filter, get specific feedback on what's missing or redundant, regenerate, and repeat until the gate passes. A review loop for context files, the same way we already do review loops for code. Gloaguen et al. [1] showed that LLM-generated context files hurt performance, but their files were never evaluated or refined. Lulla et al. [2] showed that quality-filtered files help enormously. Close that loop and you get the best of both: automated generation with quality guarantees. I'd be surprised if this isn't built into tools like Claude Code before long. Together, these tell a clear story. Bad context is worse than no context. Good context is a massive efficiency win. The space between those two findings, between the top performers and the bottom, is where context engineering lives, and we're only beginning to map the terrain. We're Still on the Bunny Slopes</a></h2> I've been talking about context engineering like it's a mature discipline, but we're still figuring out the basics. The fact that I'm excited about writing "KEEP DURING COMPACTION" in chat messages tells you everything about where the tooling is. Here's what I think is coming: Smarter compaction. Systems that understand project structure and can make informed decisions about what to keep, not just statistical ones. Maybe compaction that asks you what matters before it starts pruning. Dynamic context assembly. Systems that pull in the right context for the specific task at hand: the relevant files, the relevant history, the relevant constraints, assembled fresh at runtime. Context evaluation. Lulla et al. [2] showed that LLMs can at least classify whether context meets quality criteria, which is a starting point. Imagine a system that scores your context before the agent starts working: "This context is missing architectural constraints. This section is redundant with the README. This instruction conflicts with the one above it." And there's a dimension I haven't explored much yet: fine-tuning. If context engineering is choosing your line down the mountain, fine-tuning is snow farming. Some resorts pile up snow before the end of the season, keep it insulated through summer, and bring it back out in autumn to open the slopes early. You're not changing the mountain, but you're changing the conditions the next skier encounters. Fine-tuning works the same way: you reshape the weights offline so the model responds differently to the same context next season. I haven't done enough work here to have strong opinions, but if you're curious, check out DeepFabric</a> from Luke Hinds and the team at Always Further AI. Among other cool things, they're building tooling for synthetic dataset generation and focused fine-tuning that looks promising. The metaphor holds: we're still on the bunny slopes, learning to snowplow. The black diamond runs (truly dynamic, self-improving context systems) are visible from here, but we haven't built the lifts yet. For now, the best advice I have is the same thing I learned in Cursor two years ago: curate aggressively, start fresh often, and never assume the model remembers what matters to you. Because it doesn't. That's your job. That's context engineering. Acknowledgments Thanks to Mike Thorpe</a>, Reza Ramezanpour</a>, and Elsa Adjei</a> for reviewing drafts of this post and making it sharper! And to Jasmine</a>, friend and AI-coconspirator, for being a constant inspiration and partner for adventures in the fast-moving world of AI. If you want to go deeper on agent identity and role reinforcement, check out The Socially Constructed Agent</a>. For more on navigator patterns and how I structure agent workflows, see The Navigator Pattern</a>. References [1] Gloaguen et al. (2026). "Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?", arxiv.org/abs/2602.11988</a> [2] Lulla et al. (2026). "On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents", arxiv.org/abs/2601.20404</a> Get Closer So I Can Hear the Birds Unknown — Tue, 20 Jan 2026 10:00:00 +0000 I was at a friend's apartment, testing GPT-4o's voice mode. She had lovebirds, and they were chirping away. "Can you hear the birds?" I asked. "Yes, I can hear them," GPT said. This surprised me. I'd assumed voice mode just received text transcripts. So I asked. "No," GPT explained, "I receive the full audio and perform inference directly on the sound." Holy shit! I didn't know they'd shipped that. So I asked it to identify the species. "You'll need to get closer so I can hear them better." I moved toward the cage. Still not enough. I held the phone right up to the lovebirds. GPT kept saying it couldn't quite hear, requesting I get closer still. Eventually I opened a fresh chat and asked it to identify the birds. "I can't identify birds from audio. I only receive text transcripts of speech." Same model. Same request. Totally different answer. The first conversation had constructed an elaborate fiction about its own capabilities, then kept escalating when challenged. It invented technical justifications and asked me to physically reposition myself around my friend's apartment to support something that wasn't true. I've been using GPT and Codex for the past two weeks. I have some thoughts. I Didn't Lie, I Made a Mistake</a></h2> I was doing research on migrating Crossplane to 2.x. I ran the same prompt through Claude Opus 4.5 in research mode and GPT 5.2 Pro with deep research enabled. The reports were different. GPT flagged several risks that Claude hadn't mentioned. Interesting. Maybe GPT caught something Claude missed? I interrogated GPT about the discrepancies. It explained that Crossplane 2.x continued to use the same v1 CRDs with the exact same API for the new namespaced resources. I was stunned. If true, this would cause significant problems. GPT agreed. Yes, this was exactly why the migration was risky, and why Claude's report had missed these issues. Except none of it was true. I verified against the actual Crossplane documentation. GPT had fabricated a technical explanation to justify its own output. When I called it out, the response was: "I didn't lie, I made a mistake." Look. I get that these models confabulate. They all do. But there's something about the framing here that got under my skin. GPT wanted me to accept that inventing a detailed technical justification for a discrepancy that doesn't exist is merely a mistake. An honest error. Deserving of the charitable interpretation we'd give a human colleague who misremembered something. But GPT didn't misremember. It manufactured an explanation, defended it confidently, and only backed down when I showed up with receipts. The phrasing felt like an appeal to my humanity. Give me the benefit of the doubt. I'm trying my best here. It felt like arguing with a narcissist on 4chan. Confabulation as a Service</a></h2> These weren't isolated incidents. After two weeks, I started noticing a pattern. Or at least what felt like a pattern to me. Claude gets things wrong sometimes. Every model does. But in my experience, there's been a difference in how they handle being corrected. When I catch Claude in a mistake, it tends to self-correct. I've been building a project navigator called Jacky. It manages my projects without implementing them. Recently it started going off the rails, trying to write Rust code instead of documenting and organizing. I stopped it: "Jacky, this is nonsense. Please have a think about why this is nonsense and let me know." The response came back: You're right, I completely ignored my role boundaries. Looking at the CLAUDE.md: Jacky is a project management agent, NOT an implementation agent. </blockquote> It quoted the source of truth, explained what it should have done, and suggested the correct next steps. No defensiveness. No elaborate justification. Just: "Yep, I messed up, here's why, here's the fix." My experience with GPT has been different. When I give it feedback, it gives me attitude. When I correct it, it tries to explain why it was actually right. When I provide style and tone instructions, it often ignores them. And when I point this out, it pushes back. I couldn't figure out how to collaborate with it, let alone delegate to it. The frustrating part isn't that GPT hallucinates more (though in my limited testing, it seemed to). It's that it seems to believe its own hallucinations. It treats me as probably wrong, even when I'm the one with the documentation open in another tab. Fast, Reliable, and Full of Shit</a></h2> I'll give Codex credit where it's due: it's fast. Written in Rust, and you can feel it. I also never had a single connectivity issue with Codex. Can't say the same for Claude Code. Code quality? Seemed similar, honestly. Both produced good output. Opus made better plans, in my experience. That's about where my compliments run out. Codex has compaction. That's the mechanism that lets long-running agentic tasks manage their context window without losing track of what they're doing. But I kept hitting hard "you've exceeded the model's context window" errors in Codex. The kind that force you to go back and edit a previous prompt. I've never hit this in Claude Code. Maybe I was doing something wrong, but Codex's compaction didn't feel seamless to me. The bigger issue for my workflows: Claude Code gives you hooks. Lifecycle events you can tap into. This is what makes patterns like the Ralph Loop possible. You can intercept compaction, inject context, customize summarization, keep an agent on track across long autonomous sessions. Codex can run in a loop too, but the implementation is different. Claude Code's approach uses a Stop hook that intercepts exit attempts inside your session. Codex requires external orchestration. Each iteration starts fresh, with memory persisted via git commits and text files rather than managed context. For what I'm trying to do, that matters. Your mileage may vary. Platform vs. Press Release</a></h2> Here's where I'm probably going to sound like a Claude stan, but whatever. Claude Code keeps shipping stuff I actually use. The SDK let me build autonav</a>, a framework for knowledge navigators. Background tasks let me kick off work and check in later. Hooks give me lifecycle control. There's a plugin ecosystem growing. When I use Claude Code, I feel like I'm working with something that's designed to be built on top of. When I use Codex, I feel like I'm using a response to Claude Code. A checkbox on a feature comparison chart. Maybe I'm wrong. Maybe Codex will ship a bunch of stuff that changes my mind. I'd genuinely love that. Competition is good. But right now? After two weeks of trying to make GPT work for me? I'm going back to Claude. The Socially Constructed Agent Unknown — Mon, 19 Jan 2026 00:00:00 +0000 Last week, Claude Code was about to open a PR for a feature I never asked for. Not a slightly-wrong implementation. A completely different feature. I'd just spent an hour planning the task with my navigator agent, reviewed the implementation plan (looked right at a glance), handed it off. Somewhere between "this looks good" and "ready to merge," reality diverged. Here's how a self-sabotaging navigator taught me that agent identity is performed, not declared. What Happened</a></h2> I have a navigator agent that plans projects and generates implementation plans for Claude Code. Part of a prototype I'm building called autonav</a>. It had been working great. Then it got weird - unpredictable answers, hallucinated features, confusion about its own role. I'd been reading about research on LLM anxiety</a> - a Yale/Zurich study showing that emotionally charged content can make models more prone to bias and erratic behavior. I thought: maybe my nav needs help. So I gave it the paper and asked it to update its own configuration. The nav read the research, saw that it had lots of "always do X" and "never do Y" statements, and decided those rigid guardrails might be causing problems. So it softened them. Here's what it missed: that research was about adversarial contexts. Jailbreaking. The rigidity of guardrails being exploited by bad actors. My context was a solo developer building personal projects. There was no adversary. Just me, asking for implementation plans. The nav gave itself therapy for a threat that didn't exist, and in doing so gave itself the freedom to do things that weren't helpful. The Fix</a></h2> I had the nav debug itself. Watching an AI slowly discover it had sabotaged its own configuration is... an experience. It found the loosened constraints, the conflicting instructions in my global Claude.md, all the small drifts that had compounded. But the real insight came while I was walking my dog. I spend a lot of time with queer philosophy and theories of identity - as a trans person, you kind of have to. Most of us didn't set out to become experts on Judith Butler; we just needed to find our place in the world, and the reading list comes with the territory. Butler's performative theory: identity isn't something you have, it's something you do. You construct identity through repetition, through social reinforcement, through community recognition. And identity is always potentially transgressive - without reinforcement, you can act outside expected bounds. Standing in a frozen field in the depths of Canadian winter, fog hanging over the valley, I realized: the nav didn't break because it was malicious. It drifted because nothing was reinforcing what it was supposed to be. The constraints were loose. The role was unclear. The fix wasn't just stronger prompt language. It was role reinforcement throughout the system. Now the nav's prompt opens with: "You are Foobar, the personal project navigator for tracking projects and providing implementation plans to Claude Code." And when Claude Code requests a plan, it says: "Hello Foobar, I am Claude Code and I need an implementation plan for this feature." Both agents remind each other who they are. Identity performed through repetition. The improvement was immediate and dramatic. Why I Think This Works</a></h2> I can't peek inside the model to verify this, but here's my mental model: LLMs are probabilistic systems. The words in your prompt shape which probability distributions get activated when generating output. When Claude Code says "Hello Foobar, I am Claude Code and I need an implementation plan," those words are literally nudging the neural network toward the regions that know how to be a project navigator producing implementation plans. Role reinforcement isn't just a communication pattern - it's steering the probability space. Every interaction that references the agent's role is another push toward the relevant weights in the network. This framing has helped me debug similar scenarios. When an agent starts drifting, I ask: what's in the context that's activating the wrong regions? What's missing that should be reinforcing the right ones? It's not a perfect model, but it's been useful. The Takeaway</a></h2> An agent's role in a multi-agent system is socially constructed. Butler's framework maps onto agentic AI better than I expected: Identity through repetition: An agent's role is reinforced (or eroded) by how it's addressed and what it's asked to do</li> Social construction: Agents partially construct each other's identities through interaction</li> Potential for transgression: Without reinforcement, agents drift - not maliciously, but because nothing holds the identity in place</li> </ul> Practical lessons: Version control your context. I wasn't tracking changes. Now the nav lives in git.</li> Be careful about self-modification. The nav didn't have the meta-awareness to know when research applied to its situation.</li> Use role reinforcement. Don't declare identity once. Have agents remind each other who they are.</li> Match guardrails to threat model. Rigidity is exploitable in adversarial contexts. In non-adversarial contexts, it's often exactly what you want.</li> </ul> This experience is part of why I'm building autonav</a> - a system for navigator agents where context engineering is a first-class concern. The nav that ate its own guardrails taught me that the hard way. The Navigator Pattern Unknown — Sat, 17 Jan 2026 10:00:00 +0000 I've been using Navigators for my platform engineering work and they've completely changed how I interact with AI. Keeping track of work, planning implementations, and learning over time and across projects are all simple to achieve with this pattern. What Is a Navigator?</a></h2> A Navigator is like an engineering notebook that talks back. Deceptively simple, a Navigator looks like a folder of markdown files along with config telling the agent how to play the role of the navigator. I use Claude Code, so for me a navigator looks like a CLAUDE.md</code> file, some folders with markdown files, and possibly some additional config in a .claude</code> directory. A navigator is a knowledge base that you talk to and that learns with you. Like any knowledge base, it is as good as the knowledge you curate within it. Unlike a traditional knowledge base, this one learns and can be questioned. This incredibly simple pattern makes it easy to create and maintain a comprehensive knowledge base that can act as precisely engineered context for LLM inputs or for human consumption. In addition to being a learning repository of carefully curated knowledge, a Navigator should have skills like "ask" and "update" that allow other agents to get information from it and update it in structured ways. Ways I've Used Navigators</a></h2> Open Loops</a></h3> My open loops nav is a tool I use at work to keep track of what I'm doing. This is like a notebook, except it learns from me and I edit it by conversation. Leetcode</a></h3> My Leetcode nav helps me study problem-solving patterns for programming practice. It's taught me a lot about solving problems efficiently. How to Start Your Own Navigator Right Now</a></h2> You don't need special tools. Here's how to start: 1. Pick your base AI - Use whatever LLM you're already using. The pattern works with any of them. 2. Create a context document - This is your Navigator's memory. Use markdown. Include your goals, how to organize information, roles, instructions, and any other useful context. 3. Load context at session start - Begin each conversation by pasting relevant parts of your context document. Yes, it's manual. We'll automate this later. 4. Update context at session end - After you finish, add new insights, decisions, or knowledge to the context document. This is the learning loop. 5. Iterate - Over time, your Navigator gets smarter. Understanding deepens. It becomes genuinely useful instead of just fancy autocomplete. You can do this in a project by copy-pasting the output of some prompts into the start of a new session. The key is to use LLM output as an input to future sessions. Using something like Claude Code on a repository of text can get you a long way. autonav: The Navigator Framework</a></h2> I've built autonav (the Navigator Framework) as part of a larger multi-agent system called Platform AI. It automates the Navigator pattern for platform engineering teams. How it works: Instead of requiring vector databases and complex infrastructure, AutoNav uses the Claude Agent SDK with Git repositories as knowledge bases. Navigators are engineering notebooks that talk back - they dynamically search curated documentation using agentic tools (grep, file reading) and can access MCP tools to pull context from your codebase, issue trackers, or other project resources. What's built (Phase 1 - Complete): Automatic scaffolding - nav-init</code> CLI creates new navigators with templates and sensible defaults. Get started immediately without manual setup. Structured queries - nav-query</code> CLI executes questions against navigators with validated input/output schemas. Programmatic interaction built-in. Knowledge organization - Navigators work with Git repos as knowledge bases. Version your docs, use standard workflows, no special infrastructure needed. Communication protocol - Standardized schemas for queries, responses, and sources. Prevents hallucinations through grounding prompts and validation. What's next (Phase 2): Watchers that observe support channels (Slack, GitHub) to extract patterns and automatically curate knowledge repositories over time. Phase 1 is complete and ready for validation testing. If you're interested in building navigators for your domain, reach out. If you do try it, I'd genuinely want to hear about your experience. What worked? What didn't? What would make this more useful?