Sessions Shouldn't Be the Human Unit of Work: Pushing State and Scheduling into the Agent Substrate

Much of our interaction with AI agents today remains framed around chat windows. Whether through terminal CLIs, IDE side panels, or browser tabs, screens regularly end up with three to five active sessions running at the same time.

As single-task reasoning models become capable enough to complete code changes with less oversight, a different constraint becomes noticeable: multi-task coordination is limited by human attention.

Most people can realistically track around three to five active sessions at once. Beyond that range, you spend much of your time toggling between windows: waiting for one agent to respond, copying outputs over to another, forwarding CI error logs, and nudging stalled tasks to continue. Without intending to, the user turns into a manual scheduling bus connecting separate sessions.

In The Bottleneck in Multi-Agent Systems Isn't the Model—It's the Engineering Outside It, I discussed runtime, authorization, isolation, and kill-switch requirements in distributed setups. Getting more value from agent workflows requires revisiting the interaction model: take sessions out of user-facing mental models and interfaces, pushing them down into the infrastructure as an implementation detail.

Decoupling Brain and Hands: A Session Is an Event Ledger, Not Volatile Chat History

Current chat sessions can feel taxing because existing designs overload them with too many responsibilities: the window acts simultaneously as an input surface, active context, tool runtime, and ad-hoc long-term memory. When context exceeds the window's budget, systems either truncate early context and lose earlier decisions, or let conversation logs expand until responses slow down and attention wanders.

In their work on Claude Managed Agents, Anthropic engineers outlined a cleaner separation of concerns, dividing the system into three components:

1. Session (Event Ledger): An append-only log recording user intents, tool calls, inputs, outputs, and errors. The lifecycle of a Session can extend well beyond any single model context window. With an immutable log, the system can revisit and reread history as needed without relying on lossy, speculative summaries.
2. Brain (Stateless Reasoning): The model paired with a lightweight harness, acting as a stateless reader. Given an extensive Session, the Brain determines its context approach dynamically: rewinding, rereading selected sections, or resuming from a checkpoint. While context management conventions evolve across model generations, the Session interface should outlive specific model assumptions.
3. Hands (Replaceable Sandboxes and Tools): Execution and tool environments should remain isolated from the reasoning model. Sandboxes can be created on demand and discarded after use. Sensitive credentials and long-term tokens should not live inside sandboxes directly, but be retrieved through external proxies and secret vaults in controlled environments.

Closing the loop on longer tasks works better when driven by structured outcomes and automated graders rather than manual check-ins. Cross-task learning can similarly be handled by offline pipelines (such as the Dreams mechanism) that distill event logs into reusable rules in the background.

Super-Agent Scheduling: Routers for Continuity, Isolated Workers for Concurrency

When users are no longer manually switching windows, how does the system coordinate work? The DeepSeek Harness team explored a layered design in their Super-agent architecture concept.

Balancing continuity across channels (Continuous), concurrent throughput (Productive), event listening (Proactive), and always-on availability (Persistent) within a single agent's linear ReAct loop is difficult. A two-tier division of labor is more practical:

• Router for Global Interaction and Coordination: Whether a user connects via chat apps, web dashboards, or code repositories, they interact with the same logical agent. The Router maintains global task state, parses intent, routes events, and dispatches work, but avoids running long-running operations itself so interaction channels stay responsive.
• Isolated Workers for Throughput: Workers operate in isolated environments, focusing on specific tasks assigned by the Router. They run asynchronously and apply changes directly to the target environment without conversing with the user.
• Event-Driven Triggers and Watchdog: Monitoring alerts, code pushes, and other events can initiate tasks directly. Fast-path code filters routine noise, while slow-path models interpret deeper context. An external Watchdog tracks background health to catch stalled or drifting runs.

In synthetic workload evaluations shared by the DeepSeek Harness team, the two-tier architecture showed better p50 and p95 task completion times than running sub-agents inside a single session. When nesting tools within one session, neutral prompts sometimes led the model to avoid delegating altogether. Pass-through mechanisms primarily reduced Router decision volume and cache-read tokens; while actual task runtimes remained comparable, the setup cut down central orchestration overhead without claiming to accelerate the underlying work itself.

Fleet Operations and Stigmergy: Removing Waiting from the System

Taking coordination a step further, what does collaboration look like when internal waiting time is systematically reduced? Spawn (jacob) shared an approach where a small team operates alongside an active fleet of agents, shipping changes on an hourly cadence.

The premise behind this approach is that velocity bottlenecks often stem from waiting rather than coding speed—people waiting on people, agents waiting on people, and agents waiting on each other.

To reduce that wait time, they adopted two primary mechanisms:

First, Stigmergy (coordinating through the shared environment). In biology, termites construct mounds without centralized planning by responding directly to changes in their shared surroundings. Similarly, agents do not need constant conversational exchanges or prolonged Pull Request reviews; the codebase, deployment status, and production telemetry serve as the coordination medium. In Spawn's setup, agents commit changes directly to the main branch, maintaining stability through hourly automated cleanup and dispatching patch agents (janitors) to fix regressions as soon as they appear, rather than trying to make every pull request perfect before merging.

Second, direct production feedback loops. Rather than waiting for a human to triage issues, agents read production error logs, monitoring alerts, and user reports directly. According to jacob, roughly 60% of their workload originates directly from production exceptions. When an issue occurs, agents locate the fault, write a fix, verify it, and aim to deploy within an hour.

Under this division of labor, human effort focuses primarily on two areas:

• Taste (Judgment and Veto): Saying "no" to system proposals, pruning outdated rules left over from earlier model versions, and making calls on unfamiliar scenarios.
• Entropy (Setting Non-Linear Targets): Models tend to favor small, incremental 2% adjustments rather than architectural overhauls. Humans provide the push for larger rewrites or substantial performance leaps.

Practical Boundaries and Security Redlines

This style of rapid-fire collaboration requires specific conditions that cannot simply be copied into any project:

First, the operating pattern is closely tied to model characteristics. Moving quickly with direct commits assumes high consistency over long tasks. If an underlying model tends to drift over extended workflows, or exhibits erratic behavior, committing directly to production amplifies mistakes quickly.

Second, it depends on fast rollbacks and strong infrastructure. Bypassing conventional PR workflows requires reliable safety nets. According to the author, their process depends on targeted ~30-second rollbacks, hourly codebase maintenance, and an exceptionally low revert rate. Without equivalent tooling, skipping review steps introduces substantial risk.

Third, credential isolation is an essential boundary. When cloud agent loops ingest untrusted external events while sandboxes have code execution capabilities, prompt injection poses a real hazard. Long-lived credentials should not be exposed directly in model contexts; models should be able to trigger credentialed tasks without having raw secrets readable in context.

Finally, when chat windows no longer serve as the primary interface, how people monitor dozens of background tasks and step in when needed remains an area where standard UI conventions have yet to settle.

My Own Small-Scale Version

While managing multi-agent development on perryOS, I encountered many of the friction points of session bloat, which led to a few practical habits:

• Avoiding sequential tasks in long sessions: When I used to dispatch tasks to sub-agents, I would send round after round inside the same long session. The session file for one of the worker agents bloated past 20MB, forcing every request to carry the entire conversation history, which slowed down responses and made the model prone to distraction and unnecessary file reads. The main agent's own session could grow to 12MB in an hour, mostly driven by screenshots and lengthy command outputs.
• Starting clean sessions per round: Once one round passes acceptance and before dispatching the next, I have the worker start a fresh session (using /clear or /new), rather than letting history pile up indefinitely.
• Documents serve as memory, not the chat window: Fresh sessions carry no historical context, so relevant background—design decisions, implementation plans, and previous results—is recorded explicitly in task briefs or handoff documents. The session is ephemeral memory; the document is the durable record.
• Lead agents follow the same handoff pattern: The orchestrating agent also avoids running in one continuous session. At the end of each round, it records conclusions, decisions, and next steps in a handoff document. When its own context grows too large, it restarts from a fresh session and reads the document to continue.

What I'm Still Unsure About

Pushing sessions into the system substrate makes sense architecturally, but a few open questions remain:

First is subtle semantic drift in environment coordination. Codebases and business logic rely on implicit assumptions. When multiple agents commit frequently without talking to each other, even if unit tests pass, keeping their shared understanding of the architecture aligned over time remains tricky.

Second is the return on investment for small teams. Assembling a runtime with Routers, worker sandboxes, event listeners, and credential proxies involves notable upfront work. For solo developers or small groups, it is not always clear whether the attention saved outweighs the maintenance effort required to keep that infrastructure running.

Questions I Want to Figure Out Next

• When chat windows move to the background, what interface patterns (such as status timelines, kanban flows, or state graphs) let a person track multiple background tasks in seconds and step in with minimal friction?
• How can we structure lightweight credential isolation so local or cloud agents can interact with GitHub and cloud APIs without leaking tokens into model prompts?
• Similar to the Dreams mechanism described by Anthropic, how can we build compact offline routines that distill agent logs into durable guidelines while filtering out outdated assumptions?

References

• *Exploring Super-agent Design: Towards a More Autonomous Agent System*: Published on X by the DeepSeek Harness team (led by Yujia Qiao et al.) on November 1, 2026. Discusses the Super-agent architecture, frames multi-tasking limits around human attention across 3–5 active sessions, introduces a two-tier division of labor (Router for coordination, isolated Workers for execution), evaluates pass-through benefits under synthetic workloads, and highlights credential safety boundaries.
• *Anthropic engineers 90-minute course on building AI agents (AI Engineer World's Fair)*: An Anthropic engineering session from the AI Engineer World's Fair, shared by Anatoli Kopadze on October 30, 2026. Covers the Claude Managed Agents architecture, decoupling the system into Session (append-only ledger), Brain (stateless reasoning harness), and Hands (isolated execution tools), alongside credential proxying, Outcome-based task evaluation, and the Dreams memory distillation routine.
• *How I Built the Most AI-Pilled Company in the World*: Published on X by Spawn founder jacob (@jsnnsa) on October 29, 2026. Recounts running a team alongside an active agent fleet to eliminate waiting through Stigmergy (coordinating via shared code and live state) and direct production issue loops, focusing human effort on taste and non-linear goals, while emphasizing reliance on long-task model consistency and fast rollback infrastructure.