DeepSeek Open-Sources SuperAgent: Agents Must Learn to Take On Work Continuously

The DeepSeek Harness team recently published a SuperAgent design article and a corresponding GitHub repository, released under the MIT license and explicitly labeled as a research prototype. The problem it aims to solve is not whether a model can write code, but how a person who is constantly interrupted by messages, tickets, and code reviews every day can manage multiple pieces of work that genuinely need to be delivered.

This direction is more noteworthy than "yet another coding assistant." It designs the Agent as a long-running workflow system rather than a one-off conversational tool.

SuperAgent's Core Design: Separation of Scheduling and Execution

The key change in SuperAgent is separating message triggering, work-acceptance decisions, long-lived work items, and actual execution. The Router is responsible for deciding which requests are worth accepting and who they should be dispatched to; the Worker completes tasks in an independent session and directory, then reports the PR or issue back to the original conversation.

This split directly targets a pain point: when an Agent receives messages while writing code, tasks easily interrupt each other. Encoding scheduling responsibilities into the system structure may be more stable than a single prompt.

The official deployment documentation states that Workers execute with operating-system user privileges using a high-privilege execution model, and recommends isolating a dedicated account; this prototype must not be connected directly to a company's production repository. Complexity and security costs increase alongside architectural capability.

Router-Worker architecture is a system design pattern that decouples task distribution from task execution, commonly found in distributed systems and task queue systems. The Router acts as the scheduling layer, receiving external events (such as messages, tickets, CI notifications), and based on rules or policies decides whether to accept a task, what priority it has, and which execution unit it should be assigned to; the Worker is a stateless or lightly stateful execution unit that completes specific work in an independent context (independent session, independent directory) and writes results back to a specified location. The core value of this separation is that scheduling logic can evolve and be tested independently, execution units can scale horizontally, and the failure or blockage of a single task does not pollute the state of other tasks. In the Agent context, this architecture separates "whether it should be done" from "how to do it," giving long-running workflows a structural foundation that is traceable, recoverable, and auditable, rather than relying on the implicit memory of a single conversational context.

What the Benchmark Data Shows and Doesn't Show

In simulated group chats and GitHub CI message streams, each group had about 300 messages, of which about 20 were actual work requests, and each approach was run 5 times. SuperAgent's median task completion time was 12.4 minutes, with a 95th percentile of 15.7 minutes; under the neutral prompt, the 95th percentile for a single Session plus SubAgent was 29.5 minutes.

However, the coding work used a time-consuming substitute tool, so what is being measured here is scheduling, concurrency, and interruption management, not the speed, quality, or success rate of the model actually completing code. Moreover, the control Agent under the neutral prompt never proactively delegated subtasks in any of the 5 runs — this is not a rigorous head-to-head product competition. The value of these numbers lies in demonstrating the impact of system structure on scheduling stability, not in ranking model capability.

I prefer to view this release as a signal about Agent engineering architecture rather than as DeepSeek^Ad launching another new product that can replace programmers. There are two reasons: when a model can work continuously for tens of minutes, the human management cost shifts from writing prompts step by step to confirming permissions, dispatching tasks, and closing out acceptance; only by extracting a task's persistence state from the chat window can responsibility continue to be tracked across new messages, network fluctuations, and machine switches.

In the future, we should look at PR merge rates in real projects, rework rates, the number of manual interventions, and the recovery success rate after errors. If the coordination overhead introduced by multiple Agents outweighs the benefits, expectations for this kind of long-running architecture will need to be lowered.

Median and 95th percentile are two key statistics for describing latency distributions. The median (P50) indicates the time within which half of tasks are completed, reflecting the typical experience; the 95th percentile (P95) indicates the time within which 95% of tasks are completed, reflecting long-tail latency, i.e., the performance of the slowest subset of tasks. In scheduling system evaluations, P95 is often more meaningful than the mean, because the "lag" and "loss of control" perceived by users usually come from the long tail rather than the average level. In the SuperAgent report, P50 is 12.4 minutes and P95 is 15.7 minutes, while the control approach's P95 is 29.5 minutes, indicating that its advantage is mainly reflected in long-tail stability — that is, reducing situations where tasks remain suspended for a long time after being repeatedly interrupted. Note, however, that these numbers measure scheduling and concurrency management capability, not the quality of model-generated code; and the sample size (about 300 messages per group, 5 repetitions) is small, so statistical significance is limited, and they should not be extrapolated into product-level performance conclusions.

OpenAI's Lowered Fundraising Target: A Business Signal, Not a Verdict of a Bubble

The Financial Times reported on October 30 that OpenAI's latest funding round target had been lowered from the previously reported $30 billion to $20 billion, and TechCrunch followed up on October 31. The Wall Street Journal also reported that about $11 billion in funding commitments had currently been obtained, with investor response relatively lukewarm, and the media-reported valuation adjusted from the previously cited $1.4 trillion to $1.25 trillion.

Here it is necessary to distinguish between target, valuation, commitment amount, first close amount, and final cash received — they are completely different concepts. There is currently no official closing announcement from the company, nor can the investor sentiment described by the media be treated as a confirmed fundraising failure.

The more credible mechanism is this: AI companies need to continuously invest extremely high capital expenditure in compute and data centers, and whether future revenue can cover depreciation, energy, operations and maintenance, and debt costs is prompting investors to demand a clearer path. The most practical takeaway for developers is not to predict stock prices, but to avoid business models that rely entirely on infinitely cheap tokens in the future; for infrastructure companies, it is necessary to more carefully distinguish long-term contracts, prepaid cash, and irrevocable compute obligations.

Fundraising target, valuation, and commitment amount are three concepts that are easily confused. The fundraising target is the upper limit or expected amount the company plans to raise in the current round; valuation is the pricing of the company's overall value before or after investment, usually expressed as "pre-money valuation" or "post-money valuation"; the commitment amount is the amount investors have indicated in writing or orally that they are willing to contribute, but it does not mean the funds have been received; the first close amount is the cash actually received at the first formal legal closing. The media often conflate "lowered target" with "lowered valuation," but the mechanisms differ: a lowered target may reflect fundraising pace or changes in investor demand, while a valuation adjustment involves a consensus on pricing. In the absence of an official company closing announcement, these figures should be treated as media estimates based on sourced reporting, not confirmed financial facts. For infrastructure buyers, what matters more is whether the compute obligations in the contract are revocable, the prepayment ratio, and liability for delivery breaches, rather than the fundraising amount itself.

Meta and Fourier's Humanoid Robot: Supply Chain Validation, Not a Home Product

The Information reported on October 31, citing people familiar with the matter, that Meta and China's Fourier Intelligence had built a humanoid robot with the internal codename Max in about three months, weighing about 106 pounds (48 kilograms). The report was first made public on October 31, which does not mean the robot was just built that day — the media said it was shown to some Meta employees in August and that second-generation design had already begun in September.

The report says the two sides discussed home interaction, voice, and gesture perception, but there is currently no public mass-production timeline, independent testing, or home task completion rate. Reuters, when relaying the report, also explicitly stated that it could not independently verify it.

This news has more industry value than simply showing a robot walking: it reveals how big companies may shorten the distance from models to physical devices, delegating perception, interaction, and full-machine mechanical capabilities to different specialized teams for collaboration. The strongest counterinterpretation is that what was built in three months was most likely mainly a custom shell and interaction integration for an existing hardware platform, and did not cross the threshold of generalized manipulation and home reliability.

For robotics startups, rather than first pursuing more anthropomorphic expressions, it is better to prioritize providing the success rate and manual takeover rate for tasks lasting many consecutive hours, and then calculate hardware BOM and after-sales service costs.

The Controversy Over Training on Security Drawing Data: A Single Front-End Switch Is Far From Enough

The Decoder reported on October 31 that an email sent to members of the Daybreak Blue cybersecurity project Trusted Access stated that starting November 29, these specific security drawing data would be used for model training, even if users turned off the ordinary "improve the model for everyone" switch. The subsequent backlash prompted OpenAI to send a follow-up email saying it would provide a separate opt-out mechanism, although interactions flagged by security review may still have security uses.

This is not an announcement that "all ChatGPT chats will be retrained." The key facts come from membership emails shown and quoted by the media, and there is a lack of a formal, complete new version of the terms for everyone, so the applicable population and policy status must be clearly stated.

Supporters would say that using cybersecurity drawing for training helps improve defensive capabilities, and that exceptions for security review may also be justified; opponents would say that security research is most likely to contain undisclosed vulnerabilities, source code, customer environments, and credentials, and if a general switch cannot accurately tell users where data actually goes, researchers cannot make credible confidentiality commitments.

When enterprises choose models, they cannot treat a front-end privacy button as the entire contract; they need to look at data categories, purposes, retention time, and exception channels. For sensitive vulnerabilities or customer data, prioritize isolated environments with explicit written agreements, and verify default settings on test accounts.

The Hidden Costs of Compute Infrastructure: Litigation, Permits, and Compliance

TechCrunch reported on October 31 that a U.S. federal judge rejected xAI's motion to dismiss an NAACP-related air pollution lawsuit. The plaintiffs allege that the Colossus data center near Memphis used at least 35 gas turbines without obtaining the required permits. xAI had argued that these devices were exempt mobile facilities and also questioned the plaintiffs' standing to sue. The court's position is that the case can continue; it did not determine at this stage that xAI has already broken the law, and the extent of pollution and ultimate liability still need to be tried.

In the past, analyses of compute often compared only chip prices, PUE, and electricity prices, but actually building a site also requires air emission permits, water use, grid capacity, local residents' trust, and time subject to judicial review. The court currently only allows the case to continue, which does not mean the plaintiffs have proven pollution damage, so a general industry-wide judgment of illegality should not be made based on a single case.

An actionable recommendation for buyers is to add due diligence clauses on energy sources, permit status, force majeure shutdowns, alternatives, and delivery deadlines in large long-term compute contracts.

Text Watermarking: Useful Supplementary Evidence, Not an Absolute Judge

xAI's latest official documentation states that starting November 7, text output via API from 7 Grok models will by default include an invisible watermark, and administrators can opt out per model when applicable legal exceptions apply. It leaves statistical features through word choice during generation, rather than inserting hidden characters into the text.

That said, The Decoder reported on October 31, based on an email from Anthropic to API customers, that 4 earlier Claude models will have watermarks added, but for Opus 4.6 and Sonnet 4.6 among them, if developers adjust sampling parameters such as Temperature, Top P, and Top K, the watermark may not be applied. Anthropic's current help page still lists several older models as not yet supported, so the plan should not be written as already fully launched.

Text watermarks are useful, but they should not be treated by education and enterprise risk control systems as an absolute judge. Because the essence is a statistical mark on the token distribution, the signal is insufficient when the text is too short, and it may also fail after manual rewriting or rewriting by another model. xAI even provides a reverse lookup function to indicate whether a given request carried a watermark, but this is information obtained at the time of the API call and cannot replace content provenance auditing years later.

A more practical approach is to retain request sources, versions, and trusted logs, and then use watermarks as supplementary evidence. Only if independent large-scale multilingual false-positive rate research emerges in the future proving that short texts can also be reliably detected should their evidentiary weight be increased.

Text watermarking is a technique that embeds a statistical signal by adjusting the probability distribution of the vocabulary when a model generates text. A typical approach is to divide the vocabulary into a "green list" and a "red list" using a secret key during each token sampling, and slightly increase the sampling probability of green-list words; during detection, the proportion of green-list words in the text is counted, and if it is significantly higher than the random baseline, it is inferred that the text may have been generated by that model. This kind of watermark does not insert visible or hidden characters, so it does not affect readability, but it depends on the sampling process during generation. The key limitations are: adjusting sampling parameters such as Temperature, Top P, and Top K changes the distribution and may weaken or destroy the watermark signal; when the text is too short, there are insufficient statistical samples and detection reliability decreases; after manual rewriting or paraphrasing by another model, the watermark signal is usually diluted. Therefore, watermarks are suitable as auxiliary evidence for provenance tracing, but not as the sole basis for judgment, especially in high-risk scenarios such as educational grading or enterprise risk control.

A High-Frequency Product Scenario: Translation on AI Glasses

IT Home reported that Quark AI glasses added call translation and media translation via OTA, providing real-time translation during phone calls, online meetings, podcasts, online classes, and videos, with synchronized text display and optimized recognition in noisy environments. Compared with merely taking photos to identify objects, this is closer to a high-frequency scenario that users are willing to use repeatedly.

However, there are currently no independent device tests, so the advertised real-time accuracy and accessibility cannot be understood as already-verified experience. Whether AI glasses can retain users depends first on end-to-end latency, usability under noise, wearing burden, and whether tasks can be completed without looking at a phone. If translation still requires frequently taking out the phone to correct, it will be difficult to build a moat with new features.

Putting today's news together, there are two judgments worth keeping. First, as model capabilities gradually become sufficient, the next round of Agent product differentiation is more likely to be reflected in whether they can take on work over the long term and whether errors can be held accountable and recovered from. DeepSeek's new prototype demonstrates a feasible system structure, but it is still far from proving production reliability. Second, from reports of OpenAI's lowered fundraising target and the xAI data center case to security drawing training data and text watermarks, AI is exposing costs that were previously easily covered up by marketing rhetoric: funding, data, permits, energy, compliance, and user trust. For developers, what may be more worth doing today is to chase one fewer benchmark and design one more reliable task state machine; for buyers, write a few more acceptance conditions rather than merely comparing token unit prices.