Same model, different behavior: four rules for what you build around an agent, what you get and what you pay

The longer an agent's session goes, the worse it tends to get. Before you reach for a different model, look at what's around it. The tools, the permissions, the loop control and the context are four ways you can architect how an agent behaves, with the same model underneath. Here are four rules I use, what you get from each one, and what you pay for it. It's not one solution for all.

One of my agent sessions lasted for weeks. Over those weeks, the orchestrator used almost a million tokens in total, and its own window never filled up that much, because the sub-agents did the heavy reading.

The other kind you probably know: a few questions in, the agent starts hallucinating, missing things, forgetting what you told it at the start, and you sit there thinking: okay, what's wrong here?

At a glance

Rule	What you get	What you pay
1. Reset your context	A fresh, small window, so the agent stays sharp; your rules come back from CLAUDE.md	What lived only in the conversation is gone
2. Use sub-agents	A clean main window that can last for weeks; overall, more done in less time, at higher quality (my perception)	More tokens in total; one task usually isn't faster; details lost in handoffs
3. Split only independent work	Work that runs side by side; fresh eyes that can catch what one agent got wrong	Coordination and tokens; sequential work can get worse
4. Automate the checks	Consistency without repeating yourself; checks that don't trust "done"	A loaded skill takes window space, and the model can skip it

The model makes a decision, affects the environment, comes back, and decides again. A chatbot gives you the response, and that's it.

There are four things you can add around the model. Tool definitions: the actions it can take, like finding a file, reading a directory or editing code. Context, which you need to consider as soon as you talk about harness engineering. Loop control: how many steps can it take? You can limit that, so it doesn't go on endlessly. And permissions. Agents sometimes do risky things, like deleting a file, so you want a human in the loop: should I do this?

Four ways you can architect how an agent behaves: tools, context, loop control and permissions.

That four-part split is my own framing of the agentic harness, the layer around the model. Birgitta Böckeler, Addy Osmani and HumanLayer have written it up well. The four rules below are mostly about context; permissions and loop control get their own post.

What I know here comes from experience first, and second from Anthropic's own documentation and courses. That's why the examples are in Claude Code. But I'd be very cautious if a model vendor told me to use one of these methods, because they probably have an incentive behind it: more tokens, more spend. I experience it myself, and then I see where it fits.

1. Reset your context more often

My rule of thumb, from experience: restart your session at about half the window, whether that's a million tokens or 200,000.

The window is a limited space, and it fills with the system prompt, the tool definitions, the conversation history, every file the agent reads, every tool call and its response. One task can fill most of it.

All of these actions, all of this reading, all of this effort piles up in the context.

It's not just a feeling or a vibe: Anthropic describes a performance gradient rather than a hard cliff. Dex Horthy at HumanLayer recommends keeping utilization in the 40–60% range through frequent intentional compaction. In a May 2026 preprint, Sam Martin and Fabien Roger had models act as monitors that read long agent transcripts and flag subtly dangerous actions; after roughly 800K tokens of harmless activity, the monitors missed those actions 2 to 30 times more often than when the actions stood alone.

What you get from a restart is a small window again, where the agent stays sharp. It's cheaper per turn too. If there are 100 tokens in your context, the model looks at all 100 of them to predict the next one, and every turn resends all of it. So you pay for it again (less, with prompt caching), and caching doesn't shrink the window.

Your rules survive too, if they're written down. When the window fills up, Claude Code compacts it: it clears older tool outputs first, then summarizes the conversation if needed. Summarizing can lose something, maybe a rule or a prompt you gave at the start. That's why I put the rules I want to keep in CLAUDE.md or AGENTS.md (which Claude Code can read in its place) instead of relying on the conversation. CLAUDE.md loads in full at every session start, so they come back after a restart.

What you pay is the restart itself: anything that lived only in the conversation is gone.

Why do I bring this up? Because context is important: treat it as part of the engineering.

2. Sub-agents spend more tokens to keep your main context clean

If I tell you to read a file, write the tests, go and get coffee, then talk to this person and that person, what happens to your cognitive load? You have lots of things to keep in mind. Same thing for an agent.

So you hand some of it off. I'm not interested in the test run, only in its results. Not in reading the file, only in its summary. Anthropic calls this pattern orchestrator-workers.

In Claude Code, each sub-agent starts in a fresh window. It doesn't see your conversation; it works from the task the orchestrator writes for it, plus your project instructions. Each one reports back to the orchestrator with a summary, and if Claude names them when it spawns them, they can also message each other.

The sub-agents do the reading. The orchestrator only gets the summaries back.

What you get is a main window that stays clean. In one of my own runs, the orchestrator's window held about 79,000 tokens while its four sub-agents' windows went to 100K and 200K each. I've kept one orchestration going for four days with its window holding about 500K; the one I opened with ran for weeks.

Is it cheaper, then? Not at all. You run out of tokens really quickly: in my own practice, I hit my limits more often because of it. Each agent uses less, but the whole flow spends more, because several agents each read and reason on their own. Anthropic states the cost itself: multi-agent systems "typically consume 3 to 10 times more tokens than single-agent approaches for equivalent tasks".

You'd also expect it to be faster, because several agents are doing the work. For a single task, in my experience, it usually isn't: the coordination adds time. Overall, though, I perceive that I finish more in less time, and at higher quality. That's a perception, not a measurement.

Every handoff also drops something: the things that didn't happen, the things a sub-agent found complicated, the blockers. Cognition names part of the problem: "Agents assume they share state with their children when they don't." I'm building my own thing for this, a findings pool that lives in my repository. Anything can be a finding: a source, inefficient or dead code, a security risk. A sub-agent's main task is to fix task A, and on the way it notices something about task B. My agents are instructed to record that as a finding instead of ignoring it. Claude finds most of them on its own.

One real finding: all my application code looked good, and the agent told me: there's a bit of dead code somewhere, we might benefit from trimming it away later. I didn't want that in the current session; it would just make it bigger. So it went in as a finding: once we're ready, we'll figure it out.

If it's one task, don't use sub-agents. If it's several tasks, they're useful. And start small. I run six or seven at the same time, but if you're starting, then start with two. Don't go beyond two, and see how far you can manage that.

As of October 2026, my orchestrator runs on Opus and my sub-agents run on Sonnet. I don't usually let the orchestrator pick the model, but sometimes I do, and it goes different ways. Once, Claude spawned something like 13 sub-agents for me, all on Opus 5.5. After a couple of minutes everything stopped: they had used up my whole five-hour limit. Another time, it picked Haiku for a task Haiku couldn't do (more on that in rule 3). So watch the model choice. Since the 13 agents, I keep sub-agents as small as possible, but not so small that it hurts the progress or the quality of the output.

3. Split only what can run without the others' output

Can the subtasks run without each other's output? Yes or no? If not, use a single agent. If yes, use several.

Can you split the tasks? If not, a single agent will do it.

Think about it as management. If you have interns on the team and the work splits, you send it to several interns. If it doesn't, you give it to one person.

When the work splits, the parts run side by side. Research with three or four angles gets one sub-agent per angle. In a refactor, each agent takes one module, one file, one class. For a new feature, reading the documentation, checking the framework, investigating the code and writing the first tests can all start in parallel.

Some work needs its own system prompt, like a specialized agent that does one thing very well. A prompt like "you're a Python expert" doesn't count: to me, it's just another bunch of tokens. A specialized agent can get hard limits too: in Claude Code, a reviewer whose tools field lists only Read, Grep and Glob can't edit the code it reviews.

Keep it in the main thread when the steps depend on each other: you read this, based on it you make that decision, and based on that the next one. Debugging is the clearest case. You run the test first, then you debug it. It doesn't go the other way around.

Kim et al. (Google and MIT, 2025/26) report relative changes that range from +80.8% on one decomposable financial-reasoning benchmark to −70.0% on one sequential planning benchmark. Still, this is my rule of thumb, not a law.

A second use: fresh eyes

A second use isn't about splitting: the same work, given to fresh eyes for review. I notice that a new chat behaves a bit differently from an old one, and a sub-agent with a fresh pair of eyes can review better. Cognition reports that its clean-context review agent catches an average of 2 bugs per PR, roughly 58% of them severe, even on PRs its own agent wrote: a vendor's number for its own product.

Once, I wanted a very small model to find the critical components in a project of mine, and Claude picked Haiku. It came back with more than 60 issues. I was surprised, because that would mean the whole codebase was bad, and I didn't trust it. I didn't keep the results. I immediately spawned another agent to review them, and apparently they were incorrect findings. The fresh pair of eyes flagged the first one's findings as incorrect. So I put several agents on the same task, small enough but not too small, and kept the issues they had in common. Since then, I also score the findings. Agreement only filters for consistency: agents can agree and still be wrong, which is why the scoring step is there.

When I prepared a slide deck for a talk, instead of asking Claude "can you look into my presentation and tell me if it's nice or not", I asked it to spawn eight sub-agents, each with its own persona: almost a council. One was very critical and didn't miss a single detail. One had a short attention span, to catch me staying on one topic too long. One was a developer who knew the basics, but not the interesting parts. They saw only the text, no visuals, and looked at the story flow and at what was vague.

One thing I changed: I moved content from later in the deck to earlier, and that helped a lot; the story flowed more naturally. Being AI agents, they didn't flag the text-heavy slides or the footer on every slide. I found that odd, so I flagged those myself, along with other points. It was a useful simulation.

4. A skill is a recommendation, so automate the checks

A skill is a procedure you repeat, written down: a name, a description and the steps. The best thing about skills is that they're consistent. My own pull-request skill makes every PR description list which files changed, what's left to do after it's committed, the security concerns, and anything that needs attention. Without a skill, you're steering by hand: no, don't do this; yes, do this; change that. With one, you don't need to repeat yourself. CLAUDE.md does the same for every session: mine tells Claude to read the findings pool back at the start of each one.

Only the name and description load at the start, about 100 tokens per skill. The description is the trigger: when a task matches it, the agent reads the rest. Once it's read, it sits in your window, and the cost goes up.

One caveat: a skill is a recommendation. The model can decide: yeah, I don't want to do this. The Claude Code docs say it directly: "An instruction like 'never edit .env' in CLAUDE.md or a skill is a request, not a guarantee. A PreToolUse hook that blocks the edit is enforcement."

So automate the checks that matter. Agents are nice for writing code, but then you have linting, tests, quality checks and a scan for secrets: make sure they run, and that they pass.

That's what hooks are for. A hook is a script that Claude Code or git runs automatically at a set moment, like before a tool runs or before a commit. A Claude Code hook fires without Claude deciding, and it costs nothing in the window unless it returns output.

I use a tool that turns my codebase into a graph for the agent. It needs maintenance: after every change, the graph has to be regenerated. I kept asking the agent: did you update it? Now a Claude Code hook regenerates it.

My pre-commit hooks are git hooks: git runs them before each commit. On my own projects, one of them updates the version. It's a plain bash script: based on how many lines of code changed, how many files, and some rules I set, it decides whether the version goes up, so small or minor changes don't get a new version number. Lately I commit each feature as one commit on my own projects. It's easier, and I can see directly in the app when the new version is there, without going into the code or checking pipelines. It doesn't have to be AI. Another hook fails the commit whenever the tests or the linting don't pass. Even when the agent thinks it's finished, the pre-commit hook comes in and tells a different story.

A local pre-commit hook can be skipped with git commit --no-verify, so the real gate is CI. In Claude Code, a PreToolUse hook can block that command before it runs.

CLAUDE.md, a skill, a sub-agent or a hook: it depends on how you want your harness to work.

Try it, then judge it yourself

I'm not saying you should drop everything you did before. The old methods are still very relevant, because they're more deterministic and more linear. Each of these rules is just a tool in your toolbox. Use it this week, cautiously and deliberately, and see how far you can go.

Try it on your own repo (about 30 minutes)

1. In Claude Code, on a clean branch of a repo you know, pick one task that splits: how a module works, or a question with three or four angles.
2. Run /context and note how full the window is. Then run /usage and write the numbers down.
3. Ask for sub-agents explicitly, and start with two. For example: Use two sub-agents in parallel to find out how <a module you know> works and where it's tested. Report back with a short summary.
4. Run /context again. The main window should have grown only by the summaries. Run /usage again. The change is roughly what this run cost: dollars with an API key, a share of your plan limit on Pro or Max.
5. Check one line of a summary against the code. Was the summary right, and what did it cost?