Long agent sessions get worse the longer they run. When we let one session do everything, it would read a pile of files, trace a bug and check how some convention worked, and by the time it had to make a real decision, its context was stuffed with details it only needed once. It started losing track of what it had decided earlier, and every turn cost more than the one before.
Most people think of tokens as the cost to manage. I think the scarcer thing is the main agent's attention. A context window is finite, and a model gets worse at using it as it fills up. Anthropic's write-up on context engineering calls this an attention budget, and says a model's ability to recall information from its context drops as the number of tokens in it grows. Once we started treating context as a budget, most of how we run agents followed from that.
Why one big session falls apart
Exploration is a lot of reading, and very little of it is worth keeping. To trace a bug, an agent might open a bunch of files to find the one line that matters. In a single session, all of that reading stays in the context for good, right next to the decisions that need to stay sharp. So we started splitting the work by how long it needs to stick around.
How the main agent works now
Our main session is an orchestrator, and it works a bit like a CEO with a team of specialists. It takes the task, decides what needs looking into, and hands each piece to a short-lived helper agent with a narrow brief. The helper starts with a clean context, reads as much as it needs, and reports back a short summary. Then it's thrown away.
A helper writes the code too, in its own clean context, and reports back what it changed. Even the reviewers start fresh, so they never inherit the reasoning that wrote the code.
What the main agent holds onto is small: the task, the summaries and the judgment calls it has made. It judges whether the work is heading the right way and whether the result holds up, the way a CEO judges an outcome without knowing every step a specialist took to get there.
The helpers' context is cheap because it gets thrown away. The main agent's context lasts for the whole task, so that's the one we're careful with. When we plan a task, the question is what needs to be in the context that lasts. Most of it doesn't, and that goes to a helper.
flowchart TD task[A task comes in] --> main[Main agent plans and writes a brief] main --> reader[Helper reads the code in its own clean context] main --> writer[Helper writes the change in its own clean context] reader -->|short summary| main writer -->|short summary| main main --> next[Main agent decides what happens next]
What changed for us
Deep exploration stopped being scary. Tracing something through a big codebase used to drown the session. Now the main agent sends a helper to go look and gets a paragraph back.
The main agent's decisions got better too, because it's reasoning over summaries and earlier decisions instead of ten thousand lines of code it skimmed once. It's cheaper as well. Most of the tokens get spent in short-lived contexts instead of piling up in one long, expensive session.
The skill that matters most now is writing the brief. A vague brief gets a vague summary back. A tight paragraph that says what to find and what done looks like gets back something the main agent can actually use. That's just delegation, the same skill you need when you manage people, and it carries over in both directions.
Summaries are lossy, though. Every so often a helper leaves out the one detail that mattered, and the main agent makes a call on incomplete information. We deal with that in two ways. Every brief says what to look for and also what to flag when the helper isn't sure, so it reports what it couldn't confirm instead of guessing. And anything where correctness really matters gets checked separately, by tests or a fresh reviewer.