@adlrocha - The Context Bootloader

Or how to keep your agent’s context fresh as mint as they loop

Back in January I wrote about my “Spec-Test-Lint” workflow and ended it with a small promise: I wanted to start tinkering with remote development environments. I was thinking then about setting something up that would let me run agents while I slept

Spoiler alert: I went down that route. It took me longer to write about what I ended up building, but this post is that update you deserved describing how my way of working with agents has changed since then (a time when the loop engineering term hadn’t been coined yet, and agents weren’t as cool and smart as now).

“But before you get into that, what was the infrastructure that you decided to build to run your agents?” Glad you asked. Nothing fancy. That Strix Halo-based device that I’ve been talking so much about? I promoted it into my remote development environment. All my agents and local models run there, and I use it from all of my devices on the same Tailscale network. This allows me to start some work from my workstation, continue from my laptop, and then ship it from my phone.

But let’s jump into what I wanted to talk about today.

Loading the right context at the right time

There’s a behaviour I’ve seen recurrently happening on my agent sessions. I ask an agent to make a decision or implement a feature in one of my repos, it gives me a confident answer, and the result is wrong. Not because the implementation itself is wrong or hallucinated, but because it was under-informed and it implemented the wrong thing. The document that had the answer was sitting in the same repository, four directories down, but nothing in the session told the agent to go and read it.

The instinct is to fix the issue with a better prompt. But I tried, and I can tell you that that instinct is wrong, inconsistent and error prone. You shouldn’t have to explicitly tell the agents where to look to get the right context (because we are humans, and we ourselves may forget), agents should be able to seamlessly find their way.

The other instinct is even worse: put everything in AGENTS.md. That has a name now, context cramming, and you end up with every lesson and convention and edge case in one enormous instructions file (like a constitution), with the model’s attention spread across it like a thin layer of butter. Garry Tan’s CLAUDE.md reached 20,000 lines before Claude Code itself told him to trim it down. The fix was a 200-line routing file that pointed at documents instead of containing them. That routing layer (that I’ve been using for half a year already on my Malone suite), is one instance of what I think is the right solution.

Dex Horthy, who (allegedly) coined “context engineering”, has a name for what happens when you overfill a context window: the dumb zone. Even models advertising a million tokens of context do good work up to roughly 300-400K, and smaller models fall over somewhere around 100K. Past that, in his words, they start doing “increasingly stupid things like deleting your .env file”. Attention is (generally) quadratic. Every irrelevant token you load is paid for twice, once in money and once in the model’s ability to think.

So loading context you don’t need isn’t just untidy. It actively makes the agent worse. That reframes the whole problem. The goal is to give the agent the right thing at the moment it needs it, not to give it everything. When I realised this, I found myself using /new in my agent sessions more and more and being more diligent about tracking and inspecting the context I was using.

The context bootloader

The pattern I landed on, and that now sits at the top of every AGENTS.md I write, is a context bootloader.

The idea is simple. The first thing the agent reads is not context, it’s a routing table. Given what the user just asked for, which expert or domain does this belong to, which manifest should you open, and what’s underneath that manifest. The agent descends only as far as the task requires. Most sessions touch two levels. Some touch three. Nothing loads the whole tree, because the whole tree is exactly what puts you in the dumb zone (don’t trust me, ask Garry and his Bible-length claude.md).

As mentioned above, the first place where I started using this routing approach was in malone-suite, my personal decision-making repo. Its AGENTS.md is 209 lines containing no domain knowledge at all: routing rules, a table of four experts, and the traversal contract. Each expert has a manifest of 40 to 55 lines listing what data files exist, what commands are available, and when you’d want the full ruleset. Only below that is there any actual content. A session about my portfolio never loads the newsletter context. A session about a post never loads the finance data.

And this is an architecture that I am starting to implement in all of my projects (personal and professional). Think of a project that along with its codebase it ships all the context agents needed to navigate it and implement new features into it (with information about its architecture, design decisions, testing approach, specs, anything you think can be relevant for agents or other engineers).

The reason I keep calling it a bootloader is because it reminds me of the operating system bootloader. A machine powers on and runs POST, a self-test, before it trusts any of its own hardware. Stage 1 of the boot process is tiny and does almost nothing except know how to find and load stage 2. Firmware enumerates devices and probes for drivers so the system knows what it’s got. The kernel comes up, and userspace gets paged in lazily, only when something actually touches it.

Every one of those maps onto something an agent session needs. The self-test becomes a freshness check on the indices. Stage 1 loading stage 2 is AGENTS.md loading an expert manifest. Device enumeration is pinging the MCP servers and tools the task is going to need, so you find out at second three rather than minute twenty that the thing you need isn’t connected. Demand paging is the agent opening a specific section of a ruleset when it hits a question that requires it.

Obviously this analogy is not a perfect match (but I love it in any case) A real bootloader runs a fixed sequence once and hands control to the kernel, and it’s done. An agent’s loader gets re-entered constantly, is navigated according to the agent’s needs, and it can’t know what hardware it’s booting for until the user says something. That makes it much closer to demand paging with a routing table than to GRUB. It’s a loader that never finishes loading.

The pattern isn’t mine, by the way. I arrived at it by trial and error and then found it already had a name, resolver. But let’s be pragmatic and let me illustrate what I am talking about with the tree structure of my malone suite (I didn’t want to share an example of one of my projects that use the context bootloader, let me know if you want me to share something privately).

├── AGENTS.md

├── CLAUDE.md

├── context

│ ├── decision-frameworks.md

│ ├── economy-thesis

│ │ ├── 00_project_thesis.md

│ │ ├── 01_study_guide.md

│ │ ├── 02_system_blueprint.md

│ │ └── 06_hierarchy_of_balance_sheets.md

│ ├── economy-thesis.md

│ └── INDEX.md

├── experts

│ ├── jim

│ │ ├── archive

│ │ ├── docs

│ │ ├── drafts

│ │ ├── EXPERT.md

│ │ ├── ideas.md

│ │ ├── INDEX.md

│ │ ├── metrics.md

│ │ ├── samples

│ │ └── style_guide.md

│ ├── malone

│ │ ├── action_plan.md

│ │ ├── datalake

│ │ ├── decisions_backtest.md

│ │ ├── decisions.md

│ │ ├── docs

│ │ ├── expenses.yaml

│ │ ├── EXPERT.md

│ │ ├── INDEX.md

│ │ ├── investors

│ │ ├── portfolio.yaml

│ │ ├── queries

│ │ └── themes.md

│ ├── pam

│ │ ├── archive.md

│ │ ├── contacts.md

│ │ ├── docs

│ │ ├── EXPERT.md

│ │ ├── ideas.md

│ │ ├── INDEX.md

│ │ ├── reading_list.md

│ │ └── tasks.md

│ └── wiki

│ ├── docs

│ ├── EXPERT.md

│ └── INDEX.md

├── knowledge

│ ├── brag-doc.md

│ ├── compute-prices

│ │ └── README.md

│ ├── INDEX.md

│ └── wikis

│ ├── financial-system

│ ├── llm

│ ├── networking

│ ├── onchain-finance

│ ├── web-engineering

│ └── world-order

├── README.md

The freshness problem

Of course, it is not all gold that glitters (I always loved that idiom). My first implementation started failing after a few weeks of use.

The catastrophic failure of this system is an agent that doesn’t load context which exists, because the index didn’t mention it. That produces exactly the confident, under-informed answer I started this post with, except now you’ve built a whole architecture that convinced you the problem was solved.

Stale indices rot on a predictable schedule. Day 1 your routing table is perfect. Day 30 you’ve added three things without updating it. Day 60 the trigger descriptions no longer match the words you actually use when you ask for things. Day 90 the routing table is a historical document describing a repo that no longer exists.

There’s a tell for this, and it’s you. You start routing by hand. You stop asking “update my portfolio” and start saying “open experts/malone/portfolio.yaml and update it”, because at some level you know the system won’t find it on its own. You’ve become the router and the bootloader is now decoration.

So the rule I enforce, and it’s the highest-priority line in my AGENTS.md: if you add, remove, rename, or materially change anything under an indexed directory, you update that index in the same change. The agent is responsible to always keep all the documentation and index fresh. I don’t trust myself to hold to that, there’s a script, check-indices.sh, that walks the tree and flags drift in both directions, files that exist but aren’t listed and files listed that no longer exist. It runs as a non-blocking pre-commit hook. There’s an equivalent tool in the resolver world that hunts for capabilities unreachable from the routing table, and the reported figure for a first run is around 15%. Agents can use it to ensure the agent is fresh.

Agents identify potential inconsistencies (either between documents, indices, or anywhere) and they surface them so they can be fixed immediately. This is why before I did that, my first implementation of the context bootloader sucked after three weeks. I forgot to change indices, I was rushing things and context-switching, and I had to rebuild everything.

It probably goes without saying, but this same architecture can (and I am convinced that it should) be included not only on personal projects, but on big company-wide repos. I am starting to include all ADRs, PRDs, and relevant specs into my code repos conveniently indexed. With this, the agent has the code and the whole context it needs to create new features and evolve the project in the same repository.

This simple change has allowed me to be more productive and have to iterate less on the output of my agents. Try it, I promise that you would love it. In retrospect it is a pretty obvious thing, but it’s a charm to use. Happy to help anyone set it up on their projects.

Slow loops

The second technique that I’ve been using more and more is the one I promised in January: a kind of loop called slow loops.

A slow loop starts on a trigger. An event, or more often a cron that fires at 2am. It does a bounded piece of work while I’m not there, and it leaves something for me to look at. That’s it. Fire-and-forget on the agent’s side, scheduled review on mine. That way I can wake up to human work to do, and I let the agent advance the work when I am not there (so I don’t need to context switch so much).

I got the shape of this from Horthy, who calls slow loops his favourite way to do loop engineering. His team started with one nightly agent that fixed one thing in the codebase and opened a pull request. They now have four agents opening four PRs by morning, focused on code quality. The important part of his description is the last line: “A person still reads all of them before merging.”

That’s why I keep using the word slow. The constraint isn’t the agent’s speed, it’s my review capacity. Four PRs is roughly what I can properly read without being overwhelmed. If the loop produced forty, the gate would become a rubber stamp, which is the same as having no gate while feeling like you do. This is not OpenClaw and “never read the code” kind of loop, but a smarter way of scheduling agent and human work.

I should be straight about my position here, because I’m quoting people who go further than I’m willing to. Peter Steinberger: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” Boris Cherny, who leads Claude Code: “I don’t prompt Claude anymore. I have loops that are running. They’re the ones prompting Claude and figuring out what to do. My job is to write loops.” I think they’re right about the direction and I’m not following them all the way to the end of it. A slow loop is loop engineering with a review gate bolted on, not a rejection of it.

Horthy actually tested empirically the impact of completely autonomous loops versus slow loops: he ran unreviewed AI code starting in July 2025 and production broke catastrophically within four months. A fully automated setup he describes as a “dark factory” corrupted a codebase in three (the dark part comes from the fact that you don’t know what it’s doing under the hood). The people furthest into loop engineering are the ones who found the bottom of it, and they came back with the same conclusion. Someone reads the output.

And I think this is going to be the state of AI-powered engineering until models get better at writing architecturally sound and maintainable code. Because agents now write better code than me. I’ve always been a better engineer than coder, but there’s no doubt that they are now capable of writing really high-quality code and implementations. But all this code needs to be implemented in a way that is understandable and maintainable, and in many cases only an agent would be able to parse some code bases.

So until they manage to write proper maintainable code, I still want a human reviewing code bases. Not the usual scaffolding, but the important parts. And this is where agents can also help a lot, by pinpointing the parts of the code that they feel are worth the eye of a human (with these limitations in mind). And this is something that I’ve also recently incorporated in my daily workflow.

How do the bootloader and the slow loops fit together

The best-known version of this pattern came out of the Claude Code leak, which I wrote about in April. Buried in there was a background process called autoDream, whose system prompt opens with a genuinely lovely line: “You are performing a dream, a reflective pass over your memory files.”

Strip the poetry and it’s basically a cron job. It fires when three conditions hold: 24 hours since the last run, five sessions completed, and no other dream holding the lock. Four phases, orient, gather, consolidate, prune. Output capped at 25KB. A trigger, a lock file, a pipeline, and a size cap.

The deflation is the point. What’s valuable there isn’t the dreaming, it’s that the processing happens off-band, on a schedule, over work that has already happened. You can build that this afternoon without a leaked codebase.

And this is the only reason the two halves of this post belong in the same piece. My bootloader depends on the indices being true, and keeping them true is repetitive, unglamorous work I will not reliably do myself. So the loop that runs overnight is the one that checks freshness, finds the drift, and tells me in the morning. The slow loop maintains the bootloader. Technique two exists to keep technique one honest. That is a perfect illustration of the kind of workloads that I run in a loop. Not necessarily a slow loop, because I don’t need a human review, but something that can happen when I am not looking to maximise the use of AI.

One point worth noting is that compression is also important. Sometimes this indices get too large (and in many cases not useful) and they need to be garbage collected. This is another of those tasks that are easily implemented into a loop.

The failure case for all of this has a name too, loopmaxxing, and it’s the belief that an agent will eventually get there if you just let it run long enough. What you get instead is drift on any goal too fuzzy to terminate on, a surprising credit bill, and comprehension debt: the repo moves further from your mental model of it every night, until a production incident hands you thousands of lines of code you’ve never read, and that you no longer know how to navigate.

If you only take one of the two, take the bootloader. It pays off in the first session, it costs you an afternoon, and it needs no infrastructure. The slow loop is the more exciting one, but a loop running against a stale context tree just generates confident nonsense faster, and now it does it at 2am while you’re asleep.

Are you running anything off-band overnight? And the question I actually care about: do you read what it leaves you, or has it quietly become a thing you approve?

Until next week!