Designing an Agent Like a Company (Part 1): How a Task Gets Delivered

The DeepSeek Harness team recently published an architecture article, “Super-agent Design Exploration: Toward More Autonomous Agent Systems.” Here is my attempt to read this technical piece from the perspective of how a company operates.

The article points out that today’s agents treat a single session as the basic unit, while a person can typically follow only three to five sessions at once. The ceiling for a single task is therefore set by the model, and the ceiling for multitasking is set by human attention. Simple extensions through a CLI, MCP, or connectors do not remove three problems: a single session blocks, context gets muddled across tasks, and work stops when the device goes offline.

This resembles a small team with no management structure: everything sits in one person’s head, and he takes phone calls while doing the work himself.

So how does a company organize itself to run smoothly?

• One external point of contact. Clients deal only with an account manager, salesperson, or project team, and never need to know who does what internally.
• Grouping by project or business line. Each group handles only its own clients and tasks, without interfering with others or speaking directly to another group’s clients.
• Direct access through project channels. Follow-up communication on a project goes straight into the project group, rather than through the boss every time.
• Dedicated follow-through. Someone who does no business work and only checks whether things are truly moving forward.

These four arrangements solve the same problem: they ensure that limited management attention is spent only on matters that genuinely require judgment.

When the article discusses the two-layer architecture, it describes how to maintain global continuity while supporting high-concurrency execution. In doing so, it lays out the costs of two extreme designs, which match what companies have learned from experience:

• Everything in one session. Context stays the most continuous, but execution is serial and slow, intermediate details from different tasks blur together, and quality declines. It is like having one person serve every client from start to finish.
• A new, independent session for every task. Throughput is highest, but when tasks are not fully independent, results become fragmented, and multiple sessions replying to the user separately makes the interaction chaotic. It is like having several colleagues contact the same client at the same time.

The Super-agent, Mapped Piece by Piece

• The Router layer is the account manager. It is always on, handles human interaction from every entry point, and consolidates all cross-task information and decisions. To keep it from becoming a bottleneck, it does not execute tasks itself and may not even be given a Bash tool. Its work is often simpler than expected, and a lighter model is frequently enough.
• The Worker layer is the project team. Each Worker has an isolated context, a full set of execution tools, and a single task to focus on, so it is usually given the most capable model. Workers do not talk to humans directly. They report only to the Router, which replies to the user in one voice. When needed, a Worker can create its own Subagents, which remain transparent to the layer above.
• Subscription and pass-through are the project group chat. Consecutive events under the same GitHub Pull Request or the same IM topic form a Thread. Once a Worker subscribes to a Thread, later events go to it directly from the program, bypassing the Router. A Thread can also be subscribed to by several Workers at once. They receive the same notifications and can spot and resolve conflicts themselves, with no point-to-point communication, just as two project teams collaborate in a shared project group.
• Event filtering is the front desk and the secretary. In real group chats and code platforms, most messages need no agent involvement. The article uses two levels of filtering: program rules first remove most irrelevant messages, then a model, guided by a policy written in prompts, decides whether the remaining candidate events call for action.
• The Watchdog is the follow-through role. It is a session independent of the main system, driven by scheduled messages. It handles infrastructure failures and also judges whether each Worker is making real progress.

Together, these pieces mirror how a mature organization operates.