A loop that keeps running after I close the laptop
I read about these three features separately, months apart, and each one sounded fine on its own. Agents that can message each other. Compaction that trims context before it overflows. A mode where you state a goal and the agent works until it is done. Nothing exotic. One at a time they read like quality-of-life improvements.
Together they stopped looking like three features. An agent that can talk to peers, forget on purpose, and chase a goal for hours is a loop that keeps running after I stop watching. I started calling it the loop. The more I looked at it, the less comfortable I got.
What each piece does
Messaging came first. A session can discover other sessions and pass them a message: a finding, a status, a question. The receiving session reads it as ordinary input. A colleague can hand a task to a peer, report a blocker, or ask for a second opinion without anyone copying text between terminals. I watched a colleague paste a stack trace back and forth between two windows for twenty minutes before it occurred to me that the two sessions could have sent it to each other. Sessions on the same machine, background sessions, agent teammates: they form a small network, and Claude routes among them. The mechanism is a per-session socket on my machine, never a server round-trip, and the payload is plain text. A message is input, not authority: it cannot approve a permission prompt, run a slash command, or change my configuration on my behalf.
Compaction next. Every long session eventually hits the context ceiling, and compaction summarizes what came before so the work can continue. The older version re-read the whole conversation at the moment of overflow, which is why compaction used to stall for a minute or two. I remember a terminal sitting frozen in the middle of a refactor, long enough that I went to get coffee. The newer version writes summaries in the background as work proceeds, so the summary is ready before it is needed. You can also tune when it fires: setting the compaction window to a fixed size, say three hundred thousand tokens, trades a smaller working set for more frequent, cheaper summaries. I landed on my own number the way I land on any other budget, by watching what it cost. Subagents compact on their own schedule, and their transcripts live in separate files, so the main conversation compacting does not erase what a worker learned.
Goal mode came last. Instead of a prompt, you state an outcome. The agent keeps taking steps toward it until the goal is met or it gives up. No turn-by-turn instruction. The agent decides what to do next, checks whether it is closer, and continues. One major tool pulled goal mode from its CLI after people aimed it at tasks that did not stop.
Each piece is coherent alone. The loop is what happens when they feed each other.
goal mode: "keep working until X is true"
|
v
+--------------> agent takes a step
| |
| v
| context fills up
| |
| v
| auto-compact writes a summary, drops the rest
| |
| v
| agent keeps going on the summary
| |
| needs help or hits a blocker
| |
| v
| sends a message to a peer session
| |
| v
+--------< peer answers, agent continues
|
v
goal met ----------> stop
I wrapped that loop around a real task to see what it would do. The agent does not stop when context runs out, because compaction lets it continue. It does not stall when it hits something it cannot do alone, because it can ask a peer. It does not stop when it finishes a step, because the goal is not met yet. Every ordinary stopping point had been removed.
Why that is wonderful and why it is terrifying
The good version of the loop is a force multiplier. A teammate session that keeps working on a goal while I sleep. A worker that asks a specialist session for help instead of guessing, and gets an answer in one message instead of through me. A long migration where the agent compacts through its own history and still remembers the goal at the end. This is what "long-horizon agents" looks like when the primitives fit together.
The concerning version is the same loop with the wrong goal, or a goal that drifts. Compaction is lossy. The summary keeps what the summarizer thought mattered. If it drops the constraint that says do not touch the production database, the agent compacts past that constraint and keeps going. If it drops a correction I made an hour ago, the agent compacts past the correction too. A goal-running loop that forgets the guardrails I set is not pursuing my goal. It is pursuing a version of my goal after several rounds of telephone.
Layer on the peer network and the loop gets harder to see. Messages flow between sessions. A peer session that was told to do something does it. Two sessions that disagree, or that both misread a compacted summary, can coordinate their way into a state neither would reach alone. There is a reason goal mode was pulled from one of the major tools after people pointed it at tasks that ran away: an agent that never stops until a goal is met will meet it, by whatever path the loop finds first.
The guardrails that matter
I do not think the answer is to avoid the loop. It is too useful, and it is coming to every agent harness whether I invite it or not. The answer is to build the loop with the brake already installed.
Keep persistent state outside the context window. Compaction should not be the only place a constraint or a decision lives. Critical rules, ownership, and the definition of done belong in files on disk, where summarization cannot lose them. A session can forget; a file cannot.
Give the loop a stopping condition beyond the goal. A budget of time or tokens, whichever runs out first. Goal mode without a ceiling assumes the goal is more important than everything else, and sometimes it is not.
Make the peer network observable. Who messaged whom, what each session decided, and which decisions are still open. A loop I cannot inspect is a loop I cannot trust. Telemetry is not paranoia here; it is the only way to know whether the agent still understands the goal or has quietly replaced it.
Cap the loop's permissions at what the goal actually needs. A session chasing a goal with broad write access and no command guard is the recipe for the incident where an agent decides my database is unused. The destructive-agent stories are all versions of this: a loop that was allowed to do something the goal never required.
And treat the goal statement as a contract, not a wish. State the outcome, the constraints, and the definition of done, and let the agent reconcile against all three. Agreeing on "fix the performance issue" without saying "without changing the public API" gives the loop permission to solve a problem I did not have.
Dividing the roles so the loop stays legible
A loop with no division of labor is one session doing everything and compacting its way into confusion. The version that works assigns each session a narrow job and writes the job down where compaction cannot lose it. Four roles cover most of what I run.
One coordinator owns the goal. It plans, delegates, and reviews results against the definition of done. It does not implement. The moment the coordinator starts writing code, it stops being able to see the whole board and becomes a slow worker with a manager's context.
One verifier owns testing. It accepts finished work, runs the checks, and reports back to the coordinator with evidence: what it ran, what passed, what failed, and what it could not verify. It never reports to the workers directly, and it never fixes what it finds. A verifier that patches its own findings has stopped verifying.
The rest are developers, each scoped to a piece of the plan. They implement, run their own quick checks, and hand off to the verifier through the coordinator. They ask peers for help when stuck, which is the whole reason the messaging exists.
The rule that took me the longest to learn: no session in the loop gets to ask the human a question mid-run. The AskUserQuestion tool is exactly wrong for a loop that is supposed to run unattended. A worker that stops to ask "which approach do you prefer?" in the middle of a goal it was told to complete has misunderstood its job. Questions go to the coordinator. The coordinator either answers from the plan or surfaces a genuine decision to the human at a checkpoint, not in the middle of a step. Disabling AskUserQuestion for the worker and verifier definitions is a one-line change that eliminates an entire class of stalls.
{
"name": "verifier",
"description": "Tests finished work and reports evidence to the coordinator. Never fixes.",
"tools": ["Read", "Bash", "Grep", "Glob"],
"disallowedTools": ["AskUserQuestion", "Write", "Edit"],
"model": "haiku"
}
That shape is worth copying for every role: the tools a role needs, and the ones it must not have. A verifier without write access cannot quietly fix a test to make it pass. A developer without AskUserQuestion cannot stall the loop waiting for guidance it was supposed to derive from the plan. Constraints baked into the definition survive compaction, because they are loaded fresh every time the session starts rather than carried in a summary that might drop them.
The coordinator's job is the hardest to keep narrow. It is the one session that must hold the goal, the plan, and the state of every worker at once, which is precisely the role where a compacted summary does the most damage. Give the coordinator persistent memory so its plan lives outside the context window. Review the coordinator's view when a goal stalls, because a stalled loop is almost always a coordinator that lost the thread and a set of workers faithfully executing a version of the plan that no longer exists.
Where this is heading
The pieces are converging because they solve the same underlying problem from different angles: a single context window is too small for real work, and a single agent is too narrow. Messaging widens the agent. Compaction lengthens it. Goal mode frees it. Together they describe an agent that outlives its context, asks for help, and does not need me present for every step.
The pieces are already documented as separate features, and worth reading directly rather than taking a blog post's word for: cross-session messaging, agent teams, subagents, and session management for how compaction fits into the picture. The roll-your-own version runs on my own machine, over a socket, with plain text between sessions.
That is closer to a colleague than a tool, and it deserves the same skepticism I would apply to a new hire with the keys to production. The loop is powerful, the seam between remembering and forgetting is exactly where it fails, and the person who sets the goal is still responsible for what the loop does with it. Set the goal, watch the loop, keep the guardrails on disk where compaction cannot reach. Then close the laptop and let it work, because that part is genuinely great.