Super-Agent Design Philosophy: Organizing AI Workers to Liberate Human Attention

Introduction

The author reflects on earlier observations that Agent development is shifting toward engineering challenges: context management, tool fallback, state machines, and long-task recovery. Building on the dsh-superagent-prototype codebase (specifically 000-philosophy.md), the article frames Super-Agent design as a management problem: how to organize division of labor, protect human cognitive bandwidth, and handle exceptions — all to "manage the oxen and horses well, liberate the boss." The guiding principle is: Take as little human attention as possible, and give as much value as possible.

Organization and Division of Labor: Router and Worker Layers

Traditional single-session Agents act like a one-person workshop: the model is both boss and worker, handling intent understanding, tool calls, and context retention serially. This leads to the common critique that Agent papers equal "prompt + while loop."

Super-Agent splits the system into two layers:

Router layer : a persistent global routing session that receives all human interactions, serves as the global sequence point, coordination point, and memory. It does not execute concrete tasks and may not even have a Bash tool, avoiding becoming a performance bottleneck.

Worker layer : ephemeral execution sessions created per work item, each with an isolated session and working directory. Workers do not communicate directly with each other or with humans; they report status to the Router, which unifies replies to the user.

Cognitive Bandwidth Management

Borrowing the management concept of "span of control," the author observes a human can effectively track only about three to five concurrent sessions; beyond that, context blurs. Super-Agent aims to offload this extra load:

Users always face a single Agent; sessions become an implementation detail.

Cross-channel context fusion: e.g., a user first proposes Plan A in IM, then switches to Plan B in a GitHub PR comment — the system recognizes this as a direction adjustment on the same task without re-explanation.

Only the main control session faces the human. Routine Worker progress stays internal; only decisions, acceptances, blockages, failures, abandonments, or answers destined for the user surface as messages. Questions become explicit help requests.

Output density adapts to channel: IM replies capped at ~100 words (excess rejected, requiring rewrite); longer results show a ~600-character inline summary with full content on the work-item result page. GitHub/email async channels require full background, changes, and verification — mirroring workplace reporting norms (chat vs. formal report).

A counter-intuitive trade-off: the system spends extra machine resources (more Workers = more compute, more state storage, async/batch complexity) because human attention is far more expensive than machine resources for teams juggling many tasks.

Exception Management

Applying Taylor's exception principle (managers handle only exceptions; routine work follows standards), Super-Agent uses a two-layer filter:

Fast path (programmatic rules) : deterministic checks on sender, group, whitelist — blocks most irrelevant messages.

Slow path (model semantic judgment) : remaining candidate events are evaluated by the model for relevance.

In system terms, this is fast path vs. slow path; in management terms, policy vs. exception handling by a manager.

Admission classification: messages from allowed senders or explicit mentions are handled directly; unmentioned messages are categorized by an admission table into explicit request, inferred candidate, or ignore.

Watchdog applies exception management to the system itself. A timer-driven Watchdog session forms an external control loop. It handles infrastructure faults (interface errors, state recovery failures) and uses the model to judge whether Workers are making substantive progress or deviating from overall goals. On anomalies it intervenes to repair; on transient external faults it re-checks until recovery. Because Watchdog is a full-capability Agent session, maintainers can query it in natural language or instruct it to adjust the main system (e.g., modify prompts, change trigger rules).

Context Management: Inline, Spill, and Chain Recall

Super-Agent treats the limited context window as a cache, borrowing concepts from compiler optimization and computer systems:

Inline : inject recently used, high-probability information directly into the current context window to avoid extra tool-call round trips.

Spill : keep overflow or low-frequency full information outside the window, retaining only a reference or summary for on-demand retrieval.

This follows the locality principle: start with minimal info (object IDs and summaries), then incrementally inline associated content along relationship edges until the length budget is hit, leaving a continuation entry point. Applied consistently across events, threads, and execution sessions, this yields chain recall : every object has a unique ID; injection includes the next-hop associated object IDs, forming a reference graph. The model can traverse from the current event → its thread → related execution session → another code-review thread, expanding context hop by hop.

Speculative Execution

Analogous to CPU branch prediction, speculative execution hides latency by doing work before the user explicitly requests it. Example: upon receiving a meeting invite, the system background-checks calendar conflicts, gathers background materials, and drafts a reply — ready for user review. The key is hiding wait time; human-perceived latency is decoupled from actual system time. This consumes extra background compute to trade for reduced human waiting and intervention cost. Asynchronous ReAct solves foreground blocking; speculative execution solves background lead time — they address different problems.

Separation of Compute, State, and Execution Environment

Current local Agents bind compute (ReAct loop), persistent session state, and execution environment (code repo, local toolchain) on one machine — sleep or network loss stops the Agent; device switch breaks continuity. Super-Agent separates in two steps:

Compute becomes stateless elastic cloud containers; session state moves to a database. Containers can restart, replace, or scale horizontally; continuity is guaranteed by storage, freeing the Agent from a single device's lifecycle.

Execution environment stays local; only a lightweight, stateless daemon runs on the endpoint, executing commands and returning results. The cloud reads environment context on demand through this daemon.

Full-Duplex Human-Agent Interaction

Classic ReAct loop is half-duplex: user sends a prompt, the session runs blocked until done. Super-Agent moves to full-duplex (like interrupting a worker without stopping their current work). The diagram illustrates this shift.

Conclusion

The next step for Agents is not just smarter models, but a harness that organizes that intelligence. Super-Agent's goal: liberate human attention — manage the AI workers well, free the boss.