I Built the Same Agent Harness as DeepSeek. I Was One Step Too Late.

1. The Collision

This spring I started building a harness design. By autumn, the main body was almost finished. I had stopped at large-scale comparative experiments. Then I read the DeepSeek Super Agent article. One line stayed with me: “Similar design constraints lead to similar architectural choices.” I sat in my chair for a while. Different paths, same destination. I was one step behind.

Top-voted comments focused on event-driven design, full-duplex communication, and storage-compute separation. Those are reasonable choices at the runtime implementation layer. DeepSeek’s engineering quality is clear. But after I took that layer apart, I felt it missed the core of the idea. The core issue is different. Base models can now support a shift in agent engineering from process-oriented work to object-oriented work.

2. Hiring Is Buying Context Isolation

Let’s look at a development team first.

Why does a large company team hire? Apart from leaders and researchers, most roles do not involve hard new algorithms or obscure stacks. In many cases, employees function as the leader’s subagents.

Hiring saves time. The more important function is protecting the leader’s context from dirty engineering details. The leader does not need to know the two thousand lines of logs someone scrolled through while debugging a module. The leader does not need to remember every strange API behavior in a dependency. Local members absorb those details. Decisions, results, and risks travel upward.

From an information-organization view, one hard function of a large engineering team is context isolation. Human org structure is a context topology.

So where does the current LLM get stuck on a large project? It gets stuck when every concrete implementation process fills its cognitive load with dirty details. While writing, it forgets high-level requirements. While debugging, it loses architectural constraints. After reading thousands of lines of logs, it stops being the agent responsible for project state. It becomes an executor trapped in a local process.

That is the process-oriented agent. It is not dumb. Its context has been eaten by the process.

3. Everything Is an Agent

Java says everything is an object. The next model for agent harnesses, I think, is that everything is an agent.

This does not mean every function call becomes an agent. It means every concrete work process is carried by a subagent, and every complex requirement is owned by a leader agent.

Read Super Agent through that lens. The main agent never touches low-level business work. For any concrete task, it spawns a subagent and gives it acceptance criteria. When the subagent finishes, it leaves a report and assets, releases the thread, and leaves a short document. In the original wording, concrete work leaves the Router and goes to a context-isolated Worker Session.

The main agent faces requirements and users. It manages project state and requirement implementation. Its cognitive load stays low: what the requirement is, what acceptance criteria apply, which artifacts exist, which risks need escalation, and where the project stands.

If a subagent sees that its requirement is too large, it changes its own type into a department leader and spawns more subagents. Requirements decompose downward. Context is isolated downward. Results and risks flow back upward in compressed form. This looks like a self-organizing human company.

4. Why It Must Be an Architectural Primitive

Why not give a single agent a subagent tool and tell it in a prompt to delegate when appropriate?

Because if the model decides on the spot whether to divide work, it will fall back to process orientation.

The ablation in Section 7.1 of the original article matched a small-sample experiment I ran in July with GPT5.6 sol. Under a neutral prompt, a single Session with a subagent tool did not delegate once across five runs. Even when the prompt prioritized delegation, one run still judged the task “very small” and did it alone. That produced a long tail.

The long tail matters. It shows that when the model has only local information, it underestimates the need to delegate. It sees the code in front of it and thinks, “It is faster if I do it myself.” It cannot see that the code is dragging it into process orientation, consuming context that should stay reserved for high-level state and requirement consistency.

So the subagent must be a first-class citizen. Delegation cannot depend entirely on the model’s live judgment. As an architectural primitive, it should be governed by contracts, budgets, depth, and acceptance gates.

One caveat: first-class does not mean fine-grained spawning for every tiny task. Spawning an agent for every small job adds scheduling cost, acceptance cost, latency, and recursive bloat. The rule is not “always delegate.” The rule is “delegation is a standard action in the architecture, not something we pray the model remembers.” Thresholds can be configurable. Policies can be learned. The primitive belongs in the architecture.

GPT6.1 sol follows instructions better. In my small-sample tests, prompt optimization now works fairly well. Does that weaken architectural enforcement? Not completely. A strong model can execute a prompt strategy better. Architectural enforcement still matters because it does not depend on one model judgment being stable, and it does not depend on the long tail staying away. In long-horizon engineering, stability beats one-off cleverness.

5. Peer Multi-Agent vs. Hierarchical Subagent

I have long thought peer multi-agent setups are weaker than hierarchical subagents in most tasks. I softened that judgment later, but the core holds.

Peer multi-agent usually means N independent samples for one task, then aggregation. It adds computation, throughput, and diversity. It fits independent search, independent review, parallel verification, and multi-plan sampling. Its weakness: casual slicing for parallelism creates integration cost, and the slices have no guaranteed consistency in requirements or context.

The main value of a subagent is a change in context topology. The structure is: long-term high-level context, then temporary local context, then artifact, then compressed backflow.

The leader holds long-term high-level context: requirements, constraints, acceptance criteria, project state. The subagent gets temporary local context for one piece of work and does not pollute the main agent. When it finishes, it produces an artifact and a short report. Those flow upward in compressed form. The thread is released. The main agent keeps a short document.

Hierarchical subagents protect context and requirement consistency because they layer context instead of chopping tasks into random pieces. Peer structures mainly add computation and diversity. Hierarchical subagents mainly change context topology. Most long-horizon engineering tasks need the second more. Review, verification, and search work can keep peer structures.

6. State Management

“Everything is an agent” by itself is a slogan. State management is the hard part.

The main agent does not touch low-level business work. That sounds light, but it still has to manage project state and requirement implementation. What does it manage?

A requirement DAG. Requirements are not a flat TODO list. They form a graph with dependencies, priorities, acceptance criteria, and parent-child relationships. Complex requirements break into sub-requirements. Sub-requirements attach to the right leader or subagent.

An acceptance criteria schema. The main agent cannot hand the subagent a long vague prompt. It needs an acceptable contract: inputs, outputs, boundaries, what counts as done, what counts as failure, and which artifacts must remain. Poor acceptance criteria turn the subagent into another process-oriented executor.

An artifact registry. The subagent cannot just say “done.” It leaves reports, assets, change records, and risks. The main agent maintains project state through artifacts instead of rereading every process detail.

An agent tree and thread lifecycle. Who owns which requirement? Which thread has been released? Which subagent became a department leader? What is still running? Which failures need escalation?

Compressed summary backflow. Local context cannot pour back into the main agent unchanged. Decisions, results, risks, and necessary indexes flow upward. Compression is an operation on information topology, not a summary paragraph.

Failure escalation, budget, and permissions. What happens when a subagent fails? Retry, change strategy, escalate to the leader, or split the task? How is budget allocated? Where are permission boundaries? What depth limit prevents recursive bloat? Without answers, the self-organizing company structure becomes a romanticized recursive spawn.

I will write a separate piece on state management: how agents maintain requirements and how large engineering projects should design this structure.

7. What Humans Do

Human work moves up the stack.

Humans write requirement documents and acceptance criteria. For their own domain, they tell the Leader agent how to write requirement documents and acceptance criteria. Humans become requirements engineers, acceptance officers, and organization designers.

This sits higher than prompt writing. Prompts are process-oriented. Requirement documents and acceptance criteria are object-oriented. You define what the object is, what the contract is, what counts as done, what counts as failure, and how risks escalate. You do not define every step.

The line “employees are the leader’s subagents” is useful, but an organization does more than isolate context. It also has responsibility boundaries, verification, trust, and incentives. In the agent version, those become acceptance gates, audits, failure escalation, and budget constraints. Add them, and the self-organizing company structure stops being empty.

8. Open Source

My implementation stopped at large-scale comparative experiments. Strict experiments now have low marginal return. Experiments still matter. I am one step behind, and piling up broad proof is less useful than handing over what exists.

In the next couple of days, I will organize the work into a plugin and open-source it. The positioning is a portable delegation protocol plus a reference implementation of state management, not another Super Agent. The core interface:

spawn(contract) -> artifact + summary + risk -> dispose

Around it: requirement trees, acceptance criteria, budgets, permissions, escalation rules, and recursion-bloat prevention.

I will keep a minimal ablation: single session plus tool vs. first-class delegation; peer slicing vs. hierarchical contracts; with and without acceptance gates; context pollution and cost in long tasks. The sample can be small, but it should report long-tail delegation rates and failure modes. As instruction following improves, the need for architectural enforcement can be cross-validated with weak and strong models under prompt optimization.

9. Next Step

I am one step behind. Independently arriving at the same architectural choice tells me the direction is sound. It does not settle the argument. The next step is concrete: organize the plugin and open-source it in the next couple of days. Then write the next piece on state management, covering how requirements are maintained and how large engineering structures should be designed. I want the title to be From Process-Oriented to Object-Oriented: Context Topology and Delegation Primitives for Agent Harnesses. The contribution sits in the conceptual layer, not the implementation layer.