Agent Architectures Keep Going in Circles—DeepSeek Harness at Least Makes Clear Who Does the Work

Mario Zechner recommended an architecture article about DeepSeek Harness on X. He said he had talked with @tianyi, and that the DSH team is one of the few teams in the harness space still doing innovative things. The directions he mentioned were very specific: a single, long-lived entity; ad-hoc, free-form, potentially recursive task delegation; and cross-system event ingestion and triggering. He mentioned that earendil is also moving in a similar direction.

One commenter summarized the core of the long article in one sentence: what limits an Agent's productivity ceiling is often attributed to model intelligence, but the more direct constraint is humans' limited attention bandwidth. People can only follow a limited number of sessions at once; no matter how smart the model is, someone still has to look at results, make judgments, and deal with stuck threads.

The most time-saving part of the discussion was an architecture diagram. One commenter broke the system into several parts: external event Triggers come in from GitHub Issues, PRs, CI, and Feishu messages and are handed to Router, the central orchestrator Agent, which manages global context, determines priority, assigns tasks, and sends unified responses; Worker A/B/C fix bugs, review PRs, and run tests respectively; at the very bottom is Watchdog, which independently monitors, recovers from anomalies, and checks progress.

Another diagram separates the Router layer from the Worker layer, emphasizing that continuity and parallel processing can both be achieved. The idea is not new, but the diagram is easier to understand than the terminology: the main thread stays unblocked, concrete tasks are handed off to workers, and events keep pouring in from outside.

The questions in the comments are more useful than the praise. Someone asked what comes next, since the README says some features are not yet in the prototype. Someone asked what would interrupt the main Agent while it is working. Someone directly complained that tokens and cloud agents are too expensive. Someone else asked what people think of Firstmate's model of a persistent main session plus temporary collaborator sessions. These details determine whether this architecture can be used day to day.

Giuseppe demonstrated a similar practice on X: built on Pi Durable, the main thread acts as a control panel coordinating threads and stays unblocked; each thread is an infinite chat with memory; you can use @ to target a thread. In the video, you can see threads still working, waiting for a human answer, and needing to be reopened after timing out. Someone in the comments said manually copying thread IDs is painful and hoped t3 code would support it directly. Someone else replied, 'word salad.' There are indeed a lot of terms, but once the control plane and execution plane are separated, the pain points become concrete: interruption policy, memory persistence, cost, cross-system event deduplication, permissions, and how Router prioritizes when flooded by events.

Looking at it, the key to this direction is not just spinning up more Agents. If Router becomes a single point, the main Agent's context and judgment quality become the bottleneck; with more Workers, observability and recovery matter more than spinning up more of them. The fact that Watchdog is drawn separately shows that people are starting to admit Agents crash, get stuck, and time out. The original article and the discussion are both on X; look at the diagrams first, then decide whether to read the long article.

Original post: https://x.com/badlogicgames/status/2116997870213906524

DeepSeek Harness article: https://x.com/i/article/2116829218935857152

Giuseppe's demo: https://x.com/giuseppegurgone/status/2116232891114066092