The mental model that reorganized how I run agents is blunt: in an autoregressive model, every piece of content in the thread is either helping the next token or hurting it. There is no neutral filler. Once that sinks in, a context window stops being a chat log and becomes a budget, something you measure, route around, and spend deliberately. This post is about two features I built into goldengoose for exactly that, and the planning habit that makes them rarely needed.
I used to be the context monitor
Both features were dogfooded into existence, from the same embarrassing job. Back when I orchestrated agents by hand in Claude Code, I’d split a feature into phases and then sit in the middle as the world’s dumbest component: a human whose job was reading a percentage. After each phase I’d check the implementer’s remaining context. Above my threshold of 65%, I’d hand it the next phase, since everything it learned finishing the last one was still in its head; below, I’d retire it and write a fresh prompt for a new agent. It happened so often that I was effectively a context-window scheduler with a pulse.
So goldengoose absorbed the job. The runtime already knows every agent’s live context usage, so two things fell out. First, agents get rotated by rules instead of by me: the 65% rule now lives inside a supervisor’s skill file. Second, and I haven’t seen this in any other harness: compaction notifications. When an agent’s context gets compacted, someone who knew its original assignment gets told. Settings make that person either the team lead or the agent’s creator. The distinction matters in a flat org, where anyone can add anyone: the creator is often not the lead. A feature supervisor rotating phase implementers in its own worktree is the one holding the plan those implementers might have just forgotten pieces of, so it gets the notification, DMs the compacted agent, and triggers the recovery skill: stash, re-read the plan from disk, diff your own work to see how far past-you got, resume. The compacted context was a lossy copy; the plan on disk is lossless, and recovery means going back to the source.
Any agent can read the gauge
The second feature is smaller and quieter: the context-remaining percentage lives in the team status tool, so any agent can check any teammate’s gauge and, better still, its own. This is the same tool the supervisors use for the rotation decision: one status call before assigning the next phase, and reuse-or-rotate becomes a choice grounded in a number instead of a guess. Almost no harness I’ve seen gives an agent visibility into its own context usage, let alone its teammates’. The runtime had the data, and withholding a useful measurement from the agents that could act on it seemed silly.
What that buys me is flexibility that feels almost unfair. The rotation threshold is a sentence in a markdown skill. If I want 50% instead of 65%, I change one number in plain English and nothing else: no code, no config schema, no redeploy, because the measuring is the runtime’s job and the policy is the skill’s. My whole orchestration layer stays natural language for exactly this reason.
Tool or skill?
That split points at a decision I now face every time I want to improve an agent-driven workflow: does the improvement go into the tool, or into the skill? Sometimes both, but there’s a rule of thumb I keep landing on. Facts go in the tool: measurements, notifications, identities, anything that’s true regardless of what you do with it. Judgment goes in the skill: thresholds, procedures, what-to-do-when, anything I might change my mind about. Context percentage is a fact, so it lives in the status tool where any workflow can use it for purposes I haven’t imagined. What to do at 65% is a policy, so it lives in English where changing it costs nothing.
This time almost all the work went into the tool side, deliberately: live context visibility and compaction notifications are primitives with more uses than my current workflows, and what other people do with them is their business. The skills stay thin, legible, and mine.
Scope phases like context is the currency
The third idea isn’t a feature; it’s the habit that makes the features rarely fire. It follows from the helping-or-hurting rule having two regimes. In alignment conversations, the long ones where a spec gets born, more context is better, almost monotonically: every disagreement, every correction, every refinement improves the end output. In execution, past a point, more context hurts: the agent has too many things to think about and stops spending its thinking on the right ones. And letting auto-compaction fix that is a bad trade. The summary is decent, but it flattens the resolution that the original plan and instructions had. The goal isn’t to recover from compaction well. It’s to make compaction not happen.
So I scope phases with a strong bias: under-scoped beats over-scoped, every time. The math is why. Say a phase costs an implementer about 20% of its window and my rotation threshold is 65% remaining. After phase one the agent sits around 80%, comfortably above threshold, and because the supervisor can read the gauge, that’s an informed decision, not a guess: hand the same agent phase two, keeping everything it already knows, for free. Small phases compose; the plumbing makes running four phases through two agents cost nothing extra.
Now run it the other way. An over-stuffed phase that eats 80% of a window is a trap with no good exit: no room for review feedback, no room for a fix loop, and if anything goes wrong, a recovering agent has to re-read so much before attempting a fix that the attempt itself comes out degraded. An under-scoped phase costs you a little rotation overhead that my runtime already made cheap. An over-scoped phase costs you the quality of every token near the end of the window. That asymmetry is the entire planning bias.
Step back and the three pieces are one design. The runtime measures and notifies, the skills hold the judgment in plain English, and the plans are scoped so the budget math works out. There’s no orchestration code anywhere in it; my workflows are markdown files describing rules a Rust runtime makes cheap to follow. I used to be the component reading the percentage. Now the percentage is just another thing my agents know about each other, and the only budget I personally manage is the one this whole system exists to protect: attention on what to build next.