1. About This Report
The subjects of this report are "Super-agent Design Exploration: Toward a More Autonomous Agent System", published by the DeepSeek Harness team on 31 October 2026, and the two sets of experimental data that the article makes public. Wherever the text says "the original", it refers to that article; wherever it says "recomputation", it refers to the recalculation this report performs on the data made public in the original, with the formulas given in the body of the text so that readers can check them for themselves.
This report does not evaluate the team's product, nor does it evaluate its model capabilities. The original is an architecture note that contains three kinds of content at once: design claims, engineering simplifications and preliminary experiments. This report treats the three kinds separately: design claims are tested by logic, engineering simplifications are treated within the boundaries the original states for them, and experimental data are recomputed on a basis that permits recalculation.
1.1 Evidence Grading
Every judgment in this report carries a source grade so that readers can judge its reliability.
- E1: explicitly stated in the original and verifiable word by word.
- E2: recomputed directly from the data made public in the original, with the formulas given in the body of the text.
- E3: estimated by this institute, relying on the assumptions identified in the body of the text.
- E4: external published literature, with sources cited; the retrieval date is 31 October 2026.
Recomputation follows two disciplines. First, no data that the original does not disclose is introduced to complete a conclusion; where the material is insufficient, the point is entered in the list of unresolved items at the end of the report, and no substitute reading is given in the body of the text. Second, figures derived by this report are not mixed with source figures in the same conclusion; every derived figure is labelled separately.
1.2 Relation to Existing Discussion
A dense layer of retelling formed on the very day this architecture note was published. Media outlets including IT之家, 驱动中国, 观点网, 读懂AI时代 and 同花顺 issued digests of the main points within hours, with closely similar headlines and content concentrated on three sets of labels: "the Router and Worker two-layer architecture", "four characteristics" and "five modules". This layer of information is highly repetitive and does not constitute independent analysis.
Above this layer, a type of technical commentary has already appeared. One fairly representative opinion holds that concurrency is not collaboration, and that scheduling is not orchestration; the original pushes the branching, parallelism, result merging, dynamic replanning and cross-acceptance that complex engineering requires down into the Worker, so the original difficulties are not resolved but merely moved down one layer. This judgment holds, and this report does not repeat it, but gives a more specific mechanistic explanation in Section 5: the root of the problem is that the Router simultaneously carries two duties, routing and global memory, whose scalability requirements conflict.
The operating-system analogy has been a mature topic from 2025 to 2026. The mapping of the context window to memory, of retrieval augmentation to paging, and of context overflow to thrashing has been discussed repeatedly in a body of work including LLMOS, AgentOS and vMem, and several open-source implementations are modelled on it. The original shares the same set of metaphors with this body of work. This report therefore does not treat the analogy as a novel insight; it uses the analogy instead as a testing instrument, pointing out in Section 6 the four places where the analogy fails and setting out the primitives that those failures require.
The judgment that "verification bandwidth is the real constraint" has likewise been systematically advanced in the economics literature. In "Some Simple Economics of AGI", Catalini, Hui and Wu model verification bandwidth as a second curve racing against the cost of automation, and introduce the concept of the "measurability gap": when the cost of execution falls exponentially while the cost of verification is bounded by physiological and organizational limits, the gap between the two continues to widen. Section 8 of this report takes this as a premise; the increment lies not in proposing this constraint, but in dividing application scenarios into three classes by acceptance latency and showing that the original architecture holds in only one of them.
That "the side effects of speculation need to be committed in stages" is also discussed in the 2026 systems literature, in directions including staged side effects, reversible sandboxes and transactional tool invocation. Section 6 of this report connects this conclusion to the speculative execution design of the original, points out that it lacks a commit boundary, and gives the primitives corresponding to two kinds of channel, instant messaging and code review.
In addition, "treating tried and failed paths as first-class memory objects" has become an independent line of research. This report cites that line when discussing long-term memory in Section 5, but does not adopt it as a claim of its own.
1.3 The Increments This Report Claims
To avoid presenting existing discussion as original work, this section lists in one place the five items of work that this report considers its own. Each has a corresponding formula, table or criterion in the body of the text and can be checked independently.
First, the Router's utilization is recomputed from the batch-processing data made public in Section 7.2 of the original, yielding a utilization of approximately 0.93 at roughly 40 Triggers per minute, thereby refuting the original's judgment that "the single-Router throughput bottleneck has not yet been reached" (Section 3).
Second, it points out that the dependent variable of Section 7.1 is inconsistent with the dependent variable claimed throughout the article, and that the experiment lacks one key control condition—forced delegation. Without this control condition, the architectural effect cannot be separated from the prompt effect (Section 4).
Third, it identifies the coupling of the Router's routing duty with its memory duty as the structural source of the long-term memory bottleneck, and proposes the log sequence number rather than the session as the sequence point (Section 5).
Fourth, it proposes a sixth module missing from all five of the original's modules—settlement (结清)—and sets out its three required elements: a state machine, a reaper and a budget (Section 7).
Fifth, it divides application scenarios into three classes by acceptance latency, shows that the original architecture holds only in the first class, and gives the direction for adapting the second class of scenario (manufacturing sourcing) (Section 8).
Of the five items above, the first and the second are recomputations of already published data and can be reproduced by readers one by one; the third, the fourth and the fifth are design judgments and fall within the range of what is arguable. The conclusion of this report distinguishes these two kinds of judgment and does not present design judgments as verified facts.
2. Structured Restatement of the Original Claims
To test an architecture note, its propositions must first be stated clearly. The argument of the original can be broken into seven propositions.
- P1: The ceiling for a single task depends on model capability, and the ceiling for multiple tasks depends on human attention; as execution-side dependence on people declines, the bottleneck limiting further efficiency gains is shifting toward human attention.
- P2: The session should be an implementation detail of the system and should not become a cognitive burden for the user.
- P3: A two-layer architecture can obtain both cross-channel continuity and multi-task throughput.
- P4: Event-driven design can turn the Agent from passive execution into active response.
- P5: The separation of computation, state and environment can achieve persistent online presence across devices.
- P6: An external Watchdog can achieve self-healing from anomalies during long-running operation.
- P7: The above propositions hold under real workloads.
This decomposition is not over-demanding. At the beginning of Section 7 the original itself states that "because the experiments are based on synthetic workloads and a simplified environment, some settings could be made more rigorous, and the following results serve only as a preliminary reference". This sentence defines the scope of the evidence, and this report merely converts that scope into propositions to see which of them fall inside it.
2.1 The Correspondence Between the Four Characteristics and the Five Modules
The original proposes four basic characteristics: continuity, efficiency, proactivity and persistence. The five modules support these characteristics respectively. Setting out the correspondence in a table shows that the coverage is uneven.
| Module | Core mechanism | Corresponding characteristics | Evidence given in the original | Extent of experimental coverage |
|---|---|---|---|---|
| Two-layer architecture | Persistent Router plus isolated Worker | Continuity, efficiency | Section 7.1 completion-time comparison, Section 7.2 batch-processing stress test | Partially covered |
| Event-driven | Trigger, Thread, subscription pass-through, chain of recall, speculative execution | Proactivity | token comparison for "removing pass-through" in Section 7.1 | Only the pass-through item is covered |
| Human-facing interaction | Asynchronous ReAct Loop, multi-channel output specification | Continuity, efficiency | No experiment; the original states "already implemented in DeepSeek Harness, but not yet enabled by default" | Not covered |
| Separation of computation from state and environment | Stateless cloud Loop plus device-side daemon | Persistence | No experiment | Not covered |
| Watchdog | Independent session driven by an external timer | Persistence | No experiment | Not covered |
This table must be read with caution. Not covered does not mean not established. The capabilities described in Sections 5 and 6 may well already hold in engineering terms; they have simply not been made public in experimental form. What this report points out is something else: the persuasiveness of this note is unevenly distributed. What readers most easily remember are the p50 and p95 of Section 7.1, yet these two numbers support only "the two-layer architecture shortens task completion time under synthetic workloads"; they do not support the three more appealing capabilities, "persistent online presence", "self-healing from anomalies" and "cross-device takeover".
For an engineering note, such unevenness is normal. But it has a consequence for dissemination: when the media retell it, the four characteristics and the five modules are set side by side as conclusions of equal certainty, whereas in fact their evidential strength differs by an order of magnitude. This report treats them separately in the following sections according to evidential strength.
2.2 Two Places Where the Original Does Better Than Most Comparable Texts
Before criticism, two merits should be acknowledged, because they are what make the recomputation in this report possible.
The first is the active disclosure of the boundaries of the experiment. The original states that the coding work is replaced by a tool that only consumes time, so that the experiment measures scheduling and collaboration capability rather than the execution capability of a single task; it states that message intervals and working durations are scaled by a factor of one quarter, and that model invocation latency is a real value; it states that each scheme is run five times. These disclosures allow readers to judge which conclusions can be extrapolated and which cannot. Most comparable texts give only conclusions, not boundaries.
The second is the explicit statement of the simplifying combination. In Section 8.1 the original writes out directly the simplifications on which it relies: "a single persistent Router Session + subscription pass-through + no direct communication between Workers", and states that this "covers most of our current everyday tasks at a relatively small engineering cost". This sentence in effect concedes that the architecture is designed for a particular scale rather than being a universal solution. All subsequent discussion of scalability rests on this self-statement.
The recomputation in Section 3 of this report is possible precisely because the original gives three numbers: the arrival rate, the batch size and the per-request latency. This completeness of data disclosure is rare among comparable engineering articles.
2.3 One Claim That Needs to Be Taken Apart
P1 is the starting point of the whole text: the ceiling for a single task depends on model capability, and the ceiling for multiple tasks depends on human attention. This sentence reads like a law, but it is in fact a description of the state of the current design. Its premise is that a person must carry two things at the same time: "tracking task status" and "bearing the consequences of tasks".
The scalability of these two things is entirely different. Tracking status can be outsourced—provided there are reliable records, retrieval and reminders, the number of tasks a person tracks can rise from a few to several dozen. Bearing consequences cannot be outsourced: to accept an output means that the acceptor is responsible for the correctness of that output, and the capacity for responsibility is bounded by professional judgment and organizational authorization, not by interface design.
What the original uses to support this judgment is an empirical observation: a person can normally follow only three to five active sessions at the same time. No sample, measurement method or population is given for this figure, and this report can only treat it as a rule-of-thumb figure. Mechanistically it may correspond to three different kinds of limit: the capacity of working memory, the cost of recovering from interruption, and the capacity to bear the consequences of how many things at once. The first two can be reduced through architecture and interaction; the third cannot. The original lumps the three together as "attention", so that proving the tracking cost has fallen appears to prove that the attention bottleneck has been relieved.
In substance, what the two-layer architecture of the original does is precisely this: it strips "tracking" away from the person. The Router maintains global memory, the Workers each hold local context, and the person faces only a single unified conversational entry point. This step is effective, and it is the most valuable part of this design. But it does not touch the second thing. The original lumps these two things together as "human attention", and thereby gains a convenience in argument: proving that the tracking cost has fallen appears to prove that the attention bottleneck has been relieved.
This report holds that this merger conceals the real problem. Once the two things are separated, a different conclusion follows: the Super-agent relieves the tracking bottleneck, not the acceptance bottleneck. And as the tracking bottleneck is relieved, the acceptance bottleneck will be exposed at a faster rate—because the number of outputs awaiting acceptance produced per unit of time has increased. Section 8 will develop this line.
This distinction also explains the hesitation in Section 8.2 of the original. There the original writes that, after detachment from the session, "how to present tasks to the user and provide a natural form of interaction and project management becomes a new problem", and holds that interaction centred on the chat window is "to a certain extent the result of path dependence". This judgment is correct, but the original classifies it as a product-design problem. This report holds that it is first of all a problem of measurement: once the system moves task status out of the human mind, the only work left to the person is acceptance, and the original gives no definition of the unit of acceptance, its cost or where responsibility lies.
3. Recalculation One: The Router's Throughput Headroom Is Overstated
Section 7.2 of the original gives a set of readings from the Router layer stress test, and this is the only stress-test sequence in the whole article that can be fully recomputed. The conclusion of this section consists of one sentence: computed from this set of readings, a single Router session is already running close to full load at the highest arrival rate measured, and the original's judgment that "the throughput bottleneck of a single Router has not yet been touched" does not hold.
3.1 The Readings the Original Discloses
The stress test in the original was run as follows: the Router called the real model and the Worker used a simulated model, and the arrival rate of Triggers requiring a decision was raised step by step from about 1 per minute to about 40 per minute, with three quantities observed.
| Arrival rate (items/minute) | Average batch size | Single-request latency (s) | Inference time amortized per decision (s) |
|---|---|---|---|
| About 1 | 1.0 | 2.5 | 6.4 |
| About 40 | 2.8 | 3.9 | 1.6 |
On this basis the original writes: single-request latency rose only from 2.5 seconds to 3.9 seconds, growing more slowly than the batch size, so that the inference time amortized per decision fell from 6.4 seconds to 1.6 seconds; this shows that when a sudden burst of external events causes congestion, the Router can raise effective throughput by automatically merging backlogged events, and therefore "at our current team size there is no need to horizontally partition the Router layer prematurely".
Every step of this reasoning relies on an unstated premise: that single-request latency is pure service time, and that the batch size is the result of an active choice made by the system. Once these two premises are written out, two other readings become visible.
3.2 Recomputing Utilization with Queueing Theory
Let the arrival rate be λ (items/second), the average batch size be b, and the single-request latency be S (seconds). In a queueing system with batch service, the proportion of time the server is in the busy state is
- utilization ρ = (batch arrival rate) × (batch service time) = (λ / b) × S.
Substituting the two sets of readings from the original yields the following.
Low-rate end: λ = 1/60 ≈ 0.0167 items/second, b = 1.0, S = 2.5 seconds, giving ρ ≈ 0.042.
High-rate end: λ = 40/60 ≈ 0.667 items/second, b = 2.8, S = 3.9 seconds, giving ρ ≈ 0.929.
That is to say, across the whole stress-test interval the utilization of the Router rises from about 4% to about 93%. This is not a bottleneck that has "not yet been touched", as the original describes it; it is already running pressed against the bottleneck. In a queueing system at utilization 0.93, waiting time is extremely sensitive to small fluctuations in the arrival rate; the ratio of average waiting time to service time diverges rapidly as utilization approaches 1.
This calculation rests on three assumptions, set out one by one here. First, it assumes that what the original calls "single-request latency" is service time rather than response time including queueing. Second, it assumes that the batch size in the table is the average value at that rate rather than an instantaneous value at a particular moment. Third, it ignores arrival correlation between batches and the variance of service time. Under these three assumptions, ρ ≈ 0.93 is a central estimate; even if the batch size is raised to 3.0 and the service time lowered to 3.5 seconds, ρ is still about 0.78, and the direction of the conclusion is unchanged.
3.3 Where the Batch Size Comes From
There is a further problem more worthy of attention: the figure of 2.8 for batch size is almost exactly equal to "the number of Triggers newly arriving during one service period".
By definition, if batching is simply "events arriving during a service period are merged into the next call", then b ≈ λ × S. Substituting the high-rate end: 0.667 × 3.9 ≈ 2.60. The batch size actually measured in the original is 2.8, a difference of about 8%, within the range of measurement error. The low-rate end is the opposite: 0.0167 × 2.5 ≈ 0.04, far smaller than 1, so the system degenerates to processing one item at a time, consistent with b = 1.0 in the table.
This agreement shows one thing: the "batching mechanism" described in the original is, in this set of data, indistinguishable from the natural backlog of an ordinary queueing system. The Router has no additional scheduling policy actively accumulating batches; during the processing of one request it merely gathers newly arrived events into the queue and then handles them together in the next round. This is a phenomenon that any single-threaded server exhibits under network load, and it requires no dedicated design.
The significance of this distinction lies in the interpretation of the metric. If batching is an active policy, then "the decline in time amortized per decision" can be read as an efficiency gain; if batching is merely the natural result of backlog, then this metric is a queueing statistic, and the reason it declines is that a fixed service cost is spread over a wait that grows ever longer, not that the system has become faster. The original chooses the former interpretation but gives no evidence that could distinguish the two.
3.4 The Scale Elasticity of Service Time, and Why It May Not Persist
Fitting the two points in the table to a power law gives
- S = 2.5 × b^0.432.
Fitting a power law to two points is in itself very weak evidence, and it is used here only for an order-of-magnitude judgment. This gives the capacity of the system (the number of items that can be decided per second)
- C = b / S = 0.4 × b^0.568 (items/second), that is, about 24 × b^0.568 items per minute.
Substituting different batch sizes yields:
| Batch size | Service time (s) | Capacity (items/minute) |
|---|---|---|
| 1.0 | 2.5 | 24 |
| 2.8 | 3.9 | 43 |
| 8.3 | 6.2 | 80 |
| 17 | 8.5 | 120 |
| 30 | 10.9 | 166 |
On this curve, taking 40 items per minute as the baseline, doubling capacity to 80 items per minute requires a batch size of about 8.3; raising it to 120 items per minute requires a batch size of about 17. If each Trigger occupies about 500 to 2000 tokens in the Router context, a batch size of 17 corresponds to 8500 to 34000 tokens, far below the context length of current mainstream models.
Two judgments follow.
First judgment: the ceiling that the original describes as "depending on context length" is not tight at the current order of magnitude. Context length would become a constraint only when the batch size reaches the hundreds, and by then the capacity of the system would already have reached several hundred items per minute, beyond the event volume of a single team. What actually becomes binding first is a different ceiling—the second half of the same sentence in the original, "how many Triggers the model can accurately process in one round". This curve was not measured.
Second judgment: the elasticity of service time with respect to batch size, 0.432, is itself questionable. If the benefit brought by batching came from what the original calls Prefill parallelism, then with a fixed batch of requests and only the input tokens increased, the computation of Prefill would grow roughly linearly with the number of tokens, service time should approach S ∝ b, and elasticity should approach 1; capacity C = b/S would then be a constant, and batching would bring no throughput gain at all. The measured elasticity is only 0.432, which indicates that a large block of service time is fixed overhead unrelated to batch size—context assembly, tool calls, state reads and writes, and state reads and writes. The benefit is more likely to come from the amortization of this part of the fixed overhead than from Prefill parallelism.
The two mechanisms carry different engineering implications. If the benefit comes from the amortization of fixed overhead, then it varies with the system implementation, and a different scheme of context assembly may make it disappear; if it comes from Prefill parallelism, then it is a stable property of the model inference layer. The original attributes the benefit to Prefill but does not rule out the fixed-overhead explanation.
3.5 The Most Important of the Three Metrics Is Missing
Section 7.2 of the original reports three quantities: average batch size, single-request latency, and the inference time amortized per decision. All three describe the server side.
For the property of being "proactive", the quantity that actually determines the experience is the "event-to-decision" latency, that is, the time a Trigger takes from entering the system to the Router making a dispatch decision. This quantity equals queueing wait plus service time. In a system at utilization 0.93, queueing wait is typically substantially greater than service time and has high variance.
The original does not report this quantity. Within the scope of the original's data, therefore, it cannot be judged how much "proactive response" remains under a load of 40 items per minute. This is a gap that can be closed by additional measurement: it requires only recording, in the stress test, the entry time and the decision time of each Trigger and taking the quantiles.
3.6 The Boundaries of This Section's Conclusions
This section does not say that this architecture cannot be used. On the contrary, by the recalculation, this architecture is stable under loads below 40 items per minute, and a team message volume of 40 items per minute is already not small. This section has only two conclusions.
First, the original's description of headroom does not match the actual data. A utilization of 0.93 means headroom on the order of ten percent, not a bottleneck that has "not yet been touched", as the original describes it. This bears directly on engineering decisions: a reader who plans capacity on the assumption that "there is still a large amount of headroom" will encounter a nonlinear rise in queueing time when the load rises slightly.
Second, the original explains this phenomenon as a throughput mechanism of the Router layer, whereas the shape of the data supports "natural backlog" better. This does not affect the usability of the system but does affect its transferability—if a team follows this description and implements a scheduler that "actively accumulates batches", it may find the benefit far smaller than expected, because the benefit measured in the original never came from the scheduler in the first place.
4. Recalculation Two: The Variable the Experiment Measures and the Variable It Claims Are Not the Same
Section 3 dealt with how the data are to be read. This section addresses an earlier question: whether this set of experiments tests what it intends to test.
4.1 The Mismatch Between Claim and Measurement
The starting point of the original is P1: the limit on multitasking depends on human attention. The architectural goal derived from this should be to increase the number of tasks a person can advance per unit time. That is a human-throughput metric.
What Section 7.1 of the original measures, however, is "task completion time": the elapsed time from a work request to the result message, taking p50 and p95. That is a single-task latency metric. The original also gives cumulative completion curves for the four configurations, which contain throughput information; but the statistics the main text uses for ranking are p50 and p95, and it gives no human-throughput metric, nor does it run a forced-delegation control condition. What this section criticizes is the statistics and the control design, not the existence of the curves.
The two are not monotonically related. A system can perfectly well reduce single-task latency while reducing human throughput—if it produces more small outputs that require human acceptance, the person's switching cost rises. Conversely, a system can also raise single-task latency while raising human throughput—by accumulating several tasks and accepting them together in one batch, latency rises and the number of acceptances per unit time increases. Using an ordering by single-task latency to support a conclusion about the attention bottleneck is therefore a matter of construct validity: the variable measured is not the variable the claim is about.
This is not nitpicking. Section 4.1 of the original itself proposes full-duplex interaction, whose purpose is precisely "to accept new instructions at any time without waiting for the previous command or task to complete", which is a throughput claim. If the experiment measures only latency, then the entire asynchronous ReAct Loop module is empty as far as the experiment is concerned.
4.2 The Missing Control Condition
Section 7.1 compares four configurations: the full Super-agent, the Super-agent with pass-through removed, a single session with a sub-agent tool under a neutral prompt, and a single session with a sub-agent tool under a delegation-preferring prompt.
These four configurations omit one: the single session with forced delegation.
Forced delegation means that the harness unconditionally hands each work request to a new sub-agent, without leaving the decision to the model. This configuration differs from the "delegation-preferring prompt" by a single implementation detail—replacing the prompt that "suggests delegation" with code that "requires delegation"—and is otherwise entirely the same.
Why is this control condition critical? Because the original's own data already hint at its importance. Under the neutral prompt, the model did not invoke the sub-agent even once across five runs; after the change to the delegation-preferring prompt, it invoked it in four of the five runs, but in one run it still judged the work "very small" and chose to execute it itself, forming what the original calls the purple long tail. This description shows that the delegation prompt markedly changes the delegation rate; the one long tail that still appears under an explicit prompt can be attributed to the model's misjudgment of its own workload. As to whether the single-session structure itself loses marks, that requires the forced-delegation control condition before it can be judged.
If the forced-delegation control condition were added, two outcomes are possible.
In the first, forced delegation is roughly on a par with the two-layer architecture. This would mean that the main value of the two-layer architecture lies not in "two layers" but in "removing the model's discretion over delegation". This is a very valuable conclusion, and its implementation cost is extremely low—a few lines of harness code, requiring no Router, no subscription, and no chain of recall. For the vast majority of teams, this is a choice far more cost-effective than the entire architecture.
In the second, forced delegation still lags clearly behind. Only this would show that the two-layer architecture brings a structural benefit, such as the convergence of output that comes from the Worker not replying directly to the outside, or the reduction in Router load that comes from subscription pass-through.
The original does not run this control condition, so it cannot distinguish these two cases. The differences in p50 and p95 that it reports are compatible with both the "the architecture is better" explanation and the "mandating is more effective than suggesting" explanation.
4.3 What a Sample of Five Can Support
Section 7.1 repeats each configuration five times. At this sample size, reporting p95 calls for caution: the ninety-fifth percentile of five observations cannot be reliably estimated; computed by order statistics, it falls between the two largest observations, close to the maximum. The two figures "p95 of 15.7 minutes" and "p95 of 29.5 minutes" are therefore more accurately read as "the slowest of the five runs was 15.7 minutes and 29.5 minutes respectively".
Likewise, the observation that "under the neutral prompt the sub-agent was not invoked in any of the five runs" can, statistically, only push the upper bound of the invocation rate down to about 45% (the exact binomial upper bound for zero successes: 1 − 0.05^(1/5) ≈ 0.45). It cannot support the stronger judgment that "the model will not delegate on its own initiative".
These points are not a rejection of the original. The original itself states that the results are "for preliminary reference only". What this report seeks to flag is the risk at the layer of retelling: when these figures are excerpted by the media as "p95 cut in half", the certainty that readers receive is far higher than the data themselves can supply.
4.4 The Order of Magnitude of Cost
The original gives a valuable but easily overlooked figure: in a single experiment, the full Super-agent consumed 23.23 million cache-read tokens, which rose to 31.77 million after pass-through was removed, an increase of about 37%. A single experiment contains about 300 messages, of which about 20 are work requests.
Converting this into unit cost:
- cache-read tokens per work request ≈ 23.23 million ÷ 20 ≈ 1.16 million.
- tokens saved by the pass-through mechanism ≈ 31.77 million − 23.23 million = 8.54 million, 37% of the full version.
The original gives no pricing, and this report introduces no external prices either, only the ratio: if cached reads are priced at one tenth of the input price, then the full-price-equivalent input tokens per work request are about 116,000. This order of magnitude means that the cost center of this architecture is not "executing tasks" but "repeatedly reading context". The more complex the task and the longer the session, the faster unit cost rises.
There is also a question of load structure. Of the 300 messages, only 20 are work requests, 6.7%. The Router must read all messages before it can judge which one requires action, so the great majority of its compute is spent processing non-work messages. This is a necessity of the design, not a defect—the price of proactivity is having to read all of the input. But it means that the cost figures the original reports depend heavily on this 6.7% ratio. In a team with a higher share of work messages, unit cost falls; in a group with a higher share of casual chat, unit cost rises. The original does not state the real-world basis for this ratio.
4.5 The Minimal Experimental Design If It Were Redone
This report does not argue for overturning the original's conclusions, only that these conclusions require a supplementary experiment of no great cost. The minimal design is as follows.
Adopt a 2×2 factorial design. The two factors are: whether delegation is forced (code-enforced / model discretion), and whether the architecture is two-layer (single session / Router plus Worker). Each of the four combinations is run no fewer than twenty times, with the load following the original's synthetic message stream so as to permit comparison.
Two dependent variables are taken. One is single-task completion time, for alignment with the original; the other is a proxy metric for human throughput, for example "the number of work requests completed within a fixed human budget (say, checking once every ten minutes and handling at most five pending acceptance items per check)". The latter metric is the quantity that P1 is about.
At the same time, two curves are recorded: the "event-to-decision" latency and the "pending-acceptance queue length". The former closes the gap identified in Section 3; the latter corresponds directly to the acceptance bottleneck to be discussed in Section 8.
The cost of this design is far lower than rebuilding the entire system, but it can separate the three effects that the original currently conflates—the architecture effect, the mandating effect, and the measurement effect. For teams preparing to adopt this architecture, this distinction determines how much implementation cost they will pay.
5. Structural Diagnosis: Routing and Global Memory Sit in the Same Session
Section 3 showed that the Router's headroom is smaller than the article describes. This section points to a more fundamental problem: part of the reason the Router approaches full load so quickly is that it simultaneously carries two responsibilities whose scalability requirements conflict with each other.
5.1 The Router's Triple Identity
The description of the Router in Section 2.1 of the article can be broken into three sentences.
The first sentence: "All cross-task information and decisions are aggregated in the Router layer, which serves as the global sequence point (Sequence Point), coordinator, and memory." This sentence assigns three things to a single component: global ordering, cross-task coordination, and long-term memory.
The second sentence: "The Router layer, by design, does not directly execute specific tasks; it is responsible only for human interaction and task dispatch, and may even be equipped without Bash tools." This sentence positions the Router as a lightweight dispatcher and suggests the use of "a lighter model."
The third sentence: "In our practice, the Router layer's tasks are often not as complex as one might imagine, and using a lighter model often suffices to balance speed and quality."
Taken together, the three sentences yield a rather unstable structure: the component with the most complete information in the system uses, on the article's recommendation, a lighter model; the only component in the system that holds the global facts is a session that may be restarted, replaced, or constrained by context length.
The article is not unaware of the risk. It writes immediately afterward: "To prevent this global node from becoming a performance bottleneck for the system, the Router layer by design does not directly execute specific tasks." That is, it has seen the throughput bottleneck and avoids it by "not executing specific tasks." But it does not handle another kind of bottleneck: the volume of memory.
5.2 The Conflicting Scalability of Two Responsibilities
Routing and memory place opposite demands on context.
Routing wants context to be short. The input to a routing decision is "which recipient this event should go to," and the information required is the current task table, the subscription relationships, and a small amount of recent state. The longer the context, the higher the cost of each decision, the greater the latency, and the more dispersed the attention. In the recalculation of Section 3, single-request latency rises with batch size, and the rise in batch size in turn comes from queue backlog—which already shows that cost is sensitive to the scale of the context.
Memory wants context to be long. Global memory must answer "why that task changed its approach three months ago," and the information required is the complete history and the reasons for decisions. The shorter the context, the less reliable the recall.
Putting the two into the same session yields an inevitable result: every routing decision pays for the entire memory. The article's aggregate data are compatible with this diagnosis—approximately 1.16 million cache-read tokens per work request, while the actual "work" in the experiment is merely an empty tool that consumes time. But the article does not give a breakdown between Router and Worker, so this aggregate can serve only as circumstantial evidence and cannot prove the point on its own.
This coupling also brings three secondary consequences, all of which manifest in long-term operation.
The first is availability. In Section 5.1 the article stores session state in a database and relies on persistent storage to guarantee continuity, and this step is sound. The problem is that global memory is still carried by a single context window and has not been externalized into a queryable view; consequently, the extent to which a restarted session recovers "the same" global memory depends on whether the context can be rebuilt, and the article does not describe this rebuild path.
The second is replaceability. To change the model the Router uses, one must migrate the memory at the same time. This binds model upgrades to architecture upgrades, making incremental replacement difficult for a team.
The third is evaluability. To compare the merits of two Router strategies, each must maintain its own memory, or the comparison does not hold; yet once each maintains its own, the two memories diverge. The cost of evaluation is therefore far higher than for a stateless component.
5.3 Moving the Sequence Point from the Session to the Log Sequence Number
The article uses the expression "sequence point (Sequence Point)"; this report uses the term "sequence point" from here on. The term comes from database and logging systems and means "a position in the global order." In this context, the function of the sequence point is to provide a unified timeline for cross-task events, so that "occurred before," "occurred after," and "concurrent" have determinate judgments.
In a logging system, a sequence point is a monotonically increasing number, usually called a log sequence number. It is a value, not a process. A process can crash, restart, be replaced, or scale horizontally, while the log sequence number does not change; any component that remembers which number it has processed up to can resume from the correct position after a restart.
By placing the sequence point in a resident session, the article hands the responsibility of a value to a process. This brings two unnecessary constraints: the availability of the global order depends on that process surviving; the integrity of global memory depends on that process's context length.
A more stable structure separates the two.
The event log serves as the single authority, recording all Triggers, dispatch decisions, Worker state changes, and external actions in append-only fashion, with each record carrying a monotonically increasing sequence number. The Router session holds only two things: the sequence number it has processed up to, and a capacity-limited working set (a concept drawn from operating system research on program locality). Global memory does not belong to the Router; it is a materialized view derived from the log—task tables, decision tables, thread tables, and rejection tables—which can be rebuilt at any time and queried by any component.
Under this structure, the chain of recall in the article becomes something else. The article's chain of recall is one in which "each recalled object inlines the ID of the next associated object, supporting hop-by-hop expansion of context along reference relationships"; it depends on the Router's context holding these IDs, and on the Router knowing in which direction to hop. Once changed to log queries, recall becomes a conditional retrieval: given a point in time or a task identifier, retrieve all events of that task and the proposals of that task that were rejected. The former depends on the model's memory; the latter depends on an index.
This revision does not conflict with Section 5.2 of the article; it is in fact closer to the scheme that the article itself cites. In Section 5.2 the article writes that its approach "is consistent with the 'decoupling the brain from the hands' (Decoupling the brain from the hands) proposed by Anthropic, likewise keeping the harness stateless and storing session logs outside the harness." The core of that Anthropic design is precisely this: a session is a persistent append-only log stored outside the model's context, and after the harness crashes it re-reads the log by session identifier and recovers from the last event. The article accepts this, but applies it only on the Worker side; on the Router side it still places global memory inside the session.
Thus the problem here is not "the article did not think of statelessness," but "statelessness is only half done." The Worker's harness is stateless, while the Router's memory is stateful; the system's global continuity therefore still hangs on a single process. Section 8.1 of the article concedes that "long-range memory thus becomes the main bottleneck constraining scalability"; on this section's reading, the source of that bottleneck is not that memory is stored in insufficient quantity, but that memory is placed in the wrong location.
5.4 An Immediately Testable Inference
If the above diagnosis holds, a specific phenomenon should be observable: after long-term operation, the Router's per-decision cost rises with operating duration, and the magnitude of the rise correlates with the total volume of tasks and not with the current load.
The stress test in the article is short-duration and cannot reveal this. But the cost data in Section 7.1 of the article already offer a hint: a single experiment of 300 messages consumes 23.23 million cache-read tokens. How this number would change when the time scale is extended to several weeks is not reported in the article. This is a quantity that can be measured directly on the existing system: regress the input token count of each Router call against the length of the log at that time; if the slope is significantly positive, the diagnosis holds.
5.5 The Second Problem Introduced by Hidden Sessions: No Deduplication Key
The article makes a rather elegant judgment: "A Session should be an implementation detail of the system, not a cognitive burden for the user." This judgment holds at the interaction level. But a session is not only a cognitive unit; it is also a deduplication unit.
In traditional single-session designs, when a user repeatedly sends the same request, the system can at least see "this is a second input in the same session," and thus perform within-context duplicate detection. Once sessions are hidden, the same intent can arrive through different channels: first stated once in instant messaging, then supplemented in an email, then raised as an issue on the code platform. At the underlying level these three events are three different Triggers, coming from three different Threads, with no common identifier.
The subscription and pass-through mechanism in the article solves the routing problem of "subsequent events within the same Thread"; it does not solve the merging problem of "different Threads expressing the same intent." The latter requires semantic duplicate detection at the global level, and at the global level there happens to be only the Router, which happens to be specified as a lightweight model.
A dilemma thus arises: either the Router uses a strong model for semantic duplicate detection, raising cost and latency, or it uses a lightweight model, in which case duplicate-detection accuracy is insufficient and duplicate tasks appear. The cost of a duplicate task is not a little extra computation, but two Workers advancing in parallel on the same external target, producing conflicting external actions.
This dilemma is, in this report's view, the most concrete problem worth addressing in the next version of the design. It has a low-cost solution: perform a structured extraction when an event enters (who, wants what, what the object is), use the extracted triples for exact matching, and hand only the unmatched ones to semantic duplicate detection. This moves most of the duplicate-detection work from the model to code, which is the same idea as the "programmatic fast path plus model slow path" that the article itself adopts in event filtering—except that the article applies it to filtering, not to duplicate detection.
6. Testing the Analogy: Where the Operating System Metaphor Fails
Section 9 of the article writes: "We do not propose an entirely new theory; rather, we apply classic engineering ideas from computer systems to the construction of an Agent system." This statement is accurate, and it is an honest self-positioning. This section's task is to push that statement to its limit: since the entire design rests on an analogy, the points where the analogy fails are the points where the design is at risk.
6.1 The Analogy Is No Longer a Novel Insight
One thing must be clarified first, lest readers mistakenly believe that this report proposes a new framework. Analogizing Agent systems to operating systems was already a mature topic in 2025 and 2026. Around the correspondence of "the context window is memory, retrieval augmentation is paging, context overflow is thrashing," a batch of names and implementations appeared, such as LLMOS, AgentOS, and vMem, and several open-source projects manage context directly according to the semantics of page tables, working sets, and page-fault handling. Authors in China have also given a set of correspondences: the large model is the new CPU, the context window is the new memory, the database is the new disk, and the Agent is the application.
Therefore this report does not treat the analogy as a contribution but as a testing instrument: if the analogy holds, it should be able to predict failure modes that the article does not discuss; if the analogy fails at some point, that point is the real boundary of this architecture.
6.2 Correspondences
First list the correspondences in full, then examine them one by one.
| Operating system concept | Counterpart in Super-agent | Strength of correspondence |
|---|---|---|
| Process | Worker Session | Strong |
| Process control block | The Worker's context and tool configuration | Strong |
| Scheduler | Router | Moderate |
| Interrupt | Trigger | Strong |
| Interrupt affinity | Thread subscription pass-through | Strong |
| Cache | Information inlined in the context window | Strong |
| Swap-out | Spill outside the window | Strong |
| Multi-level page table walk | Chain of recall | Moderate |
| Hardware watchdog | Watchdog session | Strong |
| User mode and kernel mode | Privilege separation between Worker and Router | Inverted (the Router has fewer privileges) |
| Process ID | No counterpart | Missing |
| Transactions and commit | No counterpart | Missing |
The correspondences in the first nine rows hold; the tenth row runs in the opposite direction, in that the Router has fewer privileges than the Worker, contrary to the usual rule that kernel mode outranks user mode; and the last two rows have no counterpart in the article. These three places are precisely what this report considers most in need of being supplied.
6.3 Failure One: The External World Cannot Be Rolled Back
Section 3.4 of the article borrows from speculative execution and writes that "if the result has value, deliver it; if it has none, discard it."
In a processor, this statement holds, because the results of speculative execution are written to registers or the reorder buffer, and the cost of discarding is a few clock cycles. In an Agent system, the statement holds only inside the sandbox. Once a speculative product crosses the sandbox boundary—sends a group message, submits a merge request, sends an email, makes a call to an external interface—it is no longer discardable. The example given in the article is precisely one that crosses the boundary: while the discussion in the group is not yet finished, the Agent has already submitted a merge request for the fix in the background. That action occurs in the external world and cannot be undone on the grounds that "the result has no value."
This point has already been addressed in 2026 systems research. Around transactional execution for Agents, a group of designs has appeared—"staged side effects," "commit gate," "reversible sandboxes"—which write external actions into a staging area first and release them for real only after validation passes. Optimistic concurrency control in the database field long ago gave the same structure—execute first, then validate at the commit stage, and roll back if validation fails; and rollback is possible because none of the writes have yet been written to disk.
For this architecture, this means that speculative execution needs an additional stage that the article does not describe. A Worker may freely try things inside the sandbox, but before its products cross the sandbox they must rest in an inspectable, discardable form: a draft email, an uncommitted branch, a message awaiting sending. The commit step should be executed by a policy gate, not by the Worker itself.
6.4 Failure Two: Side Effects Are Not Idempotent
Operating system system calls can be retried after failure, because the kernel guarantees the semantics of most calls. An Agent's external actions do not satisfy this: sending a message is not an idempotent operation, submitting a merge request is not an idempotent operation, and telephoning a customer even less so.
Section 5.2 of the article describes a scenario in which retries are inevitably encountered: the connection between the device-side daemon and the cloud-side Loop may be interrupted, and the device may be intermittently online, so that "after one of the user's personal devices comes back online, the cloud-side Agent automatically triggers and completes the tasks that need to be executed on that device." In this scenario the same command may be executed twice, because the cloud cannot determine whether the first execution took effect.
Solving this problem requires idempotency keys, and the idempotency key must be generated by the initiator and issued along with the task; it cannot be generated by the executor. The article does not discuss this. This is not a detail that can be left until the implementation stage: the location of the idempotency key determines the design of the task identifier, and the task identifier in turn determines the log structure.
6.5 Failure Three: A Person Is Not an Interrupt Controller
An interrupt can preempt any instruction, and the cost of a context switch is on the order of microseconds. People are not like this. Human response latency is measured in minutes to hours and is unpredictable; a human "context switch" costs on the order of ten minutes. Classic research on interruption cost gives the order of magnitude: an interrupted piece of work takes on average more than twenty minutes to return to its original task state.
Therefore the "full-duplex interaction" of Section 4.1 of the article holds at the system level; at the human level it is only "non-blocking," not "real-time." This distinction has practical consequences for design: if the system assumes that a person can respond at any moment like an interrupt controller, it will tend to initiate confirmation requests frequently; and every confirmation request is an interruption of a person, whose cost is far higher than waiting on the system side.
In Section 4.2 the article gives a very good rule of thumb: a single reply should not exceed one hundred words, and the user should be notified only when a decision or acceptance is needed. The direction of this rule is right. But it is a constraint at the prompt level, not a guarantee at the structural level. To make it hold reliably, "under what circumstances a person may be disturbed" must become a decision condition of the policy gate rather than a matter of the model's self-discipline.
6.6 Failure Four: The Cost Function of Swapping Out Is Different
In an operating system, the cost of swapping out a page is slowness: a page fault requires a disk access. In an Agent system, the cost of forgetting may be irrecoverable: once certain information leaves the context, it can never be retrieved again.
The Inline & Spill design in the article assumes that "complete information exceeding the window budget or used infrequently is kept outside the context window, with only references or summaries retained inside the window for the model to read on demand." This assumption holds for objects that can be re-read—files, code, and comment history can all be read once more. But it does not hold for information that appears only once in a conversation: a constraint the user states orally, a trade-off decided provisionally during discussion, a proposal that was rejected.
The characteristic of this kind of information is that it has no corresponding readable object. It exists only in the context of that moment. Once it is spilled, the reference points at nothing.
This leads to the kind of memory that this report believes the article most ought to add: negative memory. What a team truly lacks is often not knowledge of "what it has done," but of "what it has tried and why it did not work." The former usually leaves artifacts behind—code, documents, merge requests; the latter usually leaves nothing. And the chain of recall depends on an ID graph, which can index only objects that have artifacts. A rejection has no artifact, and therefore cannot be indexed.
Existing research calls this class of objects negative knowledge or failure memory, and points out that its retrieval semantics differ from those of positive memory: positive memory can be recalled by semantic similarity, whereas negative memory must be matched exactly by condition, because "a similar failure" may well be an entirely different failure. This judgment corroborates the diagnosis in Section 5.3 of this report—the key to memory lies not in capacity but in whether the indexing method matches the type of object.
6.7 An Inference Where the Analogy Holds: Cache Coherence Will Break Down
The preceding sections discussed failures; this section discusses a valid prediction that the analogy gives in the reverse direction.
In an operating system, when multiple processors each cache the same block of memory, a cache coherence protocol is required; otherwise one processor changes the data while another still uses the old value. In the article's design, Workers do not communicate directly, each holds an isolated context, and they obtain the same events only by subscribing to the same Thread. This guarantees coherence within "the same Thread."
But global decisions are not inside Threads. The Router may have adjusted a task boundary midway, changed a priority, or rejected a proposal. These changes occur in the Router session and are not automatically propagated to Workers already running. The Worker holds the old assumptions from the moment of dispatch, and it is still executing external actions.
By inference from the analogy, the first serious incident of this system in production will most likely not be a process crash, but two Workers advancing simultaneously on mutually contradictory global assumptions, both producing side effects externally. This inference can be guarded against with a very lightweight mechanism: attach a version number to global decisions, and have the Worker verify, before executing any external action, whether its own version number is still valid; if not, it pauses and reports back to the Router.
The cost of this mechanism is very low, but the article does not mention it. This report lists it as the principal recommendation of Section 6.
6.8 Summary
The operating system analogy holds in the four sets of relations—process, interrupt, cache, and watchdog—and yields useful design intuition; it is missing in two places, transactions and process ID, and these two happen to correspond to what this report considers the weakest areas of this architecture: the commit boundary of external actions, and cross-channel task deduplication.
A more general observation is this: the operating system can make these mechanisms reliable because it controls the hardware; an Agent system does not control the external world. Wherever an action involves the external world, the analogy weakens; wherever an action involves only the system's internal resources, the analogy is strong. The article's design is quite complete inside the system and leaves more blank at the boundaries, which is consistent with the "engineering and scenario simplification" that the article itself acknowledges.
7. The Missing Sixth Module: Settlement and Reclamation
The source text supports four characteristics with five modules. This report holds that the structure is missing one module, and missing it in a very orderly way: all five modules concern "how to start" and "how to continue", and none of them concerns "how to end".
7.1 The Shared Bias of the Five Modules
Consider the function of each of the five modules in turn.
The two-layer architecture addresses how tasks are assigned and executed. Event-driven design addresses how tasks are triggered and routed. Human-oriented interaction addresses how results are presented. The separation of computation, state and environment addresses how the system continues to exist when a device goes offline. The Watchdog addresses how the system recovers after an anomaly.
All five answer "how to get things running and keep them running". None answers "what the terminal state of a task is, and how the occupancy is released once that terminal state is reached".
A complete task lifecycle requires at least four stages: admission, execution, acceptance and settlement (结清). The source text covers the first three stages and not the fourth. When Section 8.2 of the source text discusses "how to collaborate with the Agent after leaving the Session", it addresses human participation at the stages of task initiation and result acceptance, and still does not touch the terminal state.
This absence does not surface in a short demonstration. If the system runs for three days with few tasks, the residue cannot be seen. But the target form of the source text is precisely "always online" and "long-running", and the residue problem appears only under long-running operation.
7.2 Five Kinds of Residue
On this report's analysis, this architecture produces five kinds of residue under long-running operation.
Zombie task. The task is in the "in progress" state but makes no substantive progress. The Watchdog in the source text judges "whether each Worker is making substantive progress and whether its direction deviates from the overall goal", and this step is correct. But the source text gives the Watchdog only one disposition: intervene and repair. Whether a task whose repair fails continues to hang or is abandoned is not stated. A task that neither advances nor terminates continues to occupy context, occupy subscriptions and occupy budget, and remains "in progress" in global memory, thereby contaminating the Router's judgment.
Orphaned subscription. The source text describes that a Worker may cancel a subscription on its own initiative, but does not describe automatic revocation and reference counting when a Worker terminates. Subsequent events continue to pass straight through to a session that no longer exists or has already ended. At best this wastes compute; at worst it produces erroneous replies. Subscriptions are many-to-many, so revocation requires precise reference counting, and the source text does not describe lifecycle management for subscriptions.
Speculative residue. Discarded speculative results still occupy storage indexes. The source text says "discard it if it has no value", but what is discarded is "adoption", not "deletion". Those attempts judged to be without value, if they do not enter an explicit archival or deletion process, will keep accumulating in storage and retrieval indexes.
Dangling reference. Chain of recall depends on an ID graph among objects. Any cleanup leaves dangling IDs in the graph, and a recall path breaks as soon as it passes through a dangling ID. The source text does not describe how referential integrity is maintained.
Unsettled commit slot. This item is newly added by this report after Section 6 recommended introducing the commit gate: if an external action first enters a staging area and is then committed, the staging area itself also requires a settlement mechanism. An action that has been prepared but neither committed nor cancelled will remain in the staging area indefinitely and be mistakenly committed during some retry. This is a new problem introduced by adding one mechanism, and it must be designed together with the settlement module.
What the five kinds of residue have in common is that most of them do not trigger alerts and mainly produce cost and uncertainty; among them, orphaned subscriptions and dangling references may also lead directly to erroneous replies and broken recall. They are therefore rarely caught by alerts, and usually manifest only as a slow rise in unit cost.
7.3 The Definition of Settlement and the State Machine
This report defines "settlement" as a decidable state comprising three conditions: the task has entered a terminal state; all four classes of resources occupied by the task have been released; and the terminal state and its cause have been written to the log.
The four classes of resources are external action slots, subscription relations, context storage and budget balance.
The corresponding state machine is as follows.
| Current state | May transition to | Transition condition | Must be recorded |
|---|---|---|---|
| Admission | Dispatch, Merged, Abandoned | Route determination, duplicate detection hit, or manual withdrawal | Admission source, basis of determination |
| Dispatch | Execution, Merged, Abandoned | Receipt by the Worker, duplicate detection hit, or rejection | Dispatch target, version number |
| Execution | Pending acceptance, Abandoned, Expired | Output completed, budget exhausted, silence timeout | Output identifier, consumption |
| Pending acceptance | Settled, Merged, Abandoned, Expired | Human acceptance, world receipt, manual withdrawal, timeout | Acceptance method, acceptor |
| Settled | Terminal state | — | Result receipt |
| Abandoned | Terminal state | — | Reason for abandonment, grounds for rejection |
| Merged | Terminal state | — | Which task it was merged into |
| Expired | Terminal state | — | Expiration threshold |
The state machine itself is not complex, but it enforces two things that are omitted in the source text: every task must have a terminal state; every terminal state must have a cause. The second directly produces the negative memory mentioned in Chapter 6 of this report — the reason for abandonment is the only negative knowledge that accumulates naturally.
The "Merged" row in the state machine deserves separate explanation. In scenarios where deduplication fails, the same intent produces multiple tasks. The correct handling at this point is neither to let them run in parallel and leave it at that, nor simply to cancel one of them, but to merge the later task into the earlier one and record the provenance of both events in the merge record. Merging is a subclass of settlement, and it resolves part of the deduplication problem at the same time.
7.4 The Reaper: Why It Must Be Deterministic
Settlement needs an executor. The Watchdog in the source text is a ready-made candidate, but it is not suited to carrying this out independently, for two reasons.
First, the Watchdog shares a common-mode failure with the main system. The source text uses a model to judge whether a Worker is making substantive progress, and this judgment itself depends on the same model family. If the model has a systematic bias in its understanding of "progress", the Watchdog will make the same class of error as the Worker. This is the inherent risk when the verifier and the verified share a common origin, known in statistics as correlated error: two judgments from a common origin agree closely, but their joint accuracy does not improve significantly merely because one more judge is added.
Second, an unreliable semantic judgment requires a deterministic backstop. Judging whether a task is "really finished" is a semantic question, and any model will err. Judging whether a task "has exceeded its budget" is an arithmetic question, and it will not err.
This report therefore recommends that the reaper take deterministic rules as its principal basis and semantic judgment as a supplement. There are four principal rules: settle if the budget is exceeded; settle if the silence period is exceeded; settle if the Thread to which the subscription corresponds has been closed; cancel if an external action slot times out without being committed. None of these four requires a model. Semantic judgment serves only as a supplement when a task appears to be "still moving but on a suspicious course", and its output may only trigger "escalation to a human" and may not directly change the task state.
This layering follows the same idea as the source text's own "programmatic fast path plus model slow path". The source text applies it to event filtering; this report holds that it applies equally to task reclamation, and is more necessary there — because the cost of an error in reclamation is higher than the cost of an error in filtering.
7.5 The Budget Should Be a First-Class Citizen
In the discussion of the source text, the budget is implicit: the Worker consumes tokens, the Router consumes tokens, but nowhere is it stated how much a single task may consume at most.
The absence of a budget definition carries a structural consequence: the system has no intrinsic stopping condition. A task can terminate only because it is "finished" or because "a human calls a halt", and neither is reliable. The former depends on the model's self-assessment; the latter depends on human presence.
Raising the budget to first-class status means allocating four limits at task admission: a token budget, a tool-call budget, a wall-clock budget and an external-action budget. When any one is exhausted, the task enters "Expired" and is settled with "budget exhausted" as the cause.
This brings two benefits. First, cost becomes predictable: the worst-case cost of a task is fixed at admission, which makes this architecture procurable, auditable and chargeable per project. Second, zombie tasks disappear automatically: a zombie is by definition "consuming continuously without producing", and budget exhaustion is a deterministic termination condition.
This report holds that the second point is the key step in moving this architecture from "an internal team tool" to "an enterprise-grade system". An enterprise may tolerate uncertain costs internally; a procurement process cannot.
7.6 Why This Gap Is Invisible in the Accounts
The concealment of the settlement gap derives from the way costs are apportioned.
A zombie task does not produce an identifiable expenditure. It consumes a little context each round, distributed across many calls; it reports no error, triggers no alert, and appears in no success-rate statistic for any task. Its only manifestation is a slow rise in cost per unit of output.
And this manifestation is indistinguishable from architectural overhead. The cost change reported in the source text is "a 37% increase in tokens after removing pass-through", which is an attributable change. The cost increase caused by zombie tasks has no such control condition, and is subsumed into the category of "this architecture is expensive in the first place".
Settlement gaps therefore appear in the form of "efficiency declining for no apparent reason" rather than in the form of "failure". This is also why this report advocates listing "the share of zombie tasks" as a routine metric — it is the only quantity that can separate this class of cost out of the general ledger.
8. The Acceptance Regime: Three Classes of Scenario, Three Architectures
Up to this point, the preceding four sections have dealt with whether this architecture is internally coherent. This section deals with an external question: in what kind of scenario it holds. This report holds that the answer depends on something the source text does not discuss — acceptance latency.
8.1 A Conclusion That Already Holds
It should first be stated that the starting point of this section is not new.
Treating verification as a binding constraint has already been argued systematically in the 2026 economics literature. Catalini, Hui and Wu, in "Some Simple Economics of AGI", propose that as the cost of execution declines exponentially, the real constraint shifts to the verification side: the human capacity to verify, audit and bear responsibility for results is bounded by physiological and organizational limits and cannot expand in step. The three authors call this asymmetry the "measurability gap", and infer that rents will migrate toward verifiable ground truth, provenance attestation and liability underwriting.
This conclusion is directly relevant to the question of this report, but it is a macroeconomic judgment and does not answer the architectural question directly. The increment of this section lies in bringing it down to the engineering level: classifying scenarios by the nature of acceptance, and stating the requirement that each class places on the architecture.
Scattered observations in industry point in the same direction. Around human-in-the-loop product design, a class of empirical judgment has already emerged: when review requests arrive several hundred times in succession and the overwhelming majority are normal, the reviewer degenerates into a rubber stamp, and a system that adds review checkpoints is at that point instead more likely to let dangerous actions through. This report has not obtained checkable primary research for this observation; it is entered in the list of unresolved items at the end of the document, and serves here only as a directional indication, not as evidence.
8.2 Two Dimensions and Three Classes of Scenario
This report divides scenarios along two dimensions.
The first dimension is inspectability: whether the output itself can be directly examined by a human. The second dimension is decidability: whether examination can determine the correctness of the output.
Crossing the two dimensions yields three classes of scenario with practical significance. The fourth quadrant (unreadable yet decidable) does not exist and may be ignored.
| Class of scenario | Form of output | Can a human read it | Can reading decide right from wrong | Typical example | Acceptance latency |
|---|---|---|---|---|---|
| First class | Changes and text | Yes | Yes | Code changes, copy, reports | Seconds to minutes |
| Second class | Decisions and lists | Yes | No | Sourcing lists, advertising placement lists, candidate lists | Days to months |
| Third class | Complex artifacts | No | No | Superhuman strategies, large-scale portfolio optimization | Cannot be accepted |
The difference among the three classes lies not in difficulty but in the nature of acceptance. Acceptance in the first class is review; acceptance in the second class is attribution; acceptance in the third class lies beyond human capacity and can rest only on ex ante constraints and process supervision.
8.3 The Architecture of the Source Text Covers Only the First Class
The entire design of the source text — from the Router aggregating Worker results, to "send a notification only when a decision or acceptance is needed", to "a single reply does not exceed 100 words" — rests on the same premise: a human can read the output and judge its correctness on that basis.
This premise holds in the first class. It also explains why the source text chooses R&D collaboration as its main scenario — code changes happen to be the most mature instance within the first class.
The first class has a property that the other classes lack: the output is self-evidencing. A code change contains, within the same medium, the information needed for judgment: what was changed, why it was changed, whether the tests pass, and whether other modules are affected. A reviewer can reach a fairly reliable judgment without going to the external world for evidence.
This property is not brought by the Agent; it is brought by fifty years of accumulation in software engineering. Version control makes changes comparable, tests make behavior verifiable, continuous integration makes results reproducible, and code review makes responsibility traceable. These four constitute a ready-made acceptance infrastructure. The reason the coding agent was the first to be deployed is largely that it landed on this infrastructure, not that its output is inherently easier to accept.
This judgment has a directly testable corollary: moving the same architecture into a domain without this infrastructure will produce a marked decline in returns. Not because the architecture has become worse, but because acceptance cost shifts from the system side back to the human side, and the human side has not been scaled up.
8.4 The Second Class: Acceptance in Manufacturing Sourcing Is Attribution
The manufacturing sourcing scenario belongs to the second class.
The output of a sourcing exercise is usually a list of enterprises, with contact details, main products, scale and location attached. The list is readable: every row can be understood. But it is not decidable: no manner of reading can tell you whether this enterprise will reply, whether it will quote, whether it can make this specification, or whether its lead time is credible.
Judgment can come only from the external world. Whether a message sent out receives a reply, whether a reply is followed by a quotation, whether a quotation is followed by a sample, whether a sample is followed by an order. The cycle of this chain is measured in weeks, and at its longest in quarters.
This has a direct consequence: spot-checking is not acceptance. Suppose that five of one hundred enterprises are in fact non-conforming; if ten are drawn at random and checked, the probability of finding at least one is about 41.6%; if the non-conforming rate is 10%, the probability is about 67%. That is to say, for a spot-check process that looks diligent, the probability of missing all non-conforming cases is above 30% at either rate. Spot-checking provides psychological reassurance, not quality control.
What the second class actually needs is attribution capability: when a lead ultimately does not convert, can the system answer "how did this lead come about"? Which query term recalled it, which filter condition it matched, what the confidence was at the time, who sent it out and when, and what the counterparty's feedback was.
To achieve this, there are three architectural differences from the source text.
First, the output of a Worker must be a structured object, not a prose summary. Each candidate enterprise needs to carry: an enterprise identifier, a source, the reason for recall, an evidence link, a confidence, and the time at which this record was produced. The Router in the source text compresses the Worker's results into a single paragraph and hands it to the user, and the direction of compression is opposite to the requirement of attribution — what the summary discards is precisely the fields that attribution requires.
Second, the outward output of the Router should be a to-do list, not a report. The human's role here is not reader but executor: to whom this batch of leads should be sent, in what wording, and when to follow up.
Third, the system needs a result write-back interface. Results from the world must be writable back into the same table and connected to the retrieval that produced them. None of the five modules in the source text is responsible for this, because it assumes that acceptance takes place inside the system.
These three differences can be reduced to one sentence: the acceptance layer in the first class is the review layer, and the acceptance layer in the second class is the settlement layer. The review layer answers "does this output look right"; the settlement layer answers "what became of this output afterwards".
8.5 The Three Fields of the Settlement Layer
To implement this architecture in second-class scenarios, this report recommends that the settlement layer record at least three fields.
Output identifier: which task, which query and which version of the filter conditions this output belongs to. It allows any subsequent result to be traced back to the action that produced it.
External action: in what form, at what time and to whom this output was sent. It connects "actions inside the system" with "actions in the external world", and is also the basis for attributing responsibility.
Result receipt: how the counterparty responded, including no response. No response is also a receipt, and the most important kind — it distinguishes two entirely different failures: "never sent out" and "sent out but no reply".
Once all three fields are in place, the definition of acceptance changes: from "a human clicked approve" to "the world issued a receipt". The substance of this change is the conversion of acceptance from subjective judgment into objective record, which makes acceptance scalable — because records do not require human attention.
The human role in the second class changes accordingly: from item-by-item reviewer to sampling auditor and exception handler. This differs from the human role in the first class, and is the same as the role of a quality control department.
8.6 The Third Class: Unverifiability and Ex Ante Constraints
Third-class scenarios are uncommon in the day-to-day operations of manufacturing, but they arise in some high-value decisions, such as large-scale capacity layout, cross-regional supply chain restructuring, and long-horizon investment portfolios. The correctness of such output exceeds human judgment capacity, and acceptance is in principle impossible to complete.
For this class, this report gives only a directional judgment: the viable path is not to raise acceptance capacity but to move the control point from after the fact to before it. Specifically, to change the role of the human from "judging whether the output is right" to "setting constraints and supervising whether they are breached" — budget ceilings, risk exposure, a list of untouchable items, and the stages that must leave an audit trail.
This is the same mechanism as the commit gate proposed in Section 6 of this report. The only difference is that the commit gate in the first and second classes mainly guards against model error, while the commit gate in the third class guards against insufficient human judgment.
8.7 This Section's Overall Judgment on the Source Text
Section 9 of the source text writes that, as models require less and less human intervention to execute a single task, "the bottleneck limiting further gains in productivity is shifting toward human attention", and the system enables "humans to move further up from concrete execution details to higher-level decision-making and acceptance".
This judgment holds in the first class, and the architecture given in the source text is effective in the first class. But it treats "acceptance" as a uniform action, whereas the nature of acceptance differs enormously across scenarios. The source text does not make this distinction, because it chose the scenario with the best conditions for acceptance.
This is not a defect of the source text. An architecture description addressed to its own R&D scenario has no obligation to cover other scenarios. But for teams preparing to adopt this architecture, the distinction is decisive: if their business falls in the second class, then copying this architecture will produce a system that runs well but cannot be evaluated — tasks are completed quickly, the interface is clean, but no one can answer whether these outputs are of any use at all.
Most of the high-value Agent applications that this institute has encountered in manufacturing sourcing scenarios fall in the second class. This is the single matter that this report believes most needs to be stated clearly.
9. Measurement: Turning Attention into a Computable Quantity
The original article takes "human attention" as the starting point of the entire architecture, but offers only the empirical observation that "a person can typically follow only 3 to 5 active Sessions at once", without providing an operational quantitative metric. This does not diminish the value of the architecture design, but it does render the architecture impossible to evaluate and impossible to improve.
9.1 The Four Metrics Reported in the Original Article
The original article reports four quantities in its experimental section: the p50 and p95 of task completion time, the number of decisions the Router must make, the total volume of cache-read tokens, and the batch size together with the per-request latency.
All four are system-side metrics. They can answer "how fast the system runs and how much compute it consumes", but they cannot answer "how much more work people get done as a result, and how many fewer errors they make".
For a system designed with humans as the starting point, this set of metrics is incomplete. More troublesome is that, when only system-side metrics exist, any optimization will naturally tilt toward the system side: lower latency and fewer tokens look like progress, even if they leave people more exhausted.
9.2 Eight Metrics Proposed as Additions
Most of the eight metrics in the table below can be computed from existing event logs, provided that the log fields are fixed during the architecture design stage; among them, M1 relies on manual spot-checking and M4 requires recording the time people invest in the system, so these two require separate data sources.
| ID | Metric | Definition | Computation | Use |
|---|---|---|---|---|
| M1 | Routing accuracy | Share of events dispatched to the correct Worker | Manual spot-check at 1%, with "misrouted or unnecessarily dispatched" counted as an error | Judge whether the Router is reliable |
| M2 | Pass-through hit rate | Share of all events that pass straight through via subscription | Pass-through events ÷ total events | Measure the Router's load structure |
| M3 | Tokens per accepted output | Token consumption per unit of accepted output | Total tokens in the interval ÷ number of accepted outputs | Primary metric of cost efficiency |
| M4 | Human minutes per accepted output | Human time required per unit of output | Total human time on the system in the interval ÷ number of accepted outputs | Directly corresponds to the attention claim |
| M5 | Speculative hit rate and waste rate | Share of speculative results adopted, and the cost of the discarded portion | Adopted ÷ speculative; discarded tokens ÷ total tokens | Judge whether speculation is worthwhile |
| M6 | Zombie task share | Share of tasks still in progress beyond the silence period | Zombie tasks ÷ total tasks | Measure the settlement gap |
| M7 | Duplicate task rate | Share of intents accepted more than once | Duplicate acceptances ÷ total tasks | Measure deduplication capability |
| M8 | Rework rate | Share of outputs returned for rework after acceptance | Returns ÷ acceptances | Measure output quality |
M3 and M4 are the two this report considers most important. M3 attributes cost to "accepted output" rather than to "tasks", a point that differs substantially from the original article's task-based accounting: a task that runs to completion but is accepted by no one should not count as output. M4 directly measures the quantity that P1 is concerned with; if this metric does not improve, then the entire architecture's claim about attention has not been validated.
M6 and M7 correspond to the two gaps identified in Sections 7 and 5 of this report. Their role is not to improve performance but to make the gaps visible. A system that does not measure the zombie share will believe that everything is in order.
9.3 Define the Log Fields First, Then the Architecture
All eight metrics depend on the same set of fields: event identifier, thread identifier, task identifier, state transition, consumption, executor, acceptance method, and external receipt.
This set of fields should be fixed before the architecture is settled, because the fields determine the capability boundary of the system. For example, if the log records only "task completed" and not "task accepted", then M3 and M4 can never be computed; if the log does not record "who accepted it", accountability cannot be enforced.
Section 3.3 of the original article treats the context window as a cache to be managed, and this is a sound approach. The same approach can be extended to the log: the log is not a debugging by-product but a first-class asset of the system. This report recommends in Section 5.3 that the log sequence number serve as the sequence point, and the reason lies here as well—once the log becomes authoritative, every metric is a query over the log.
9.4 Any Single Metric Will Be Gamed
Any single metric will be optimized into distortion, and this system is no exception.
If only M3 is assessed, the system will tend to pick tasks that are easy to accept and push the hard ones to humans. If only M1 is assessed, the Router will tend to handle only the events with the most regular format and judge all the rest as requiring no action, so as to reduce misrouting and missed dispatch. If only M6 is assessed, the reaper will terminate tasks prematurely, ending tasks that could have been completed. If only M8 is assessed, the system will tend to produce the most conservative proposals.
This report therefore recommends assessing metrics in pairs: pair M3 with M8 to prevent quality being sacrificed for cost; pair M1 with M2 to prevent the Router from degenerating into a forwarder; pair M6 with M5 to prevent premature settlement.
Such pairing is not novel; it is standard practice in performance measurement. The reason for stating it here is what is peculiar to Agent systems: their execution speed is far faster than the speed at which humans can check, so once a metric is gamed, the deviation accumulates to a large magnitude in a very short time.
10. Security and Accountability: Two Issues the Original Article Touches Only in Passing
Section 8.4 of the original article discusses security and privacy in a very short passage, and explicitly acknowledges that "if there is no way to solve the security and privacy problems well, then the Super-agent can only work within a very small and trusted scope". This self-assessment is accurate. This section follows its two threads further.
10.1 The Capability-Model Problem of BYOM
The design in Section 5.2 of the original article is this: the Agent Loop runs in the cloud, the execution environment remains local, and the device side deploys only "a lightweight daemon that keeps no session state and is responsible only for executing commands and returning results".
In practice, the permission of this daemon amounts to "executing arbitrary commands on this machine". The original article is also aware of the risk: "Once the cloud-side Agent Loop is compromised through a server intrusion or prompt injection, all the device-side machines connected to it face the potential risk of being controlled."
To deal with this risk, encryption or authentication is not sufficient; the capability model of the daemon must be changed. Security engineering offers a mature set of principles to draw on: least privilege, complete mediation, fail-safe defaults, and separation of privilege. What the four share is this: do not provide a general-purpose executor; provide a set of capabilities that are explicitly declared, verifiable, and revocable.
Applied to the device-side daemon, this report proposes three constraints.
First, a command whitelist rather than a shell. The daemon does not interpret arbitrary strings; it accepts only pre-declared action types, and each action type has a fixed parameter structure and a fixed output structure. In this way, even if the cloud side is injected, all an attacker can do is choose within the existing action set, not execute arbitrary commands.
Second, scope constraints on paths and targets. At intake, each task declares the path prefixes, repositories, services, and recipients it may touch. The daemon checks this at execution time and refuses and records any out-of-scope action.
Third, short-lived credentials that do not enter the context. The original article already mentions "enabling the Agent to use credentials without coming into contact with the credentials themselves at all", and the direction is correct. What needs to be added is the execution location: credentials should not appear in the model's context, nor in the daemon's general-purpose shell, but only in that single call between the daemon and the target service. The classic discussion of information confinement in security points out that as long as a piece of information can be read into a programmable entity, it has some means of leaking out through an output channel. Therefore "not coming into contact" must be guaranteed by the shape of the interface, not by the prompt.
10.2 Complete Mediation: Where the Security Boundary Should Lie
The event-driven design of the original article allows the Agent to be driven by a wider range of environments, which in itself enlarges the attack surface. The two-level filtering in Section 3.1 of the original article—a program-level policy plus a semantic-level policy—is a sound noise-reduction design, but it is not a security boundary.
The reason is that the semantic-level policy is itself a language model, and its input is untrusted text. Anyone who can send a message to the group can construct a message that passes the semantic filter. Filtering reduces the volume of noise, not the attack success rate.
By the same token, the behavior the original article describes—"continuously watching public group chats and, without anyone @-mentioning it, proactively identifying defects and submitting fix Pull Requests"—is reasonable in an internal trusted group; in an open group, it turns "anyone sending a single sentence" into "triggering a Worker with full tool permissions".
The correct location of the security boundary is before the external action, not at the moment the event enters. This is the commit gate proposed in Section 6 of this report: any action that crosses the sandbox boundary must be checked at the policy gate, and the basis for the check is the action type, target scope, budget, and frequency, not whether the sentence looks like a request.
This design is consistent with the end-to-end argument in security engineering: if the correctness of a function can be judged only from information held at the endpoints, implementing it in an intermediate layer is both redundant and unreliable. The information needed to judge "whether this action should be performed" lies at the policy end, not at the event end, so the check must be placed at the policy end.
10.3 The Accountable Principal
The original article does not discuss accountability. This is not an oversight but a consequence of the scenario: within a team, accountability is resolved naturally by organizational relationships.
Once this system enters enterprise procurement or external service, accountability becomes a precondition. An enterprise cannot procure a system in which "when something goes wrong, no one can be found". This is not only a legal question but also a process question: any external action requires a principal that can be called to account.
This report therefore recommends making the "accountable principal" a first-class constraint of the architecture: every action that crosses the sandbox boundary must be bound in the log to a responsible principal, and this principal may be a natural person or a registered service identity, but not the generic label "Agent".
Complementing this is the immutability of the log. Append-only logs with hash chains are a common practice and are not costly. Its value lies not in the technology but in what it enables after the fact: when it is necessary to determine who performed a given action and on what basis, a log that can be modified is equivalent to no log at all.
11. Conclusion
The conclusions of this report fall into two groups. The first group rests on recomputation of the data made public in the original article and can be independently verified by the reader; the second group consists of design judgments and is open to dispute.
11.1 Conclusions Based on Recomputation
First, the Router's throughput headroom is overestimated. Computed from the batch size and per-request latency in Section 7.2 of the original article, a single Router session at approximately 40 Triggers per minute has a utilization of approximately 0.93, already close to full load. The original article's judgment that it "has still not reached the throughput bottleneck of a single Router" is inconsistent with its own data. Moreover, the batch size of 2.8 is almost equal to the "natural arrival volume during service" of 2.60, which means the measured batching and the queue backlog cannot be distinguished.
Second, the experiment in Section 7.1 does not test its claim. The experiment measures single-task completion time, whereas the claim concerns human throughput; the two do not form a monotonic relationship. The experiment lacks the key control condition of "forced delegation" and therefore cannot separate the architecture effect from the prompt effect. Reporting a p95 from five samples in effect reports the maximum.
Third, the center of cost lies in context reading, not in task execution. Each work request corresponds to about 1.16 million cache-read tokens; if cache reads are priced at one tenth of the input price, the equivalent full-price input is about 116,000 tokens. This figure depends heavily on the load structure in which work requests account for 6.7% of all messages.
11.2 Conclusions Based on Design Judgment
Fourth, the Router carries both routing and global memory at once, and this is the structural source of the long-horizon memory bottleneck. Routing requires a short context and memory requires a long context; coupling the two means that every dispatch must pay for the entire memory. This report recommends taking the sequence number of the append-only log as the sequence point, having sessions hold only the working set, and turning global memory into a materialized view derived from the log.
Fifth, the five modules cover the intake, execution, and acceptance of tasks, but settlement is missing. Long-running operation produces five kinds of residue: zombie tasks, orphaned subscriptions, speculative residue, dangling references, and unsettled commit slots. Settlement requires three elements: a state machine, a deterministic reaper, and a budget treated as a first-class citizen.
Sixth, speculative execution lacks a commit boundary. "Discard it if it has no value" holds only inside the sandbox, and the example given in the original article has already crossed the sandbox. External actions should first enter a staging area and then be committed through the policy gate.
Seventh, the operating-system analogy holds in four places—processes, interrupts, caches, and the watchdog—and fails in two, transactions and process identifiers, and these two correspond precisely to the two weakest areas: the commit boundary for external actions and cross-channel task deduplication.
Eighth, acceptance falls into three classes by nature, and the architecture of the original article covers only the first. Class 1 acceptance is review, Class 2 acceptance is attribution, and Class 3 acceptance can rely only on ex ante constraints. Manufacturing sourcing belongs to Class 2, and what it needs is a settlement layer rather than a review layer.
11.3 Recommendations for Teams Preparing to Adopt This Architecture
If this is to be reduced to one operational recommendation, this report holds that the order should be as follows: first conduct the controlled experiment on forced delegation, and then decide whether to introduce the two-layer architecture.
The reason is straightforward. Forced delegation requires only a few lines of harness code, and what it tests is how much benefit "removing the model's discretion" brings. If it can achieve most of the effect of the two-layer architecture, the team can obtain the main benefit at very low cost; only if it falls clearly behind does it show that the two-layer structure has value in itself, and at that point investing in the Router, subscriptions, chain of recall, and the Watchdog is worthwhile.
The original article has in fact already provided evidence in support of this recommendation: under a neutral prompt the model did not delegate in any of five runs, and under an explicit prompt it delegated in four runs with improved results. This shows that prompt preference substantially changes the delegation rate; whether making delegation mandatory is equally effective still requires that controlled experiment to answer. This point is overshadowed in the original article's narrative by the architecture-level discussion.
The second thing is to fix the log fields first. Most of the eight metrics depend on the same set of fields, and if these fields are added only after the system goes live, the historical data can never be recovered.
The third thing is to add a budget to tasks. This is the minimum threshold for turning the system from an internal tool into a procurable system, and it is the only deterministic means of clearing zombie tasks.
11.4 On This Architecture Note Itself
This report has engaged throughout in recomputation and questioning, and an overall judgment is due here.
The value of this architecture note does not lie in how many new concepts it proposes—it concedes that it proposes no new theory. Its value lies in stating clearly a problem that many teams are vaguely sensing: when the Agent moves from "a single conversation" to "continuous presence", what happens to the form of the system. The five modules it gives are a self-consistent answer to this change, and an answer that can be implemented as written.
Its shortcomings are concentrated in two places. First, the coverage of the evidence is narrower than the coverage of the conclusions: among the five modules, the two-layer architecture is touched only in part, event-driven operation only in the single item of subscription pass-through, while the tone of the narrative is comprehensive. Second, it treats "acceptance" as an action that needs no definition, and therefore does not see the different requirements that different scenarios place on acceptance.
Neither of these shortcomings is a question of capability; both are a question of genre. An internal team architecture note is under no obligation to undergo external validity testing. But when it is disseminated as an industry paradigm, these two shortcomings will be inherited with it. The work of this report is to check, before this note is inherited, whatever can be checked.
12. List of Unresolved Items
The following items could not be closed at the time this report was written and are listed for later verification. This report has not substituted estimated values for these gaps in the body.
- Section 7.2 of the original article does not define the measurement basis for the two metrics "per-request latency" and "inference time allocated per decision". The two are not equal at a batch size of 1 (2.5 seconds versus 6.4 seconds) and cannot be explained by the same service time. The utilization recomputation in this report assumes the former to be the service time; if this assumption does not hold, the figures in Section 3 must be recomputed.
- The original article does not disclose the model types, parameter counts, or context lengths used by the Router and the Worker respectively, so the judgment in Section 3 that "context length is not the current constraint" can only be estimated from the typical context size of mainstream models.
- The original article gives no token pricing; this report uses only token volumes and ratios and does not convert them into monetary amounts.
- The original article states that "a person can typically follow only 3 to 5 active Sessions at once" but does not state the sample, the measurement method, or the population. This report treats it in Section 2.3 as an empirical value of unstated provenance and notes that it may correspond to three different mechanisms (working-memory capacity, interruption-recovery cost, and social coordination capacity), whose architectural implications differ.
- In the experiment reported in the original article, work requests account for 6.7% of the 300 messages, and no real-world basis for this proportion is given. The judgment in Section 4 about the cost structure depends on this proportion.
- This report did not obtain the code in the prototype repository dsh-superagent-prototype; the recommendation in Section 6 concerning the commit gate is a design inference, not a description of an implementation.
- The directions mentioned in Sections 6 and 7—LLMOS, AgentOS, vMem, staged side effects, negative knowledge, and others—were obtained through public searches on 31 October 2026; this report has not checked each source text individually, and the body cites them only as directional references.
- The industry observation cited in Section 8, that "after several hundred consecutive normal reviews, the reviewer degenerates into a rubber stamp", is not supported in this report by any original research that can be checked; the body marks it as a directional indication and does not treat it as evidence.
- Catalini, Hui, and Wu divide work into four classes; this report has not compared their classification item by item with the three classes of acceptance scenarios in this section, and the relation between the two awaits dedicated discussion.
13. References and Method Notes
13.1 Primary Material
- DeepSeek Harness team: "Super-agent Design Exploration: Toward a More Autonomous Agent System", 31 October 2026. All E1 and E2 material in this report comes from this article.
- Contemporaneous media coverage: IT之家, 驱动中国, 观点网, 读懂AI时代, 同花顺, and others, 31 October 2026. Used to judge the distribution of public discussion and not treated as technical evidence.
13.2 Secondary Literature
- Anthropic: "Scaling Managed Agents: Decoupling the brain from the hands", April 2026. Used in Section 5.3 for the discussion of the stateless harness and the external session log.
- Catalini, C., Hui, X., Wu, J.: "Some Simple Economics of AGI", arXiv:2602.20946, February 2026. Used in Section 8.1 for the discussion of verification bandwidth and the measurability gap.
- Kung, H. T., Robinson, J. T.: "On Optimistic Methods for Concurrency Control", 1981. Used in Section 6.3 for the analogy to validation in the commit phase.
- Saltzer, J. H., Schroeder, M. D.: "The Protection of Information in Computer Systems", 1975. Used in Section 10.1 for the four principles of least privilege, complete mediation, fail-safe defaults, and separation of privilege.
- Saltzer, J. H., Reed, D. P., Clark, D. D.: "End-to-End Arguments in System Design", 1984. Used in Section 10.2 for the argument about the placement of checks and the distribution of information.
- Lampson, B. W.: "A Note on the Confinement Problem", 1973. Used in Section 10.1 for the judgment that information confinement must be guaranteed by the interface.
- Denning, P. J.: "The Working Set Model for Program Behavior", 1968. Used in Sections 5 and 6 for the analogy between caches and the working set.
- Cowan, N.: "The Magical Number 4 in Short-Term Memory: A Reconsideration of Mental Storage Capacity", 2001. Used in Section 2.3 for the discussion of the upper bound on tracking capacity.
- Mark, G., Gudith, D., Klocke, U.: "The Cost of Interrupted Work: More Speed and Stress", 2008. Used in Section 6.5 for the order-of-magnitude judgment of interruption-recovery cost.
13.3 Method Notes
All computations in this report can be reproduced from the formulas in the body. The utilization formula in Section 3 is ρ = (λ / b) × S; the service-time elasticity is obtained by fitting a power law to two points, with the fitted expression S = 2.5 × b^0.432; the capacity curve is C = b / S. The unit cost in Section 4 is obtained by dividing 23.23 million tokens by 20 work requests. The spot-check detection probability in Section 8 is computed from the hypergeometric distribution, with the formula 1 − C(N−D, n) / C(N, n), where N is the size of the list, D is the number of nonconforming items, and n is the number of items spot-checked.
This report acknowledges one methodological limitation: the recomputation relies on the three readings made public in the original article, with two sample points, and no robustness check is possible. Section 3 therefore gives an order-of-magnitude judgment, not a precise estimate. If the original article later publishes the complete stress-test series, the conclusions of this report should be revised accordingly.
13.4 On the Position of This Report
This report was written by the Tianxia Gongchang Industrial Research Institute. This institute operates a manufacturing enterprise database and uses an Agent system in sourcing scenarios, so the discussion of Class 2 acceptance in Section 8 incorporates this institute's practical experience. This background may introduce a positional bias, which readers should take into account when reading Section 8. The analysis in the first seven sections does not depend on this institute's business data and uses only the material made public in the original article and publicly available literature, so it can be checked independently.