The real bottleneck for Agents is that you can only keep an eye on 3 to 5 sessions at a time

Developer Rohit spent two days immersed in the super agent source code of DeepSeek Harness (hereinafter DSH) and wrote a series of notes. His opening judgment deserves to be singled out: if you are building an Agent, what limits you is no longer how deeply the model can think; it is you. A person can keep track of roughly 3 to 5 active sessions at the same time. Beyond that, contexts start contaminating each other, and the cost of manual switching is higher than model inference.

The official DSH architecture long-form article explains this thoroughly: the bottleneck of multitasking is people, not the model. So they removed sessions from the product layer and stuffed them into the system as an implementation detail. Users face one continuous Agent, while several Workers run in parallel underneath without interfering with each other.

Rohit's notes are basically validating this split. He summarized 5 things you can take away directly, each with concrete practices.

Separate routing from execution

A Router layer only deals with people and dispatches work. Each job is assigned to a Worker. The Worker carries its own context and has a full set of tools, but never speaks to the outside directly. The Worker's reasoning process and tool-call records stay internal, and the Router replies to the human uniformly.

This solves the most awkward part of the old architecture: a single session running ReAct has to finish one step before moving to the next, and new messages that arrive midway can only queue. DSH's data shows that the single-session design had a p95 completion time of 29.5 minutes in simulated workflows, while the Super-agent architecture reduced it to 15.7 minutes. The difference is not all model speed; it is mainly the scheduling method.

Filter events at the code layer

Incoming events first pass through deterministic rules: source, sender, permissions, allowlist. Most noise dies at this layer and never reaches the model. Only candidate events that pass the initial screening enter the LLM for semantic judgment.

Rohit's advice is to run in observe mode first, see what the rules block and what they let through, and only let it actually act after confirming there are no problems. This is the same idea as DSH's Fast Path / Slow Path: never ask the model what code can decide, saving both tokens and latency.

Open a ticket for each job

Record two things: who authorized this job, and how far it can go. Replaying the same trigger still produces only one ticket, so work does not start twice.

Someone in the comments asked whether the ticket model is reliable for multi-step human approval. Rohit's reply was quite honest: the waiting part can hold up, but the gating part cannot yet. Tickets can survive restarts. When a stuck Worker asks a specific question, the answer can be routed back to the same Worker. But approvals are currently written in the prompt, not enforced by code. For multi-step approval, you need to add explicit gate states to the ticket (plan approved, change approved, deploy approved), and the host refuses to proceed when the states are incomplete.

This passage is more worth noting than his 5 summaries. The reliability weakness of Agent systems is often not in capability, but in constraints.

Send follow-ups directly to the Worker

PR comments, approval results, CI receipts, and other follow-up events do not need to go through the Router again. Continuous events in the same Thread are passed directly to the Worker that has already subscribed to it. The Router only appears during cold start and cross-task coordination.

DSH's experimental data shows that without this direct pass-through mechanism, the Router makes about 30% more decisions per round, and cache-read tokens rise from 23.2M to 31.8M, an increase of 37%. Task completion time does not change noticeably. In other words, direct pass-through is not for speed; it is to keep the Router from being dragged down by repetitive work.

Design for crashes

Store replies before sending them. On retry, it can find the GitHub comment that has already been sent, and a restarted Worker can pick up the same workspace and continue.

This point sounds the least sexy, but it is exactly the dividing line between long-running tasks and non-long-running tasks. An Agent running for a few minutes versus running in the background for several days involves completely different orders of engineering requirements.

Where the moat is has changed

Someone in the comments dropped a line: the harness moat is already dead. Rohit answered directly: the inner-loop layer is indeed dead; opencode, pi, and codex are all open source and good enough. The moat has moved up, to authorization, tickets, recovery, and knowing when to shut up.

This judgment has its merits. Model capabilities are rising, and scaffolding is open source. What remains genuinely hard is how to make a continuously online system not act randomly when the human is absent, and clearly explain what it did when the human returns. The Watchdog, permission boundaries, and context granularity that repeatedly appear in DSH's long-form article are all work in this direction.

Rohit added one last point: everyone should build their own harness according to their own scenarios, and should not expect products like Claude Code to leave openings for them. This is not new, but coming from someone who spent two days reading someone else's source code, it carries a different weight.

Reference sources: Rohit's tweet thread (@rohit4verse), the DeepSeek Harness architecture article "Exploring Super-agent Design", and public discussion in the comments.