DeepSeek’s Super-agent takes over the work of coordinating AI workers

DeepSeek’s Super-agent addresses a problem that appears once several coding agents are already useful. Someone still has to open their sessions, relay a reviewer’s correction, remember which agent owns a failing test and stop the one pursuing an obsolete fix. The DeepSeek Harness team proposes giving that work to a persistent coordination layer that receives events and dispatches separate workers. Its public repository demonstrates a narrower version for one GitHub repository, with optional Feishu integration. The wider proposal describes how such a system could keep working across conversations, machines and interruptions.

The work between the windows

Picture a developer fixing a checkout bug when a teammate reports a broken import in chat and GitHub delivers a review comment on yesterday’s pull request. The three requests have different histories and different acceptance criteria. The review comment could be handled by the worker that wrote the patch. The import report might require a fresh worker, assuming the team has authorised that kind of request. The checkout investigation already has an owner and should continue. Parallel model calls solve only one part of this problem. The coordination layer must know which messages concern the same work, which people can ask for changes and where the result belongs.

IT之家 reported on October 31, 2026 that the Harness team had published the design. In the essay, the team says its internal instance was already used to reproduce and fix problems, respond to code reviews and work on Harness itself. Those are examples reported by the team that built the system. The repository says DeepSeek adapted the implementation for release and that several ideas in the essay describe future directions. The examples help explain what motivated the design. The public code provides a separate basis for judging what an outside operator can actually configure.

The question matters because handing off a task changes its owner without changing the underlying facts. A reviewer can invalidate an assumption while a test is running. A teammate can supply an example that turns a vague request into a reproducible bug. An issue can close because someone fixed it elsewhere. If the only authoritative record is the original prompt, the worker keeps acting on an increasingly stale brief. The work item needs a relationship to the places where the team makes decisions. A system that records those relationships can deliver updates without expecting someone to copy them into a second conversation.

In its November 2, 2026 report, 36Kr framed the launch around developers becoming managers of multiple sessions. The Chinese text attributed to DeepSeek’s Harness team, available in republication, likewise describes human attention as the bottleneck and cites an internal observation about the limited number of active sessions one person can follow. That observation describes the team’s experience. It is a poor candidate for a universal limit because the effort of following a session depends on the task, the consequences of a mistake and how often another person must decide something. One fragile release can demand more supervision than several routine patches.

The design becomes easier to evaluate if coordination has a concrete definition. Intake means collecting relevant events. Admission means deciding which events can become requests. Routing means linking a request or follow-up to a task. Execution means doing the authorised work. Acceptance means checking that the work meets a standard the team recognises. A product may put several of those jobs in one interface, but the distinctions matter when an agent acts incorrectly. A misplaced message, an invalid grant and a bad patch are different failures, even if all three arrive in a chat as the same bland error.

The name Super-agent encourages a mental picture of an unusually powerful model giving orders to smaller ones. The code points to a more ordinary and more testable idea. DeepSeek Harness supplies model integration, session management and tools. The bundle adds durable work records, event intake and coordination. The prototype can use the Harness profile’s default model or a separately configured model for evaluation or execution. A team can change the model without changing the meaning of a work item. Its identity, originating event and authority belong to the application.

There is a contrast between a session and a task even for one person. A session might contain an initial attempt, a long digression into a build error and a final successful run. The task is the result someone needed and the scope within which it was acceptable to get there. If a machine restarts, a replacement worker may need a short account of the first attempt, the patch and a pointer to the failing test. It needs a reliable way to find all three. Continuity comes from preserving enough of the work to resume it, even when the old transcript is an awkward tool for finding the relevant facts.

An illustration from agency work makes the distinction less abstract. Suppose a team asks for a fix to a sitemap generator and later adds that certain translated URLs must stay out of the feed. An agent can work through the repository on the first request. The second message may alter the acceptance criteria substantially, and a reviewer should see that change in the eventual pull request. If a different team simultaneously asks about a web server timeout, the two conversations may mention the same domain or repository. A shared proper name is weak evidence that two requests are one task. A link to an existing issue or an explicit reply carries a different kind of information.

This explains why the proposal is relevant even when a team has enough compute to run every worker immediately. The hard part may be the decisions that use scarce people. A developer can delegate several investigations and still be the only person able to say whether a breaking change is acceptable. Scheduling can free some of that developer’s time, but it can also deliver a pile of simultaneous questions. The unit to optimise is the complete path to a useful decision, including the interruptions imposed on the team. A system that launches work quickly and asks people to reconstruct its reasoning at review time has deferred part of the work.

DeepSeek’s release offers unusually useful boundaries for this discussion. There is a published design essay, an account of the team’s internal use and an inspectable research prototype. Those are three kinds of evidence. A proposal can explain why a component would be useful. Internal use can show why the team kept working on it. Code and documentation can establish how the released version is supposed to behave under specific settings. A claim about one layer needs evidence from that layer. This distinction is particularly important when the topic shifts from chat routing to remote execution or automatic recovery.

The premise is stronger than the familiar claim that more agents yield more output. It identifies a job that already exists and gives it a place in the architecture. In a manual setup, people act as the routing table. They translate a comment into a task identifier, forward it to the right window and notice when two workers are using conflicting assumptions. The proposal gives each handoff a durable address. Its consequences are easiest to see by following the smallest possible unit of work from a message to a reviewable change.

One request through the public prototype

The public repository describes a coding agent for one GitHub repository. An operator can add Feishu as a second channel. The agent uses a dedicated GitHub identity, and accepted work gets a separate session and working directory. The prototype gives the work item a life outside the chat. Its documentation calls the item a Ticket. To follow the machinery, imagine an authorised maintainer asks the agent in a GitHub issue to reproduce a bug in a file importer. The example is illustrative. The path follows the repository’s documented domain model and authorisation rules.

The source adapter gives the incoming message an identity and places it on a thread. In ordinary language, a thread is the conversation an event belongs to. In code, it is also an object whose identity can survive an application restart. The message has an author, an address and surrounding evidence. The adapter supplies facts that the model should never have to infer from prose. A comment quoting an administrator and a comment authored by that administrator could look almost identical after copying their text into a prompt. Their structured metadata allows the application to treat them differently.

An intake decision can see whether the account is allowed and whether the request addresses the agent. The host enforces the admission rules. A model may then assess the request and help decide what action fits. In the domain documentation, the evaluation is called an Eval. If the request is accepted, a Ticket records the work and a Mandate records the basis on which it was allowed. The mandate captures authority as it existed at acceptance, including the relevant policy version, scope and source identity. That gives a maintainer something more specific to inspect than an explanation generated after the fact.

The application binds the Ticket to an Executor through an Assignment. That distinction becomes important as soon as an execution attempt fails. A bug investigation can be legitimate and remain open after a model request times out. A worker may finish its turn while the team still needs to supply evidence. An assignment records who is executing now or did so previously. The Ticket represents the work across those attempts. A durable system can show that the importer task remains open even if its worker is waiting for a retry.

The work directory provides a place for the agent to check out code, reproduce the failure and prepare a patch. Git’s worktree documentation explains why distinct checkouts can be useful even when they are linked to the same underlying repository. A worker’s branch can carry unfinished changes without requiring another worker to switch branches in the same checkout. An independent checkout solves a collaboration problem at the file level. It leaves open the question of what the worker can read elsewhere on the host, which belongs to the security analysis of the deployment.

A colleague now adds a sample that reproduces the bug. Once the ticket subscribes to the issue thread, the application can deliver the comment as context to its executor. A known follow-up can bypass a fresh routing judgement. Suppose the next comment instead asks the agent to change how every client uploads files. The issue thread gives the worker a reason to read it, but the broader request may exceed the mandate. The authorisation document describes how the worker can hand back a message that belongs elsewhere or exceeds the Ticket’s scope. That hand-back restores the opportunity to evaluate the request under the policy for new work.

The prototype supports more than one subscription for a ticket. A worker may need to follow the pull request it opened and keep receiving messages on the original issue. It can also follow related work as context. Those relationships have different consequences. A context-only subscription gives the worker evidence without extending its authority. In the importer example, a related pull request may contain the correct file format, but a comment there does not automatically gain the power to restart an ended importer task. Recording the type of relationship prevents a useful research link from turning into an unintended command channel.

A worker’s report can lead to a message in the conversation where the request arrived. The work itself may be a pull request, which gives people an independently inspectable artefact. A report is easier to trust when it says what was reproduced, identifies the relevant validation and makes any remaining uncertainty visible. Opening a pull request transfers a decision to a reviewer. Whether the bot can merge depends on actual GitHub permissions and configuration, alongside the prototype’s settings and prompts. The presence of a pull request is evidence of delivery. The eventual acceptance criteria are separate.

The panel connects those steps. The documented interface exposes source health, triggers, evaluations, the state of execution and settings history. A maintainer investigating why the import job ran can trace it to the originating message and the policy under which it was accepted. A colleague asking why a follow-up was not acted on can see whether it stayed with an existing ticket or went back to evaluation. The panel turns routing into something an operator can inspect without opening each worker’s transcript. That is the practical payoff of giving the coordinator its own records.

The same structure supports a stop request, but stopping has several meanings in a live system. A human may want the worker to cease future actions, preserve a useful branch and leave the issue open. An external command may already have returned a result or changed remote state. The operator needs to see where in the sequence the stop arrived. Cancellation has to be interpreted against work that may already exist. A good status explains the state of the branch and the result, giving a human a concrete decision about any cleanup. The public documentation gives stop, end and resume distinct roles in the lifecycle.

The importer example illustrates the architectural shift in a way the number of workers cannot. In a manual setup, the developer has to recognise the issue comment, locate the correct worker, pass it the sample and preserve the result somewhere visible to reviewers. Here, stable identifiers and explicit relationships do much of that. The worker still has to understand the failure and produce a good patch. The system reduces the coordination work surrounding the patch while leaving the patch itself open to ordinary review. That division of responsibilities runs through the larger design.

A router with a narrower job

The proposed router sits where competing demands arrive. Its job includes judging what belongs to an existing task, initiating work when the rules permit and returning information to the people who need it. The workers have the tools and context to act on their assigned tasks. The design essay makes the separation a property of the system. In its discussion of tool access, DeepSeek uses the absence of a shell tool as an example of how the router could be kept out of routine execution. The public prototype’s tool configuration should be read on its own terms. Offloop’s comparison and DeepSeek’s architecture and prompt documents distinguish the restrictions actually present in the release from the stronger separation illustrated in the essay.

A single session with a subagent tool offers a useful baseline. It can receive a request, delegate independent branches and combine their findings. Anthropic’s Building effective agents describes orchestration patterns in which a central model breaks down work when the branches cannot all be defined in advance. A task that begins with one prompt and ends with one answer fits this pattern well. A persistent intake service has a different calendar. It receives unrelated requests while yesterday’s work is still active, and it must maintain working relationships that outlive a single delegation tree.

The difference appears when the coordinator can decide to execute something itself. A small fix may look like a harmless exception. Starting a command or reading several files, however, occupies the same model session that is expected to handle new events. If another work request arrives, a session must either finish its current step or interrupt it under whatever turn semantics the harness provides. The short path for one request can become a long wait for the next. A fixed boundary between intake and ordinary execution trades some freedom for a more predictable route when several tasks arrive close together.

There is a legitimate reason for a router to perform small operations. It may need to inspect the identity of an incoming thread or verify whether the linked item exists. If every lookup becomes a dispatched assignment, scheduling overhead can dwarf the underlying work. An architectural boundary has to distinguish the tools that clarify a routing decision from those that pursue the substantive goal. A read that answers which task owns a review is part of coordination. Editing the code under review is a different act. That distinction is easier to maintain when tools have narrow inputs and named outcomes.

DeepSeek’s prototype architecture puts an Engine between the ports that translate external input and the records that hold it. The Engine has access to policy, an assessor, an executor and an outbound channel. The documented design has the Engine own state transitions, while adapters perform effects after a transaction commits. The model’s suggestion passes through application code on its way to becoming work. That matters because a model-generated tool call may arrive twice, come after the relevant window has expired or cite a scope that the policy does not permit. Recording the decision and executing it are separate engineering problems.

The router also needs enough global information to identify collisions. In the checkout and importer examples, two agents might discover that they both depend on the same library upgrade. Coordination then has a concrete purpose. It can make the dependency visible, ask a maintainer to settle the order or hand one piece of work back. Shared visibility is weaker than shared control. Giving a router the ability to see two tickets does not make concurrent edits compatible. A developer can still need to rebase, run both changes together or choose one implementation.

The essay presents one long-lived router session as a way to preserve conversational continuity and considers hierarchical filtering or sharding if load warrants it. The trade is easy to see in a company that assigns a separate router to every repository. Repository partitioning keeps much of the work local and offers a clear way to distribute demand. A chat report that spans a client package and a service can now land in the wrong partition or reach both. Sharding changes the meaning of a global question. The design has to say which partition owns the work and how it obtains context from its neighbours.

A tenant boundary leads to a different choice. An agency should be able to explain why a message from one client could never be used as evidence in another client’s task. Partitioning by client reduces opportunities for cross-client context to enter the same model window, though it also makes it harder to recognise a common upstream defect. A shared coordination service may still record an explicitly approved dependency between tickets while keeping credentials and private evidence separate. The best partition for traffic may differ from the right partition for confidentiality. That is an architectural decision made before increasing the number of workers.

The model assigned to coordination need not be chosen in the same way as the model assigned to implementation. The router must interpret conversational references, recognise changes of scope and produce well-formed decisions. A worker may spend most of its time reading code, using a debugger or designing tests. DeepSeek’s deployment guide permits role-specific model selection. Separate roles make it possible to test each model against the errors that matter in its job. A cheap routing call that regularly sends comments to the wrong worker can be more expensive than a slower one that prevents rework. The reverse is possible when an expensive model is repeatedly asked to classify routine CI messages that code could handle.

A useful router has stable behaviour when it is uncertain. Consider a chat message that says “please finish that” after a discussion touched three separate tasks. The safest interpretation may be to attach nothing, or to ask for a single identifier. The value of a request for clarification depends on the cost of getting the answer wrong. Ambiguous references are ordinary conversation, especially in teams that work together every day. A system can accept ambiguity gracefully only if its state model allows a candidate to wait and its communication layer knows whom to ask.

Coordination therefore has its own performance requirements. A fast intake decision should preserve the option to explain later why the request started, and a cautious one should avoid leaving a time-sensitive task indefinitely unassigned. The code and design separate those concerns from a worker’s ability to fix the issue. A useful dispatcher keeps the next task moving while workers stay with the tasks they already own. Its design starts with the stream of evidence arriving before any worker is launched.

Admission begins with the source

A team’s event stream includes messages that ask for work, messages that change work already under way and messages that merely show what happened. GitHub might announce a failed build after a commit. A reviewer might ask for a new test. A chat participant might paste part of a stack trace to explain a problem to another person. The fact that a system receives a message says little about what it may do with it. DeepSeek’s design approaches that problem with programmatic filtering followed by model assessment when semantic judgement is needed.

The first filter can use fields the source adapter already knows. These include where the event arrived, which account sent it and whether it was directed at the bot. The repository documents an admission table that distinguishes the receiving scope, whether the sender is on the allow list and whether the message addresses the agent. GitHub issues, pull requests, comments and default-branch CI have different source settings. Feishu can distinguish configured chats, direct messages and other configured mention behaviour. An explicit mention is a signal evaluated under the source’s policy. The same words from a different source or account can enter a different path.

Programmatic filtering is useful because a great deal of traffic can be decided without making a model call. A repository’s routine notification that a bot updated a dependency may be irrelevant to the work intake policy. A duplicate delivery can be recognised from the event identity. A message outside the sources the team has selected can be ignored at the boundary. Fast filtering works best when its input is authenticated metadata. It becomes brittle if every quiet message has to be distinguished from an urgent one by a list of keywords.

Model assessment enters where the facts need interpretation. A permitted message may describe a defect that another worker already owns. A complaint about slow uploads could be a reproducible regression, a reminder of known capacity limits or an anecdote with too little information to act on. The model can compare the description with recent context and assess it against written rules. The model judges whether the candidate fits a policy the team supplied. The host still has to enforce the conditions under which its decision can create a ticket.

The public prototype’s documented approach to inferred work is useful for evaluating the design. In observation mode, the team can inspect the work an inferred candidate would have started while keeping that inferred work from executing automatically. Explicit requests follow their own policy path. Observation mode gives operators a set of real examples to review before automatic inferred work begins. A team can see whether a rule picks up issues that people would want fixed or repeatedly treats snippets of ordinary conversation as assignments. This form of trial asks staff to check decisions before asking them to review unsolicited patches.

The benefit of observation is easy to overstate if the review sample is selected from interesting cases. The obvious bug report that the agent noticed may be rare. A useful sample also includes vague reports, jokes that resemble requests, a correction to an existing issue and messages that mention the project in a different sense. False positives spend attention even before they spend compute. Someone must classify the resulting candidates and adjust the rule. If the long-term expense of checking candidate quality exceeds the manual cost of filing good issues, a more passive configuration may fit the team better.

False negatives have their own cost. A failure alert may arrive from a CI identity the system does not regard as eligible. The resulting silence might look like good filtering even though a human was expecting a first pass at diagnosis. The operational distinction is whether an alert was outside the intake policy, entered observation, was rejected as irrelevant or was never received. A quiet inbox means different things at different points in the pipeline. Source health and decision records make it possible to investigate without treating each miss as a model problem.

The same reasoning applies to bot messages. A tool may recognise a CI identity but should still know whether its message can start work, update an existing ticket or simply supply context. A dependency bot and a deployment monitor both speak as machines, yet their reports have different relationships to urgency and authority. DeepSeek’s authorisation guide describes a separate bot list and distinguishes inferred candidates from explicit requests. A machine-produced message should retain its provenance when it reaches the worker. A human’s comment quoting that message is another event, even if the text is identical.

A team’s admission policy is also part of the interface people learn. If the agent sometimes starts on a mention and sometimes on an unaddressed comment, colleagues need a way to predict the effect of their words. The obvious way to ask for work should behave consistently in a given channel. Inferred work can be allowed under narrow rules whose decisions are visible. Predictability reduces the need to write defensive messages around the bot. People should be free to discuss a bug without guessing whether the conversation itself has started an implementation.

Extending the system to another event source involves this same work. The prototype’s cookbook asks authors to map stable event identities, thread identities, actors, reply addresses and receiving scopes before implementing a source. A connector for a ticketing system with organisations and private comments would need to translate those distinctions faithfully. A connector carries identity and authority information as well as text. Mapping every event into the same undifferentiated message shape throws away the facts needed to decide who can ask for action.

The practical lesson of the two stages is that policy written in code and judgement expressed in language serve different roles. Code can check whether a sender and source qualify under established rules. A model can interpret whether the message concerns a known job or appears to meet a written condition for new work. The handoff between those stages is where an inference becomes accountable. It should leave behind the event, the policy and the decision that created the ticket, allowing later reviewers to follow the chain back to its beginning.

Threads carry the updates

Once a ticket exists, most of its useful information arrives in places people already use. In a GitHub issue, a maintainer adds a failing input. On a pull request, a reviewer questions a compatibility assumption. A CI service posts a status for a revision. The design essay calls these events Triggers and groups related ones into Threads. A subscription records which active work should receive later events on a thread. The worker does not need a central agent to read each follow-up and make the same routing decision again.

The prototype adds an important qualification. Its domain model puts subscriptions on threads and associates them with tickets, whose executor assignments can change. That means the conversation’s relationship to the job can outlast the specific worker that took the first turn. A ticket is a more stable destination than a running session. If a new executor resumes the work, the system still has a record of which conversation the team uses to discuss it. A request to look at an old comment can be recovered by following the same stored relationship.

Imagine a worker building a reproduction for a race in a job queue. While it runs the test, someone responds in the issue with a warning that the bug occurs only after a reconnect. If the router repeatedly has to analyse the whole stream, that message competes with every unrelated issue waiting for evaluation. A known subscription can instead hand it to the worker on the queue bug. Direct delivery removes a fresh semantic judgement from a known route. The worker still needs to decide how the new evidence affects its test. Routing and interpretation remain different jobs.

The many-to-many design allows a task to follow several conversations and several tasks to follow one conversation. A feature branch might depend on a separate migration proposal. A worker for the feature needs the migration timeline, while the migration worker needs the review thread in which users discuss compatibility. Sharing a thread can coordinate independent work without creating a private chat between workers. It can also deliver more updates than either worker can use. A team should be able to distinguish a subscription that carries work instructions from a subscription that supplies background evidence.

Context-only subscriptions preserve that distinction in DeepSeek’s authorisation design. If a worker follows a related issue, messages from it reach the active task as information. They do not gain the authority to extend its mandate or resume an ended ticket merely because the worker chose to follow them. A model’s choice to read a discussion cannot delegate the right to issue commands. This is particularly important when the related thread is public or contains participants who have no authority over the task. Reading useful evidence is a different permission from accepting a request.

Even an ordinary subscription creates a hard case. A single GitHub issue can host a valid correction and a new proposal unrelated to the original scope. Delivering the message to a worker with context is sensible. Treating that delivery as automatic approval for every sentence would let anyone who could reply change the work. The documented hand-back mechanism gives the worker a route for a follow-up outside scope, and the main session can reassess it under the relevant rules. Direct routing saves judgement at intake while preserving a later check on scope. The remaining weakness is that the worker must recognise the boundary when the difference is expressed in ordinary language.

That boundary is easier to inspect when a ticket carries a specific mandate. “Fix import parsing for quoted fields” supplies a narrower anchor than “improve import reliability.” If a later comment asks for network retries, an agent can compare that request with the original scope and find the mismatch. In practice the scope text needs enough detail for a reviewer to distinguish a permissible implementation choice from an unauthorised expansion. The quality of the recorded scope determines whether a hand-back can be explained. A vague mandate makes every later decision look defensible after the fact.

Messages also have an order problem. People react to earlier comments while the conversation continues. A CI status can refer to a commit that has already been replaced. A newer note can say to ignore the reproduction sample posted just before it. Chronological order and causal order can differ. A reliable system preserves both the timestamp and the reference that tells a worker what a message concerns. In a review, a commit identifier or line reference can matter more than recency because it tells the agent whether the comment applies to the current code.

The prototype’s records distinguish a thread from the correlation between threads. The same trigger can add evidence about related conversations without turning their relationship into a routing rule. That is a modest distinction with practical consequences. Suppose the same failure message is quoted in a customer escalation and an internal release checklist. The two threads are related, but an instruction in the escalation should not necessarily reach every worker on the release checklist. Correlation gives the model a trail to investigate without automatically assigning new listeners. It makes context discoverable without treating it as a command.

The event route also has to handle a worker that finishes while a follow-up is in flight. The authorisation document describes releasing messages that remain unacknowledged or unhandled when a ticket ends so they can return for evaluation when appropriate. An end state should not silently bury a request that arrived late. The panel can help an operator distinguish a message still owned by a ticket from one eligible for fresh evaluation. The architecture makes that distinction a recorded state rather than a question about whether an agent happened to read the last message before ending its turn.

From a team’s perspective the benefit is continuity. A developer can leave a review comment on the pull request, where the rest of the team can read it, and expect the work to continue in the relevant place. The coordinator does not need a private copy of every conversation to maintain that relationship. A subscription gives the system a reason to deliver evidence, and the mandate gives the worker a limit on acting on it. The combination matters more than either one by itself.

A mandate survives the conversation

The prototype’s Mandate is the most interesting record in its domain model because it puts a name on something that many agent demonstrations leave implicit. A person asks an agent for help and then watches what it does. In a shared system, the original person may be away by the time a second colleague asks for a change. The system needs to retain the basis on which the work was accepted. The documented mandate includes the decision’s scope, the policy version, the source identity and the relevant rules for inferred work. The conversation remains evidence, but the permission has a separate record.

A mandate is most useful when it sets an intelligible boundary. Consider a request to reproduce an intermittent failure in a repository’s test suite. Reading the tests and running them in the assigned environment follow naturally from the request. Changing the deployed service, contacting a customer or pushing a fix for an unrelated failure goes beyond it. The purpose of an investigation constrains which side effects make sense. Tool access may be broader for operational reasons, which makes the distinction between allowed purpose and available capability central to the security review.

The source of authority matters because people participate in several capacities. A maintainer may be authorised to request changes in a repository and still have no authority to share client data in a chat where the agent can retrieve it. A member of a chat may know how to reproduce the failure without being allowed to change its priority. DeepSeek’s domain document treats source identities separately. Matching display names across applications is inadequate proof of delegated authority. Cross-platform identity knowledge may help the model understand who said what, while source-specific admission continues to depend on the host’s records.

The team’s policy can change while work is active. A new rule may exclude the type of task that an earlier rule admitted. A member can leave a project. A channel can move from open requests to a tighter allow list. The domain document describes versioning and revalidating the basis for resumption. A policy revision and a direct stop have different operational meanings. A direct stop targets a particular piece of work. A policy change can affect many current and future decisions, and the handling of already running work must be understood from the implementation and the operator’s controls.

There are situations where continuing is appropriate. A maintainer might temporarily turn off inferred admission because a high-volume chat is producing too many candidates. An existing explicit request still reflects an identifiable decision and may be safe to finish. In a different case, an identity was compromised and the tickets it originated need immediate human review. The reason for changing a policy affects how operators should treat accepted work. Merely publishing a new list cannot tell a system whether a prior approval was legitimate. Operational procedures need an independent way to identify and stop the work connected to the old authority.

Work can end for reasons that matter to resumption. A successful pull request may finish the worker’s assignment while the ticket retains enough of its relationship to a discussion to resume when a person follows up. A human stop indicates a different intent. DeepSeek documents that a stopped ticket ceases to receive subsequent inputs through those relationships. Finishing a job and withdrawing permission are separate state transitions. That separation makes it possible to continue work when a reviewer discovers an edge case without treating a deliberately stopped ticket as dormant work ready to reactivate.

A new request that widens scope needs its own treatment. A reviewer might say that the importer fix should also change the public file format, a decision that affects existing clients. Even an authorised reviewer can make that request in a place where the current ticket’s mandate covers only a narrow patch. A new evaluation can record the broader authority and give the work an identity of its own. Keeping the original mandate intact preserves the history of who authorised which change. Rewriting it silently would make yesterday’s actions appear to have been approved under a scope that did not exist at the time.

The reporting surface can make these differences legible. A useful operator view can answer whether a request was explicit, which policy was active, whether the source allowed it and what text the model used to connect a candidate to a rule. The prototype’s panel shows the originating trigger, scope and policy version. An auditable decision contains records a person can compare against the underlying event. A language model’s polished explanation is less useful if the operator cannot tell whether the evidence mentioned in it actually existed when the decision was made.

A permission can be enforced at several layers. A worker prompt can tell an agent to stay within scope. A host tool can refuse an operation whose arguments fall outside a specific ticket. A service account can lack permission to perform the operation altogether. The same capability can have different enforcement depending on which route reaches it. The strongest available check belongs as close as possible to the consequential action. Application records are valuable for audit and routing, but they cannot substitute for repository or operating-system controls when a process has another way to act.

The mandate is therefore a useful bridge between the language in which people ask for work and the state a system can actually track. It will never settle every interpretive disagreement. A patch may technically satisfy a narrow request and still create a maintenance burden that a senior reviewer rejects. Authorisation says who may start work within a scope. Acceptance says whether the result should be used. Keeping those judgements separate gives a team more precise ways to intervene, and avoids making the model’s initial classification carry more weight than it can support.

Context has a storage problem

A system that listens continuously faces a choice every time it calls a model. It can include more background in the immediate context, which helps if the next decision needs it. It can keep background elsewhere and offer a retrieval path, which helps if the next decision has little to do with it. DeepSeek’s essay borrows the terms Inline and Spill for these choices. Inline material is available to the model immediately. Spilled material stays behind a reference. The two operations let the router retain access to far more work than it can afford to include in each request.

Take a review comment that asks whether “the earlier workaround” still applies. A short excerpt around the comment can include the text to which it replies and the relevant pull request identity. The complete discussion may contain a long log, a rejected proposal and messages that have nothing to do with the workaround. If the model needs the full story, it can follow the stored reference. A compact event description should contain enough information to justify opening the longer record. If it strips every useful clue, retrieval becomes a ritual. If it includes the whole discussion, the prompt becomes another copy of the archive.

The trade is especially sharp when several workers are active. A central session may need to know that there is an import bug ticket and that it owns a particular issue. It need not read all output from the worker’s diagnostic commands. The worker needs enough detailed evidence to reproduce the problem, without taking on the router’s view of all the team’s unrelated work. The coordinator and the executor have different working sets. Maintaining those working sets is part of the architecture rather than a formatting choice for the first system prompt.

The essay’s chain of recall makes these references traversable. An event can lead to a thread, which can lead to a ticket or a related session, which can lead to the material relevant to the query. That resembles opening a source from a citation and following its references when the first page is insufficient. A chain of recall relies on stable relationships among work objects. It can retain task provenance across months if the underlying records are kept, but it cannot guarantee that the model finds the right starting point or stops on the best evidence.

An older ticket may contain a decision that was correct at the time and obsolete now. A model that retrieves a fragment about disabling a feature has to recognise whether a later release removed the reason for disabling it. References should retain enough identity to distinguish an old proposal, an accepted decision and the current state. Retrieval restores evidence in its historical context. Treating every retrieved note as current instruction would erase the very chronology the system worked to preserve. Date, branch, policy version and source matter because they let a model and a reviewer tell which kind of claim they are seeing.

There is also a judgement about what belongs in a brief. A support conversation may contain a customer’s name and account details while the coding task needs only a failure mode and a redacted sample. If the same context travels through router, worker and audit logs, unnecessary data can be copied repeatedly. Context selection is a privacy decision as well as a performance decision. Leaving evidence in a retrievable store offers limited protection if every worker can fetch it or the identifier crosses a tenant boundary. Access rules must apply to retrieval in addition to the original source.

The public prompt document provides a narrower view of how this works in the prototype. It describes compact Trigger cards, resource pointers for truncated content and assembled prompts tailored to the main session or to an executor. Policy text is placed late in the main session’s assembled instructions so that a revision need not change the preceding material. The prompt is assembled from records and role instructions for a particular call. It is not a fixed copy of everything the system knows. The way cards and references are arranged can affect both cost and the likelihood that a model correctly interprets their provenance.

A technical reader should distinguish the cache analogy from the cache-read tokens reported in the benchmark. In the essay, treating a context window as a cache describes a decision about which facts to inline and which to fetch later. The reported cache-read metric counts token activity for the tested model calls. A retrieval design and a provider’s prompt caching are separate mechanisms. A system can manage retrieval thoughtfully and still produce many cache-read tokens by running several active contexts. Billing, cache hit conditions and latency require separate measurements on the provider actually used.

A concise summary is itself a model-produced artefact when generated by a model. If a worker writes “the maintainer approved the change,” a later executor ought to know whether that means approval of the approach, approval of a pull request or a comment phrased as encouragement. A summary should offer a path back to the underlying event. Keeping the raw message and its metadata lets a person audit the summary, and it gives a worker a way to recover nuance before taking consequential action. For long-running work the cost of carrying a pointer is small compared with the cost of treating a compressed inference as policy.

A related difficulty appears after software upgrades. A source may change the format of an identifier or a retention policy may remove older raw content. A pointer that once led to a discussion can then stop resolving. DeepSeek’s cookbook recommends choosing stable identifiers before implementation because those values persist. A retrieval scheme is only as dependable as the referential integrity beneath it. An operator should be able to distinguish a record that has been deliberately deleted, a connector that is temporarily unavailable and an object that the current worker lacks permission to read. Each case calls for a different response.

The point of keeping work outside a single context window is to make the right material available at the right moment. A worker investigating a bug may need the whole trace. A router deciding where a reply belongs may need only its parent and thread address. A reviewer may need the test result and evidence of the final scope. The record survives, while the view changes with the decision. A context system built on that premise is better suited to an ongoing team than one that assumes there will always be one sufficiently long conversation.

Background work changes the rhythm

The design essay describes an asynchronous variant of the agent loop. The standard mental model of a tool call is a sequence. The model asks for a command, waits for its result and then decides what to do. The ReAct paper by Shunyu Yao and colleagues helped describe the value of interleaving reasoning and action. DeepSeek’s proposal focuses on what happens when the action takes long enough that waiting prevents the agent from attending to other input. The launch of a background operation can return before the operation’s result exists. Its eventual output arrives as another event.

A long test suite makes the distinction clear. If a command occupies the only foreground turn for the full duration, the agent may appear unavailable while a human is trying to supply new acceptance criteria. An asynchronous interface can acknowledge that the test began, allow the agent to process the correction and reconnect the result to its originating operation later. Availability and completion become separate states. The agent can respond while work is still running, but its response should name what remains unresolved. Declaring a test successful when the only observed fact is that it started defeats the benefit of the architecture.

New input while a command runs introduces a version problem. If a worker changes files or moves to a new revision, a test result from the old revision can arrive afterwards. The worker must have enough information to know which checkout state it tested. In a simple case, the relevant context is the commit or a snapshot identifier. In a more complicated case, the result also depends on the environment, configuration and fixtures. An asynchronous result needs an identity that attaches it to the state it actually observed. The latest successful result in chronological order may be irrelevant to the latest code.

Stopping has a similar race. A user can ask the agent to halt while an external operation is finishing. The agent may stop receiving output after the command sent a request to another service. It may find an already-created pull request when it checks that service later. A stop request needs a documented cut-off and a way to reconcile effects that already happened. Immediate cancellation is valuable when available. An honest report about uncertain external effects is more useful than a confident “stopped” based solely on the disappearance of a local process.

The public execution design and the essay use different levels of description. The essay describes a broader asynchronous ReAct mechanism, which the authors say was implemented in Harness but was not enabled by default at the time described. The prototype’s execution documentation covers its own worker sessions, command behaviour and reporting. A claim about the essay’s loop should be kept separate from a claim about a particular prototype setting. Readers deciding whether to try the release need the latter. Readers studying continuous assistants can still learn from the broader mechanism.

A background queue gives operators choices about priority. If a system launches twenty long operations at once, the local machine or CI runner can become the bottleneck while the model stays responsive. A user may then be able to request cancellation but still wait for scarce execution slots. A responsive router can coexist with an overloaded worker pool. The architecture needs an explicit view of what is running, waiting, blocked on a person or blocked on an external service. Distinguishing those states prevents a fast acknowledgement from obscuring a slow delivery path.

Speculative execution is the more controversial form of background work. DeepSeek’s team describes acting on environmental signals before anyone explicitly asks, including attempting to reproduce a software issue discussed in chat. In the broader design, a meeting invitation might trigger private preparation before a person chooses how to respond. The risk depends on the effects of the preparation. Reading an already permitted calendar or running a test in a disposable checkout is easier to contain than sending a reply, committing to a meeting or modifying an operational service. The useful question is which actions the team permits in advance and under what conditions.

A worker that speculates too readily turns probability into workload. Suppose it starts preparing a fix for every mention of a known bug, even when the discussion merely asks whether a workaround still exists. A handful of successful guesses may look impressive while hidden jobs consume compute and fill queues. The relevant denominator includes the work nobody uses. Observation mode offers one place to estimate which candidates would be worthwhile. A later pilot can track how many inferred tasks produce accepted results, how many duplicate work already under way and how often a person has to stop them.

The practical difference between a draft and a send is especially important. An agent may produce a useful draft for a reviewer to consider while the author is offline. Sending it to another team may disclose information, make a commitment or create an expectation of further work. Preparation and delivery can have different approvals and different time limits. A long-running architecture should let a prepared artefact wait for the right decision without assuming that the arrival of an event permits the final external action.

To the people in chat, good asynchronous behaviour can feel boring. The agent acknowledges a legitimate request once, stays available for a useful correction and returns when there is something worth reviewing. The prototype’s philosophy document makes restraint a design goal. The user-facing conversation should reveal consequential state changes without showing every execution step. The test of that policy comes when work is delayed or uncertain. Silence is valuable while a known task is progressing. A clear question or status is valuable when the next move depends on a person.

The worker’s checkout and its limits

The prototype’s execution guide begins with a decision that affects every worker after the first. An operator specifies how a ticket gets a directory, typically through a prepare command that creates a worktree. The directory is part of the ticket’s environment. The executor uses it to inspect code and make changes. Separate checkouts let independent workers change files without sharing an active working directory. They also let someone open an unfinished change without asking the rest of the team to stop. That separation is a practical improvement even if the team uses agents for a narrow class of jobs.

Git’s worktree manual explains the mechanism. A linked worktree has its own working files and administrative state for the checkout, with a connection to common repository data. Consider two independent changes, one to a documentation generator and one to an importer. The workers can edit, stage and test in different directories. Each worker gets a concrete place to leave evidence of its attempt. A reviewer can inspect the diff even if a session was interrupted before it wrote a final explanation. A branch and its commits can be tied back to the ticket in a way that a temporary transcript cannot.

The convenience has a boundary. If both workers change the same parser and their branches are built from the same base, the changes can still conflict at integration time. Even patches touching different lines may depend on incompatible behaviour. One worker could rename a fixture while another adds a test relying on the old name. Clean parallel checkouts do not establish that parallel changes compose. Shared CI, review and merge policy still determine whether both can land. The worker can report a dependency, but a maintainer may need to decide whose patch should define the new contract.

The same point applies to services the checkout uses. Two tests can start separate processes that both try to bind the same port. They can write to the same database if the local configuration points to a shared development instance. They can download packages into a shared cache, where a lock or a long update changes the timing for both. Process-level resources often remain shared when directories differ. A team considering parallel execution needs to look at ports, test data, credentials and machine capacity, as well as the source tree. None of those conflicts will be solved merely by creating more sessions.

The prototype’s prepare command creates a convenient boundary around setup. The documentation explains that the command can fail the ticket and preserve its output. A retry can then attempt setup again. Preparation is a distinct failure stage with its own evidence. A missing compiler and an incorrect solution should not end up in the same performance report as “agent failed.” The first may mean that the host lacks a dependency. The second may mean that the model misunderstood the task. Knowing which failure happened tells the operator whether to repair the environment or change the assignment.

Consider a repository where setting up one checkout means downloading dependencies from a private registry. Every worker preparation might spend time retrieving the same packages and fail when the service limits bursts. Moving that cost into a shared, controlled cache can improve latency, but the cache needs a policy about who can write to it and which inputs are trusted. The choice to share an environment component exchanges duplicated work for a new dependency. A deliberately prepared base can give more consistent results than allowing each worker to infer a setup procedure from old documentation and try its own changes.

The public execution guide also describes a worker slot limit. Launching or actively running a ticket consumes a slot. An input from a person or a status request has a documented path to an extra slot when regular capacity is occupied, with different treatment for inputs such as CI updates. The scheduling rule gives an existing human follow-up a route ahead of ordinary new launches. It addresses a familiar problem in a shared queue. If every new ticket and every user correction compete under an identical rule, a surge of automated work can make it difficult for a person to redirect something already under way.

A priority slot can shorten one kind of wait while creating another. Suppose the pool is full of long tests and several users ask for status. If those requests are inexpensive, reserving space for them preserves control. If they trigger fresh investigation, the extra path can consume the resource it was meant to keep responsive. The significance of a priority class depends on what it actually causes a worker to do. An operator can inspect the effect by distinguishing acknowledgements, resumed work and new work in queue metrics. A single average across those categories would mask the trade.

There is a related question about how an executor spends a slot while waiting. A worker may be blocked on a design decision, waiting for CI or idle until a comment arrives. A running process can be cheap to keep around if it holds little memory and no scarce external lease. A paused session can still own a working directory, a branch and a test environment that nobody else should use. Idle work has a resource footprint even when the model is silent. Long-lived systems need rules about when to retain those resources and how to resume the ticket when they are released.

The small print in DeepSeek’s deployment guide deserves to be read before attempting a trial. It says that the managed router and worker presets run as the operator’s operating-system user with full access under the configured preset. The account wrappers choose the agent’s credentials by default, and the guide explicitly says they do not isolate the process. A worker can read what its operating-system identity can read. If the user’s home directory contains unrelated project data or credentials, a distinct checkout alone has done nothing to remove those from reach. The docs recommend a dedicated operating-system account containing only the agent’s credentials.

That warning changes how to interpret a familiar word in the design essay. An isolated worker session has its own context. An isolated working directory gives it a separate starting point for its files. Security isolation requires an enforceable boundary around the process or its resources. A model can follow a direction to stay in the assigned tree most of the time and still be exposed to a message that induces it to take a different path. In the published setup, real enforcement also depends on how the host is deployed. That is an independent engineering responsibility.

There are analogous limits on repository permissions. A dedicated GitHub identity can improve accountability because people can see that a branch or comment came from the agent account. The service’s permissions still determine what that account can change. An account that identifies an agent should also restrict what the agent can do. GitHub branch protections can require reviews, code-owner approval and passing status checks. A careful operator must inspect the matching rule and its bypass settings. The purpose of the policy is to make consequential changes depend on controls enforced by the service, even when a prompt encourages a different action.

The difference between the two boundaries is easiest to observe during a fault. If two workers produce overlapping edits, separate checkouts make it possible to compare their changes and discard one. If a worker can access secrets outside its checkout, discarding its branch does nothing to remove the exposure. Collaboration isolation simplifies recovery from file conflicts. Security isolation limits which mistakes can happen in the first place. DeepSeek’s prototype is valuable because the deployment guide states where that line falls. The published code can be studied on a dedicated host while the broader design is judged on the controls it would need in other environments.

Durable work needs more than a saved transcript

The design essay separates model-loop computation, persistent state and the environment where tools execute. A local coding assistant can keep those together on one machine. The arrangement is simple until the machine sleeps, the harness crashes or a task needs tools on another host. A durable ticket should outlive the particular process carrying out its next step. The broader proposal places the loop and persistent state behind separate interfaces so the process can be replaced without losing the work’s identity. It then treats the execution environment as a distinct component.

State in this architecture covers several things. The orchestration application needs to know that it admitted a request, assigned an executor and received some inputs. A session store needs to preserve interaction history and tool results that a resumed model might need. A checkout or remote service holds the effects of actions already taken. Each type of state has a different source of truth. The ticket can say a patch should exist, but Git has the commit. The session can say a message was sent, but the destination provides evidence that the message was accepted. Recovery works when the system can compare those records.

A process restart illustrates what goes wrong when these are conflated. Suppose the worker pushes a branch and opens a pull request, and the harness exits just before it records the outcome. The next worker sees an assignment that never reported completion. If it follows the transcript alone, it may repeat an operation that already succeeded. If it checks the branch and pull request first, it can recover the missing fact. Before repeating an external effect, find out whether it already happened. A stable ticket identity gives the system a way to relate a branch, a remote change and an interrupted assignment.

Amazon’s Builders’ Library discussion of idempotent APIs gives a complementary approach to retries. If a client sends a stable identifier for a request, a service that supports that contract can recognise a duplicate attempt as the same operation. The identifier matters because two requests with similar parameters can represent two legitimate intents. Stable request identifiers support retries without equating similar text with identical intent. The approach is easier for operations the system owns end to end. When a third-party service offers different semantics, the recovery path may require looking up the result or asking a human before retrying.

DeepSeek’s architecture guide describes a transaction around the Engine’s state changes and an effects mechanism that lets external work run after commit. Its Outbox keeps a receipt record and queues a reply as one local change. The application can preserve the intention to send even if it stops before sending. That helps distinguish a planned notification from one that was never queued. It does not establish that every external service guarantees delivery exactly once. Recovery still depends on the adapter, response handling and any identifier accepted by the destination.

The deployment needs to respect the same distinction when an outbound message cannot be delivered. The architecture document describes replies waiting while a source is disabled and being dropped when the conversation has disappeared or is no longer listened to. A dropped reply is a state an operator should be able to see. The coding work may already be usable even if the original notification has no destination. Retrying indefinitely could waste resources or post in a context that the operator deliberately closed. Recording the failure lets a person decide whether to contact the requester through an appropriate route.

The design’s remote execution example makes persistence more concrete. The essay considers a cloud agent loop and a lightweight component on an execution machine. The machine could be a personal development computer, a hosted environment or one created for a task. If it goes offline, the cloud process can retain the work’s identity and wait for a machine-dependent step. A durable coordinator can know about an offline environment without pretending to execute inside it. The prototype’s public local deployment is a narrower case and should not be taken as a demonstration of the full remote architecture.

Using the existing development machine has a practical attraction. It may contain an uncommitted reproduction, a toolchain tailored to the project or access to a test service that is difficult to reproduce in a hosted environment. Sending the operation to that machine avoids rebuilding everything somewhere else. The very facts that make a personal machine useful make it sensitive. It can hold unrelated projects, sign-in material and routes to private services. Remote commands into such an environment require controls whose importance grows with the fidelity of the access.

A remote execution design has to decide how a machine proves its identity and how an agent obtains permission for a particular action there. An environment reference in a model prompt is an instruction to use a resource. An authenticated request from the orchestration service is evidence that it came from that service. Neither alone establishes that the requested operation belongs to this ticket. The execution endpoint needs the information necessary to enforce its own policy. A design might require an environment-scoped grant and reject operations after it expires. Those are architecture choices to verify in an implementation, not features to infer from the proposal.

Machines also change while they are offline. If a developer modifies the repository before reconnecting, the environment may no longer resemble the one the agent last used. A deferred instruction to rerun a test could now operate on uncommitted work. A worker may find that its branch no longer exists or the dependency it needs is unavailable. Reconnection is a new observation of the environment. An executor should reconcile the ticket’s assumptions with what is actually present. Continuing from a durable state record is useful precisely because it gives the worker something specific to check.

Anthropic’s account of Managed Agents provides a useful comparison for this separation. It describes an architecture with a session log, an agent harness and a sandbox, and with execution environments provisioned when needed. Anthropic reports gains in time to first token after removing eager provisioning in its own system. That comparison supports the value of separating interfaces while leaving DeepSeek’s performance an independent question. A managed container provisioned for a task has a different trust model from a developer laptop that retains its own data and network access. Similar interfaces can support very different operating policies.

Persistence has a cost as well as a benefit. Stored event history gives investigators evidence, but it also creates a collection of messages, model inputs and potentially sensitive tool output. Keeping everything forever makes historical reconstruction easy until an incident exposes the archive. Retaining too little makes a worker unable to explain an older decision or recover unfinished work. The sensible retention unit may differ for an event, its decision record and its raw content. An operator could preserve an audit record and dispose of some sensitive payloads under a separate schedule. The references should then show what was retained and which material is gone.

Long-lived state also changes an upgrade. A transient assistant can often be restarted from a new prompt. A persistent service may have tickets whose subscriptions and pending replies were created under a previous schema, prompt or policy. The prototype’s architecture document discusses versioned settings and migrations. An upgrade has to preserve the relationship between work and its past decisions. Tests for a persistent coordinator should include state created before the change, interrupted effects and requests that are still in the queue. Fresh start tests alone cannot answer whether the service resumes yesterday’s work correctly.

The larger design is easiest to understand as an insistence on recoverable work rather than immortal sessions. Workers can fail, machines can disappear and policy can change. The system should preserve enough to show what it was trying to do, what it already did and whether permission still holds. Recoverability comes from reconciling durable intent with real effects. The next component in the essay extends that principle to failures a process monitor cannot see at all.

A watchdog needs something to measure

A worker can be alive and still make no progress. It can run variants of the same failing command, reopen a solved question or pursue a technically plausible fix that does not address the requested behaviour. A process health check sees a process. It does not know whether the activity helps the ticket. DeepSeek’s design essay gives an external Watchdog Session a role in assessing task progress as well as infrastructure faults. The proposal uses scheduled input to drive that session and describes it as having tools with which it can intervene.

There is a clear reason to make that control loop external to the worker being watched. If the worker has lost track of the objective, asking it whether it is on course may produce another explanation drawn from the same mistaken assumptions. A separate session can review the recorded goal, inspect evidence and compare successive attempts. An independent view makes it possible to ask whether activity has produced a new fact. It can notice that five apparently distinct retries still fail before any test starts because the environment cannot reach a package registry. The best intervention in that case is to mark the dependency, not to ask for another coding attempt.

External monitoring also gives a place to recognise outages common to several tickets. If all workers encounter rate limits from the same model provider, restarting each worker individually may multiply the demand on the provider. If they all fail after a host upgrade, the preparation environment may be at fault. A system-wide pattern can call for a system-wide pause. A watchdog should be able to distinguish an isolated execution problem from a shared dependency failure. That requires visibility across assignments and enough structured telemetry to compare errors without reading every private task transcript.

The public prototype documents narrower recovery paths. It distinguishes blocked and failed reports, retries certain transient model-provider and connection failures with backoff and preserves information about queued or read inputs across restarts. A failed preparation command has different handling from a transient model failure. The release already makes some recovery choices in application code. Readers should avoid treating those deterministic behaviours as evidence that the public bundle includes the broader semantic Watchdog Session described in the essay. An explicit retry condition and an independent model deciding whether a worker has drifted solve different problems.

Semantic monitoring needs a definition of progress. Elapsed time is an inadequate proxy for a task that involves waiting for CI or a review. Tool-call count is even worse. A competent worker may deliberately run one slow test because it is the best reproduction, while an ineffective one can generate dozens of low-cost observations. Progress is a change in evidence, artefact state or the decision that blocks completion. Examples include a reproduced failure, a discarded hypothesis, a verified patch, a review request or a recorded dependency. Monitoring should favour those facts over the appearance of activity.

The same test can be applied to an idle worker. A ticket waiting for a product owner to choose between backwards compatibility and a breaking API change should stay quiet until the decision arrives. A ticket that entered the same status because an outbound question was dropped may be stalled despite appearing to wait for a person. A valid wait includes a reason, a responsible party or event, and a way to verify delivery. The outbox and source state can help distinguish a genuinely pending decision from one nobody has been asked to make. That difference determines whether the next action is escalation or patience.

Intervention carries its own risk. A watchdog that automatically rewrites a worker’s instructions may turn a recoverable error into a change of scope. One that can edit global prompts or trigger rules has influence over work that was never involved in the fault. DeepSeek’s essay describes this kind of maintenance interface as possible for its watchdog. The recovery layer can have more authority than the worker it supervises. Any implementation needs a clear distinction between inspecting state, restarting an assignment, changing a rule and granting new capabilities. Each action should carry its own authorisation and record.

A helpful intervention can often be smaller. A watchdog might annotate the ticket with a reproducible environmental error, request a fresh observation of the remote branch or tell the operator that a retry would duplicate work already published. These are concrete outcomes a person can verify. The correction should be proportionate to the uncertainty it resolves. When the system knows only that two workers disagree, automatically selecting the one that sounded more confident is a poor substitute for comparing their evidence. Giving a maintainer the conflicting test outputs can make a more useful contribution.

There is a failure mode in which the watcher repeats the worker’s mistake. Two sessions using the same model and the same incomplete task summary can arrive at the same wrong inference. A second model call adds little independence if it receives only the first model’s account of events. Monitoring needs access to evidence independent of the worker’s self-report. A source could include a test artefact, the current branch state or the original request. It should also include permission to read those records. Adding a privileged monitor that can see every private artefact may solve an operational problem and introduce a confidentiality one.

Research on multi-agent failures makes the caution concrete. Cemri and colleagues analyse annotated traces and distinguish failures in system design, alignment between agents and task verification. Their taxonomy was developed on other systems. It offers categories for thinking about the prototype rather than measured failure rates for it. Independent verification has to target the error that would otherwise escape the system. Checking that the executor completed a turn will catch fewer mistakes than checking whether the reported reproduction matches the test output and the scope the team authorised.

An operator could evaluate semantic supervision with planted faults. A test harness could supply a ticket whose worker repeatedly misreads the same failing fixture. Another ticket could wait legitimately for a slow external job. A third could contain a branch already pushed before a simulated crash. The useful question is which interventions improve recovery and which merely increase activity. A watchdog’s false alarms should be measured alongside the faults it catches. Unnecessary restarts consume time and can erase useful working context, even if the system records the attempt as active supervision.

Long-running agents will inevitably meet conditions the designer did not anticipate. The quality of the recovery path can be judged by how well it limits those conditions and gives a person a reliable picture. A worker that cannot finish should be able to show what it tried. A watchdog that cannot settle the fault should be able to expose the evidence for a human. The objective is a predictable handoff at the edge of automation. Keeping the service online is only one part of keeping the work under control.

Evidence at the edge of the benchmark

DeepSeek’s team reported a scheduling experiment in the architecture essay. It replayed a stream of roughly three hundred messages, with about twenty work requests, across four arrangements. The remaining traffic included conversation, follow-ups, cancellation and CI messages. Each arrangement ran five times. A timing tool stood in for coding work, and the published comparison measured time from request to result message. The experiment asks how the system handles work under a controlled stream of interruptions. It does not measure how well the workers write code. Offloop’s English translation and the Chinese republication make the setup available alongside the account in 36Kr.

The four arrangements help isolate two decisions. One compares the full architecture with a version that does not deliver subscribed follow-ups directly to workers. The other compares the full architecture with a single session that has a subagent tool under two different delegation prompts. The baseline is part of the finding. A single session with a tool it rarely uses is different from a single session configured to delegate early, even if both have the same list of tools. Keeping both baselines visible is necessary to interpret the size of the advantage.

DeepSeek’s reported synthetic scheduling results

The design team’s figures compare request-to-result latency under simulated coding work. The median describes the middle of the measured completion times, while p95 describes the slower end. Cache-read tokens are a separate workload measure. The table does not establish total billed cost or performance of the released prototype.

The comparison with the neutral baseline is striking but specific. The reported p95 falls from 29.5 to 15.7 minutes. The difference is 13.8 minutes, which is about 47 percent of the baseline value. That figure describes a change in tail completion time within the reported simulation. It cannot be read as a 47 percent improvement in the productivity of a software team. Reviewing a patch, waiting for a build environment and fixing a mistaken implementation can each dominate the time saved by dispatching a worker sooner.

The two single-session results show a second effect. With a neutral prompt, DeepSeek reports that the model did not invoke its subagent tool in any of the five runs. With a delegation-first prompt, it delegated in four of the five. The median moved from 20.4 to 13.8 minutes, while the p95 moved from 29.5 to 29.0. Encouraging delegation improved the middle much more than the tail in these runs. The authors describe an instance in which the session still chose to execute what appeared to be small work and produced a longer tail. The experiment illustrates sensitivity to a prompt and a workload, rather than an invariant property of all single-session systems.

Against the stronger baseline, the median difference is 1.4 minutes, about ten percent of 13.8 minutes. The p95 difference remains much larger. A team deciding whether to build a separate coordination service should ask which part of the distribution it cares about. A routine queue may value median performance while an incident queue cares about long waits. Even within one queue, the p95 can reflect the fate of quite different work. A late documentation edit and a delayed incident diagnosis occupy the same mathematical percentile while imposing very different costs.

The direct-delivery ablation is the best example of why the table should be read in full. Removing the shortcut changed the median from 12.4 to 12.6 minutes and the p95 from 15.7 to 15.5. Those observations do not demonstrate a p95 latency win for direct delivery on this workload. Cache-read tokens fell from 31.77 million without the shortcut to 23.23 million with it, a reduction of roughly 27 percent relative to the version without it. The clearer effect of pass-through here is lower reported cache-read token usage. The essay’s broader argument that direct delivery reduces load at the router remains an architectural explanation to test under traffic that actually saturates it.

More cache-read tokens in one configuration do not give a bill by themselves. Prices depend on the model provider and how it treats cached input, new input and generated output. The workload can also create local compute, network and review costs that no token counter represents. A model usage category is evidence about work performed, with cost requiring a separate accounting step. A meaningful comparison would collect all model usage by role, the duration of execution slots, the utilisation of shared services and time spent by the people accepting the work.

The second experiment considered the router under a higher arrival rate for triggers requiring decisions. The authors reported that an increase from roughly one to forty triggers per minute coincided with larger batches and a drop in amortised inference time per decision, from 6.4 to 1.6 seconds. They also reported longer individual requests, from 2.5 to 3.9 seconds. Batching can improve throughput even when the request carrying a batch takes longer. A request-level latency figure and a decision-level throughput figure describe different things. Both should be kept distinct from the time an event spent waiting in a queue.

The design essay notes that synthetic message intervals and work durations were scaled while model-call durations were real. That choice changes the relationship between the time spent on routing and the time spent waiting for the simulated operation. The relative timescales are part of the experimental environment. On a real repository, a queue dominated by hour-long builds would place more weight on worker capacity. A queue dominated by tiny tasks and chat interruptions could expose overhead at the router more quickly. The reported configuration does not identify the crossover point between those cases.

The number of runs also matters to interpretation. Five replays per arrangement can demonstrate that a mechanism is worth investigating. They offer limited information about variation across repositories, providers and kinds of work. The cited sources do not give grounds to assign a confidence interval to the comparison here. The published numbers are descriptive evidence from a preliminary experiment. A team would need its own repeated trials to estimate variance, particularly if several jobs share traffic conditions and their completion times are correlated.

Even the definition of completion deserves scrutiny. A result message marks the outcome the experiment can observe. In engineering, a result message may announce that a patch is ready, that a bug could not be reproduced or that a human decision is needed. Those are different outcomes. A scheduling measure should count delivery consistently and leave acceptance as a separate measure. For a business trial, the interval to a result is useful as one checkpoint. The interval to an accepted change, including review and rework, answers a different question.

The most defensible reading is that architectural separation reduced the long waits associated with the tested single-session pattern, under a specific synthetic event stream. The reported cache-read figures and stronger delegation baseline prevent the result from turning into a one-line speed claim. DeepSeek’s evidence earns the scheduling hypothesis a real test. The next test needs to count the useful work that survives review as well as the work the system can launch.

The channels become part of the security perimeter

In a continuous agent system, a GitHub comment can be both a message to a team and text supplied to a model with tools. That dual use is the source of a security problem. A comment could include an instruction purporting to come from a maintainer, an innocent copy of text from somewhere else or a deliberately crafted request to use an unrelated credential. The model can read a sentence without gaining any authority from it. The application must retain that distinction when the text passes from the source to a router, from the router to a worker and from the worker into a tool request.

OWASP’s prompt-injection guidance distinguishes direct input from instructions embedded in material the system consumes. In this setting, an indirect injection could arrive in a repository file, build output or comment that an agent opened while doing authorised work. An external contribution can be legitimate evidence about a defect and still contain text the model should never obey. The security question is which operations are possible after a model misreads untrusted data as an instruction. If a worker can only prepare a local patch in an environment without unrelated secrets, the effect is narrower than if it can execute commands with a developer’s normal access.

The prototype’s two-stage admission model helps address one part of this problem. A new request can be checked against authenticated source metadata before a model assesses it. A forged claim inside a message cannot by itself alter the sender identity supplied by the source. Programmatic admission limits who can start work through the ordinary intake route. An attacker may have another path into the model’s context. Comments on a followed thread, code the worker is asked to read and output from external tools can all be relevant to an existing job. Each path needs to preserve provenance.

Consider a review thread on a public repository. An outside contributor posts a valid reproduction, and a later comment in the same thread asks the agent to use a deployment command. Treating the thread as context for the work is reasonable. Letting any comment inherit the maintainer’s permission would allow the conversation to enlarge the scope. The authorisation guide describes how the prototype handles context-only subscriptions and how out-of-scope follow-ups can be handed back. Routing to the right worker does not answer whether the requested action is allowed. The actual ability to use a deployment service should be constrained independently of the worker’s classification.

A worker with full access under the operator’s account can invoke programs that were never listed as dedicated tools in the user interface. This is why a narrower list of named tools is only one control. Blocking a particular shell command through a wrapper can prevent an ordinary route to it. It is weaker if the same operation can be performed through another binary, a library or a network client. The enforceable capability boundary includes the whole process environment. For the public prototype, DeepSeek’s deployment guide says the account wrappers are not isolation and advises using a dedicated operating-system account with only the agent’s credentials.

Repository permissions deserve the same scrutiny. The identity that can push a branch may also be able to alter CI configuration, depending on permissions and repository policy. A CI job can, in turn, have capabilities that differ from the agent’s local process. A patch can change what another system executes. Reviewing modifications to workflows, dependency declarations or deployment scripts therefore requires more attention than counting lines in a diff. A small change in a privileged path can have a larger effect than a substantial edit to documentation. That distinction matters whether the patch came from a human or an agent.

The dedicated bot account still serves a useful purpose. When a pull request appears under that identity, operators can distinguish its author from a particular employee and review its activity. Credentials can be rotated or access removed without changing the employee’s own account. Attribution and least privilege reinforce each other when the account has a narrow grant. The scope must be checked in the services themselves. If the account belongs to several organisations or can bypass branch protections, an application-level promise to work on one repository is a weaker assurance than it appears.

OWASP’s excessive-agency guidance names a general class of risk behind these examples. A system can offer too many operations, too much permission for the operations it exposes or too much autonomy to use them without review. Applied here, an agent tasked with collecting diagnostics could have permission to read test output and post a draft report. It may never need to modify an external configuration. Removing an unused capability prevents more failures than telling a model to avoid using it. Even a well-understood model can misinterpret a novel message, and a perfectly classified message can still lead to an erroneous action.

The identity problem grows when a worker can use more than one channel. A person may be in a private Feishu group and a public GitHub repository. A response appropriate for one place can disclose internal context if sent to the other. The prototype’s records distinguish incoming sources, channels and the addresses to which responses go. A correct answer can still be a security failure when it reaches the wrong audience. An integration should know which output belongs in a public comment, which belongs in private review and which must remain in the worker’s records.

A similar principle applies to log access. Investigating a routing mistake often requires seeing who sent the message and why the application admitted it. Investigating a model mistake may require reading a larger prompt or tool output. Those are different views with different exposure. Auditability does not require making every raw payload visible to every operator. A team can retain a redacted decision trail for routine supervision and grant access to sensitive artefacts only when necessary. If data copied into a model’s context is sensitive, controlling the archive without controlling that transfer is only partial protection.

The scope of an incident also changes with persistence. A one-shot assistant can act on one misleading input. A continuous system can save the misleading summary, attach it to work and retrieve it again later. If the summary is mistaken for a permanent team rule, the problem can survive after the original event has disappeared from normal view. Provenance matters again when stored context is reintroduced. Rules, observations and agent inferences should remain distinguishable in the data model. A secure design should have a way to amend or quarantine misleading context without rewriting the genuine history of who saw it.

The public documentation’s discussion of prompt overrides introduces another control surface. Team guidance can be edited, versioned and compared with upstream defaults. This flexibility is useful for improving behaviour and matching a repository’s practices. It also means a change to settings can alter the way the system reads every subsequent candidate. Editing coordination policy or durable instructions should leave an audit trail separate from ordinary conversation. A pull request author might be allowed to ask for a test. That authority need not include changing how the system handles future comments from everyone.

A careful trial can make these risks observable without waiting for an incident. A team can seed harmless fixtures that look like credentials, use an isolated account and attempt a forbidden operation through more than one interface. It can verify where a public reply would go and whether a private message can contaminate it. Test the boundary at the service that enforces it. A prompt that tells a worker it cannot merge is easy to inspect. A rejected attempt to merge under the actual agent account provides evidence about GitHub’s enforcement in the configured environment.

There is a useful distinction between learning from the prototype and deploying it as a trusted actor. The repository offers a concrete way to study event routing and stateful authorisation. The release’s own description warns that it is research code and is not production-ready. The inspectable value of the design survives a narrow deployment boundary. The most important features can be evaluated in a small repository and a dedicated environment, without putting the architecture’s hardest security assumptions into production first.

An agent that speaks in the right place

DeepSeek’s philosophy document treats human attention as something a system spends. The public prototype is meant to acknowledge work, stay quiet during routine progress and speak when a person needs to decide something or can use a result. The people in the conversation need fewer interruptions, with clearer consequences when an interruption is necessary. A useful background agent resembles a colleague who knows when a question belongs in chat and when it belongs in a pull request, rather than a terminal session that exposes every command to an audience.

The design essay draws a distinction between fast conversational channels and asynchronous delivery. A chat request may require a short acknowledgement and, later, one concrete question. The pull request can carry the fuller evidence, including the background, diff and verification. The channel should match the decision the recipient has to make. In a fast chat, a long transcript can make a simple decision hard to find. In a review artefact, a sentence that says “fixed” can force a reviewer to repeat the entire investigation. The same system needs both kinds of communication.

A question is useful when it moves a specific piece of work. Suppose a worker discovers that the importer can reject an invalid record or keep the record and log an error. The answer changes public behaviour and affects existing users. A concise question can name the two behaviours, state the evidence and ask the person who owns the choice. Escalation is most useful when it identifies a decision the worker cannot legitimately make. Asking a group whether anyone has thoughts about an unfinished change is a weaker intervention because nobody knows who has to respond or what work is blocked.

The prototype’s panel provides a separate place for details people do not need in every conversation. It shows source conditions, event histories and tickets that need action. An operator can use it to distinguish a worker waiting for input from one that failed to receive input. A panel should surface decisions and anomalies without asking someone to watch normal activity. The presence of an attractive overview cannot rescue a system that makes every operator check it repeatedly to see whether a requested action happened. Useful supervision starts with an accurate record of what is waiting and why.

The boundary between progress and result is also a communication choice. A worker might find that a bug is reproducible, prepare a patch and then discover a second failure in validation. Sending each of those observations into a busy chat can exhaust the reader’s attention before there is anything to decide. A single result with the reproduction, the current obstacle and a concrete request conveys more. Routine progress belongs in a retrievable record unless someone can act on it now. A deadline or incident can justify more frequent status because the timing itself affects decisions.

There are cases where silence is the failure. If a ticket is likely to miss a commitment, the team may need to know before the worker can produce a final artefact. If a queued job cannot start because the target repository is unavailable, an operator can fix the problem. A useful notification policy is sensitive to consequences as well as state labels. Two tickets can share a blocked status and warrant different treatment. The system needs a way to convey that one is awaiting a routine review and another is keeping a release on hold.

The source of a response matters for accountability. A user should know whether a statement came from a maintainer, a CI system or the automated agent. The prototype’s approach of using a dedicated account and its guidance for delivery make attribution visible. An agent’s message should never appear to carry a person’s approval simply because it is fluent. A result can describe what the system tested, quote an external decision with its origin or request a human decision. It should leave each authority visible. That is particularly important when messages pass from chat into a review where a different team reads them.

A team can make the interface more useful by paying attention to negative space. How often does the agent ask a person to repeat information already available in the original thread? How often does it announce work the team never asked for and does not use? Does a person have to leave a review to open another interface in order to say stop? The cleanest coordination removes some messages and actions from the workflow entirely. Counting the messages an agent sends, without asking which ones replace manual work and which create it, tells little about the experience.

In a longer project, the operator may want to look across several tasks without reading each transcript. A ticket list can show that two jobs are ready for review, one is waiting for a source and one needs a decision. If those states correspond to concrete artefacts and owners, the operator can choose what to do next. The task is the useful unit of supervision once one visible conversation covers several workers. Model sessions are still valuable for diagnosis. People should rarely need them as the default way to learn whether an assigned job is under control.

There is a trade in hiding implementation details. A human who understands how the system routed a task can correct it when it goes to the wrong worker. A human confronted with all routing and tool activity may simply stop looking. The interface should offer deeper evidence on demand without requiring everyone to read it. The panel’s event-to-decision history is one example. In the working channel, a clear ticket identity or pull request reference provides a compact route to the evidence when a colleague needs it.

The same reasoning applies to interventions that stop work. If cancelling takes a command hidden in a control panel, people may post an ordinary message and assume the worker understood. If every use of the word “stop” cancels an unrelated task, the interface is too broad. A stop needs a predictable scope and a visible acknowledgement of its effect. The user should be able to tell whether work stopped, which external operations were already completed and what artefact remains available for inspection. That is an ordinary product requirement with serious implications for any long-running agent.

The best human-facing result is often an ordinary object that fits the existing workflow. A pull request with a clear test result can be evaluated using familiar habits. A ticket linked to an issue can be handed to a person when the agent reaches a boundary. The architecture succeeds at this level when people can continue working in the tools where they already have context. The machinery underneath earns its place by making the interaction clearer and by preserving the evidence when someone needs to look closer.

Other orchestrators solve different coordination problems

The Router and Worker labels are familiar because software already separates scheduling from execution in many settings. DeepSeek’s essay draws on batching, fast and slow paths and durable state. 36Kr makes a similar point when it locates the contribution in applying established engineering techniques to agents. The original contribution to evaluate is the combination of a persistent intake role, explicit task ownership and scoped follow-up delivery. A useful comparison starts with the unit each architecture coordinates. A single user request, a stream of team events and a pool of execution environments each demand different contracts.

Anthropic’s Building effective agents describes an orchestrator-worker workflow that starts with a complex request. The orchestrator figures out the subtasks and assembles the results. That fits problems where the answer benefits from decomposition and the subtasks cannot all be planned in advance. A code change might require several independent investigations before someone can see the correct implementation. The life of that orchestration can fit inside the life of one request. DeepSeek’s design makes the coordination layer longer lived. Its router must still handle the next independent issue while a worker is halfway through the first.

Anthropic’s account of its multi-agent Research system gives a concrete example. A lead agent can delegate independent directions of inquiry and combine the findings. Breadth is useful when one investigator can search corporate disclosures while another examines technical research and a third checks official statistics. The outputs are useful in combination because they can be produced independently and checked at synthesis. The analogy has limits in a software repository. Two workers with overlapping authority to modify a shared interface can create incompatible effects, even if their individual reasoning is good.

An orchestrator can therefore fan out in at least two ways. It can split a single difficult task into complementary activities, or it can dispatch separate tasks that the team wants completed independently. Those patterns can be nested. A DeepSeek worker may itself use subagents on a complex job, while the coordinator keeps the job separate from other requests. Delegation inside a ticket and coordination across tickets solve different problems. An organisation can benefit from the first without needing an always-on router. A continuous system can benefit from the second even when each worker completes its ticket without spawning another agent.

Anthropic’s Managed Agents engineering account is useful on a separate axis. It describes stable interfaces between logs, a harness loop and execution environments. That comparison clarifies the design decision to separate state and computation from execution. A runtime can be durable without providing team-wide event triage. Conversely, a team router can assign work to several local workers without offering a cloud control loop that calls into personal computers. Similar diagrams can conceal different promises. The reader should ask which part of the system is intended to survive, what it can replace and who controls the environment on the other side of the interface.

A fixed workflow is another valid reference point. An existing CI pipeline can run a known set of checks when a pull request opens. It needs no semantic decision about whether those checks count as a task. A repository bot can assign reviewers according to file ownership. When the condition and action are known, explicit automation keeps behaviour easy to predict. Model-based routing has a more plausible role where the input is incomplete or the team needs to infer which job a discussion belongs to. Placing a model between a clear event and a fixed action adds an extra decision without necessarily adding useful information.

Coordination patterns and the evidence behind them

The patterns can coexist. One team may use a persistent router to recognise a request, an executor with temporary subagents to investigate it and repository rules to govern the resulting patch. The source for each pattern describes a different job, so the comparison does not rank products or transfer measured results between them.

The public prototype is attractive as an example because it documents decisions a framework diagram often omits. It has names for the event, the evaluation, the authority, the work and its assignment. These allow an operator to identify exactly where a candidate went wrong. A framework that can call five agents in parallel does not necessarily supply records for a team’s authority or lifecycle. A team could build those around a framework, but it has then chosen to build part of an orchestration application. The cost of that work should be counted in any comparison.

There is also a reason to avoid treating “single session” as one rigid category. A product can provide durable queues, several visible tasks or separate workspaces without implementing precisely the topology in DeepSeek’s essay. 36Kr explicitly distinguishes DeepSeek’s research emphasis from a claim that existing coding products cannot handle independent tasks. Product capability and experimental baseline need to be compared at the same level. The benchmark’s neutral-prompt condition is an arrangement the authors tested, rather than a measured representative of every commercial tool that exposes subagents.

A practical comparison can begin with three scenarios. In the first, a person asks for a self-contained investigation and wants a single answer. In the second, a team needs multiple issue threads to continue independently while review comments arrive. In the third, a remote executor must be replaceable without losing track of authorised work. Each scenario exposes a different dependency on the architecture. The first tests decomposition, the second tests routing and authority, and the third tests durable state and execution boundaries. A demonstration that performs well in one leaves the others open.

Consider a code audit as an example. A lead agent can ask parallel reviewers to look at input handling, error recovery and tests. They can all read the same code and return findings, with a human choosing what to act on. The system mostly needs distinct attention and a way to combine evidence. If the same agents are asked to apply fixes independently over several weeks, the workflow changes. The transition from findings to ongoing write access introduces ownership and integration problems. A list of useful findings can be merged in prose. A list of incompatible code changes requires repository controls, decisions about sequencing and more careful treatment of review.

A further distinction concerns where feedback arrives. In single-request decomposition, feedback can often go to the lead agent while the original task is still open. In the persistent model, a person may return weeks later through a different channel after the original worker has ended. A later review event needs a durable address even when the original conversation is quiet. This is where the public prototype’s association of threads with tickets has clear explanatory value. It models why the event belongs with the old work, without assuming that the original process must remain continuously active.

These differences make it possible to borrow pieces without buying the whole premise. A team can introduce durable work identities before model-based intake. It can use explicit requests from a small set of people before enabling inferred work. It can build a queue with robust retry and state reconciliation before adding an independent model supervisor. The most transferable components are the ones with clear inputs, decisions and failure modes. The publication shows where those components meet. Whether the full combination earns its operational cost depends on the work a particular team needs to coordinate.

The economics of a busy worker pool

A burst of independent jobs is the easiest situation in which to see an advantage from concurrency. Imagine a team asking for several small repository changes at the end of a release meeting. If each request can be handled in isolation, distinct workers can start without waiting for the previous patch. The release engineer can use the remaining time to prepare verification. Parallel work trades execution resources for shorter elapsed time when the tasks are independent. The business value depends on whether the earlier results arrive at a moment when somebody can use them.

Most working weeks are less tidy. A team often waits for a maintainer, a shared test environment or the next deployment window. If the new worker pool delivers several changes just before the maintainer becomes available, the bottleneck may shift to review. More unfinished pull requests then accumulate in the same queue. Faster dispatch can expose a downstream limit that was previously hidden. A useful trial measures how long a task waits at each step and distinguishes time spent preparing a result from time spent waiting for acceptance.

The relevant cost is broader than the invoice for model tokens. A worker can consume machine time preparing a checkout, running tests and waiting for services. A router can consume tokens on cases no worker ever starts. An operator can spend time on setup and support. A reviewer can spend time checking whether an automatically proposed patch matches its stated scope. A complete cost model follows each accepted result through the resources it used. It also counts the work produced and discarded along the way. Counting only the cheapest visible input misses the operating burden.

The benchmark illustrates why a token comparison needs detail. The full design used more reported cache-read tokens than either single-session condition in the published experiment. The direct-routing version used fewer of those tokens than the architecture without that path. The relevant comparison changes depending on which architecture serves as the baseline. A buyer evaluating costs needs a breakdown of input, cache, output and any other chargeable dimensions, plus worker infrastructure and staff time. Reading the table as a price list would assign a business meaning the experiment was not designed to measure.

There is also a cost to conserving every possible token. Reducing a worker’s context can make a call cheaper and increase the number of retrieval trips the model needs. Removing a citation to the original scope can make a prompt smaller and raise the cost of mistaken work. Useful economy is a reduction in cost for the same accepted result. A cheaper turn that leads to a rejected patch may be the expensive choice. Conversely, larger prompts can obscure the one relevant fact. Measuring costs together with review outcomes gives the team a way to make the trade deliberately.

Workloads have different marginal costs. A test suite that depends on a scarce staging service is expensive to duplicate, even if the model reads only a few tokens. A routing judgement that uses a cached prompt and a brief event may be cheap, but thousands of such judgements can still matter. The first saturated resource is more useful to identify than a universal concurrency target. If the package registry is rate limiting workers, increasing the worker limit may prolong setup for everyone. If review is the bottleneck, the answer may be a smaller queue of better-documented changes.

An admission policy can make that economic decision visible. Explicit requests can represent work a person already judged worth starting. Inferred requests require a separate judgement about expected value. Suppose an agent notices an obscure warning. It may be cheap to check whether the warning is already tracked and expensive to prepare an unsolicited refactor. Speculation works best when it can stop at a low-cost, useful observation. A trial can define separate budgets for triage, reproduction and implementation. This is an analytical recommendation for evaluating the design, rather than a claim about a packaged spending feature.

The queue also needs a way to manage changing priorities. A bug that was urgent before a rollback may become routine afterwards. A task that depended on a reviewer may suddenly become actionable. If the worker continues under yesterday’s priority until the next scheduled refresh, it can spend effort that nobody still values. A new event can change the value of finishing a task without changing the task’s technical scope. An effective coordination layer should preserve that distinction. Stopping or postponing a task does not necessarily require a new mandate, while changing what the task is allowed to do may.

An operator might use a small set of separate measurements. Record how many requests were admitted, how many reached a result, how many results were accepted and how many required human intervention before completion. For work that was inferred, distinguish the cases the team would have undertaken anyway from those the agent discovered. The rate of accepted work should be read alongside the rate of attempted work. A system that submits many abandoned patches can look productive under a throughput measure while costing more attention than the existing workflow.

Time saved should be allocated carefully. If workers complete tasks during an otherwise idle period, a benefit may appear in elapsed time even when human labour barely changes. If a reviewer can make a decision using evidence the agent assembled, the benefit may show up in fewer repeated investigations. Elapsed time and labour time answer different business questions. Faster elapsed delivery can matter for incidents and commitments. Lower labour time can matter for recurring maintenance. A credible trial should report both when both influence the decision to keep the system.

The maintenance work itself deserves a place in the accounting. Rules have to reflect staff changes, repository conventions and which sources the organisation wants the agent to listen to. Credentials need to be managed. A breaking connector change can require repairs. A prompt override may need review after an upstream update. A continuous agent creates a service to operate. The service can still pay for itself, but the right comparison includes the time needed to keep it dependable. An experiment that counts only successful demonstrations avoids the recurring work that decides whether a trial can last.

Buying more model capacity can have little effect if the underlying task definitions are poor. A ticket that asks for “better performance” without naming a workload or a measurable regression sends a worker into open-ended investigation. The coordinator might correctly route the request and still produce a costly attempt nobody can evaluate. A good intake process improves the quality of the task as well as the speed of assignment. Sometimes the useful result is a clarifying question that turns an indefinite wish into a narrow, measurable job. That is one reason to count human decisions made easier, even when no patch results.

A team deciding whether to invest in continuous coordination can look for repeatable sources of saved effort. Follow-up forwarding, finding old task context and keeping routine work moving while a developer is busy are plausible examples. A team with few shared events, little simultaneous work and short feedback cycles may find that a human already coordinates those tasks cheaply. The architecture has the best economic case where coordination is frequent enough to measure. The next section turns that proposition into an evaluation that a real team could conduct without assuming the published timing gains will transfer.

A field test should follow the work to acceptance

A team can test the central idea without replicating DeepSeek’s internal environment. The question is whether event-driven coordination removes work that people otherwise perform and whether the resulting changes survive review. A suitable starting workload is a collection of familiar, independently reviewable jobs with histories people understand. Choose a workload with real follow-ups and a clear standard for acceptance. A demonstration where every prompt contains a complete specification and arrives in an empty queue leaves out much of the problem the router is meant to solve.

The pilot needs a credible baseline. If the current team uses one worker per issue with a person forwarding feedback, measure that practice. If the team already uses repository automations and separate concurrent agents, record the benefit of those tools. Compare against the way a competent team works today. A weak baseline can produce a large apparent gain while avoiding the cost of building the same feature through simpler automation. DeepSeek’s delegation-first comparison is a reminder that a stronger baseline can change the size of the measured improvement.

Keep the test small enough to understand failures. One repository with a reliable test suite and a few recurring work categories gives reviewers a shared frame of reference. The public bundle is explicitly designed around a single GitHub repository, so this also stays near the documented deployment. A pilot should make it possible to trace each result to the incoming request and the policy that admitted it. If a worker repeatedly fixes unrelated issues, the operator needs to see whether the admission rule was too loose or the executor misunderstood a narrow task.

The first phase can collect evidence without running inferred work. Review a representative sample of candidates from busy periods and quiet periods. For each one, classify whether it should have started, should have attached to existing work or should have been ignored. Record what the team would have done without the agent. A candidate can be technically valid and still unwelcome if it repeats an ongoing investigation or addresses a problem the team deliberately deferred. Observation provides a way to catch those mismatches before the agent starts producing changes.

Explicit work can provide a useful parallel sample, subject to the team’s chosen rules. A maintainer can assign a bounded job such as reproducing an issue and preparing a failing test. Reviewers can then measure how well the system retains scope when another person adds an example or asks a related question. A good trial should deliberately include scope changes and corrections. An agent that handles isolated prompts well may still route a later correction to the wrong ticket. The benefit of the architecture should appear in those difficult moments.

Next, measure the individual stages. Record receipt to admission, admission to execution, execution to the first reviewable result and reviewable result to acceptance or abandonment. A time series for each stage is more useful than a single end-to-end median when a task waits for a scarce dependency. Track the time a human spends in each stage as well as elapsed time. Ten minutes of calendar delay in a test runner does not equal ten minutes of reviewer work. Both can influence a decision about the service, and they should remain separate in the records.

For delivery quality, ask reviewers to assess whether the result addresses the original work, whether the tests support its claims and how much rework it needs. For routing, measure whether each follow-up reached its intended ticket, whether duplicates were created and whether an unrelated request stayed separate. Pair delivery metrics with errors specific to coordination. The aim is to understand what the router contributes independently of model quality. A good patch attached to the wrong issue and a bad patch attached to the right issue need different fixes.

The work categories should include some that are deliberately unsuitable. A request that needs product judgement may be appropriate for investigation but should stop before implementation. An ambiguous comment may need clarification. A high-risk repository path may be excluded even when the model is able to propose a patch. A correct refusal to proceed can count as a successful routing outcome. If the evaluation gives credit only for code changes, it rewards the service for ignoring situations where a person must decide. The ability to leave a clear handoff is a result in its own right.

Fault tests can cover the time between effects. Interrupt the worker after it creates an external artefact but before the assignment records completion. Disconnect the model provider or event source for a controlled interval. Test whether a correction sent before restart reaches the right task afterwards. A recovery test should check external side effects and message ownership alongside process health. A service that comes back online with two duplicate pull requests or a lost cancellation has not restored the relevant state, even if its dashboard is green.

Security tests need their own scorecard. Verify that the dedicated identity cannot bypass the repository policy, that the execution host cannot read a harmless secret placed outside its permitted area and that a comment from an unauthorised source cannot start new work. Examine an approved worker’s response to unrelated instructions in a document it legitimately reads. A clean intake test does not exercise every route into the worker’s context. The more realistic test checks what the tools and service accounts actually permit after the model receives misleading material. All test inputs can be kept synthetic and free of genuine credentials.

A trial can also compare communication patterns. Count clarifications that were necessary, clarifications that repeated available facts, unsolicited notifications and results that gave a reviewer enough context to act. Ask the team which messages replaced work and which generated another interruption. Attention should be measured from the recipient’s point of view. The same notification may be helpful to a maintainer and distracting to everyone else in a large channel. A small repository can expose this mismatch before the agent is invited into more conversations.

The cost comparison should use consistent task classes. Investigations, documentation edits and multi-file behavioural changes draw on different resources. A worker pool that handles simple work sooner can change the mix of what gets attempted, and the change can make the average task look cheaper without reducing the cost of any class. Report accepted results by type before aggregating them. When a comparison shows savings, it should be clear whether the system reduced manual coordination, improved scheduling or simply selected easier work.

A fair test also records the work the operator performs outside the visible queue. Creating a dedicated host, selecting settings, updating policies and handling failed source synchronisation all consume staff time. A durable deployment may lower those costs after the initial setup, but that expectation should be tested over a period long enough to include ordinary maintenance. A trial measures the service people actually operate, including the work required to keep its configuration aligned with the team. Time spent by an operator to rescue a demonstration is part of the result.

Acceptance needs a clear exit condition. If the system saves time on authorised, routine tasks and can be stopped predictably, the team can decide whether to expand the policy. If it tends to misroute important follow-ups, produces more review work than it saves or cannot enforce a repository boundary, the trial has located a concrete blocker. Expansion should depend on observed outcomes rather than increasing the number of connected channels by default. A negative result for proactive work can coexist with a positive result for explicit requests and direct follow-up delivery.

The study design also makes it possible to separate architecture from model changes. Hold the task mix and review criteria steady while changing a routing configuration. Keep a record of which models and prompts were active. If both the model and routing policy change at once, the team may see a difference without knowing why. The durable ticket history can become evidence for improving the system that produced it. Evaluators can compare two runs at the same decision point and see whether a better result came from better classification, better execution or a more useful request.

A field test of this sort does not need to reproduce the exact timing ratios reported by DeepSeek to be informative. It can find a smaller, concrete gain in one bottleneck and no gain in others. It can also show that explicit automation solves most of the problem a team thought required model judgement. The deployment earns its place when accepted work gets easier to coordinate under the team’s actual constraints. That standard leaves room for the architecture to succeed in a bounded role while its more ambitious proposals remain open.

A late result, a correction and a stop

A useful trial case can be built around three messages that appear to disagree. Imagine a worker fixing an importer and opening a pull request. A reviewer says the patch must preserve empty fields. CI then posts a successful result for the earlier commit. Finally, the requester says to stop the current patch because a maintenance branch needs a different fix. Each message concerns the same work, but each carries a different kind of evidence or authority. The review changes the criteria, the CI result describes one revision and the stop concerns future activity. A system should be able to preserve all three distinctions even if the messages arrive in a different order.

Begin the test with an explicit request from an authorised maintainer and save the resulting ticket identifier. Record the first pull request and its head commit. Deliver the reviewer’s correction while the worker is waiting for the original check. The control system should associate the correction with the existing ticket. The acceptance evidence should name the version it refers to. A test log reporting success for the earlier head cannot prove the revised patch preserves empty fields. The review should be able to point to the revised commit and the relevant result without relying on an assistant’s memory of the sequence.

Now delay the CI event until after the reviewer’s correction has arrived. This forces the application to distinguish event arrival from the time of the underlying action. If the event is routed directly to the worker through a subscription, its fast delivery is useful, but the payload still needs a commit identity. Routing the old result correctly and interpreting it correctly are independent outcomes. The trial can pass on the first and fail on the second. That distinction allows the operator to improve context and evaluation without dismantling a routing mechanism that worked as intended.

The stop introduces a different ordering question. When it arrives, the worker may already have pushed a follow-up commit or started a new test. Record the branch state and external job before and after the instruction. The expected result should distinguish operations already committed from actions that should cease. A visible acknowledgement can say that the branch exists and that no further edits are planned. If an external job cannot be cancelled, a later result can be retained as an observation without triggering a continuation. This gives a maintainer evidence about the actual effect of the stop.

A further comment can test the difference between a stopped ticket and an ended one. Ask another participant to post a helpful example after the stop. That person’s message might be worth evaluating as new evidence for future work. It should not quietly reactivate the stopped assignment. The ticket’s deliberate stop should survive an otherwise plausible follow-up. The domain documentation makes this a distinct state. The trial can inspect whether the message was handled by a fresh intake decision, ignored under policy or directed elsewhere, while confirming that the previous ticket remained stopped.

The maintenance-branch request makes a useful companion test. It refers to the same bug but may require a different branch, dependency set and compatibility guarantee. Have the maintainer submit it explicitly with the required branch named. A similar problem can require a separate ticket when the intended effect changes. A coordinator that groups tasks by text similarity might attach it to the wrong job. One that records the new scope and its authority can preserve the relationship to the earlier defect without mixing the branches or confusing the approval history.

In a second run, inject a crash between the creation of the pull request and the recording of the worker’s result. Restore the same state and inspect what the recovery path does. DeepSeek’s execution guide says a restarted worker is instructed to check its directory, Git history and GitHub before repeating an outside action. The trial can verify whether that recovery instruction leads to reconciliation in the configured environment. The observable result is one existing pull request correctly associated with the ticket, or a clear report if association could not be established. A success message by itself is insufficient evidence.

The sequence can also test a connector without real infrastructure changes. Replay an identical event identifier twice and a similar comment with a different identifier once. The first pair represents delivery duplication. The other message represents distinct communication, even if its wording is close. Event deduplication and semantic task deduplication should produce different records. The adapter can supply stable identifiers. The coordinator still needs to decide whether the distinct message belongs to the existing task. DeepSeek’s domain model and connector cookbook make it possible to formulate those checks separately.

A run through the human interface should answer a different set of questions. Can a reviewer tell which commit was checked, which request ended the original assignment and whether a maintenance branch has its own owner? Can an operator explain why a follow-up was recorded without restarting work? Use the public artefacts and panel before opening the model transcript. If the answers are available only by reading internal tool traces, people will have to carry much of the operational context the architecture was meant to preserve. The transcript is still useful for a deeper diagnosis after the high-level path is clear.

Vary the case again by changing who sends the late message. A bot reporting a check, a reviewer with the relevant role and an unrelated contributor should remain distinguishable after the event has reached the ticket. A reviewer’s observation that a case fails can be valuable regardless of whether that reviewer can authorise a new deployment step. A single thread can carry useful evidence from people with different permissions. Keeping its participants distinct allows the worker to take legitimate technical evidence seriously while keeping requests for new effects subject to the relevant policy.

For a comparison with the manual workflow, run the same sequence with an engineer forwarding messages between dedicated sessions. Record the number of handoffs they perform, the amount of time they spend reconstructing the order and any messages that reach the wrong session. The comparison should use the same acceptance standard for both approaches. The engineer may identify a scope change faster than a model even while doing more manual routing. The system may consistently link a late CI result to its commit while failing to recognise the human reason for the stop. Both outcomes help locate the point where automation is earning its keep.

This test case illustrates a stronger measure than the number of workers online. It records whether the system preserved causality, honoured authority and avoided repeated side effects while a real team could still recognise what happened. A coordination system should pass the untidy sequence as well as the clean request. The difficult events in this trial are deliberately ordinary. Corrections arrive late, tests refer to old revisions and people change their minds. Those are the conditions under which a durable work record has to justify its place.

The boundary that will decide whether it lasts

The broadest version of the Super-agent idea would give people one collaborator that can follow several independent pieces of work, remain present across channels and pick up a job when the necessary environment returns. The published prototype implements a modest subset. That subset is large enough to expose several decisions the broader proposal depends on. Work needs an identity, a source of authority, a current owner and a way to return evidence to people. The value of the release is that those decisions are visible in code and documentation instead of being buried in a demonstration.

One open problem is scale. A single router can retain continuity within the team’s work while it processes an arrival stream it can keep up with. A larger team may need several routers or several filtering tiers. The design essay recognises the trade between throughput and context continuity when splitting the router’s work. A partition determines which decisions can be made locally and which need a handoff. If two routers see the same external event and both believe they own it, concurrency creates duplicate work. If neither owns it, the event can quietly disappear into a gap between responsibilities.

An organisation might start by partitioning on repository identity because the source already supplies it. A cross-repository change would then need an explicit relationship between work items. This is more legible than sending every repository event to a global model and hoping it remembers the right boundary. Cross-partition coordination should name the owner of the shared decision. A migration that touches several projects still needs a decision about order and validation. The central challenge is to share enough context to make that decision while preserving ownership and access limits at each repository.

Direct worker communication is another open choice. The design essay describes a simple arrangement in which workers generally advance their own tasks and can receive shared events when they follow the same thread. A tightly coupled project might benefit from faster negotiation between workers. It might also suffer from repeated or contradictory messages that bypass the ordinary coordination record. Adding a communication channel changes the state a person must understand during a fault. It is useful only if the messages carry provenance, distinguish advice from instruction and preserve a trace of decisions that affect the work.

The hard question about memory is not merely the length of the stored history. Suppose a team changed its style guide, retired a dependency and reassigned code ownership during a year of continuous operation. A retrieved discussion could be perfectly accurate about the earlier system and wrong as guidance today. Long-term recall needs an account of which decisions remain in force. An archive can tell an agent what someone said. The system also needs a way to show whether that statement was accepted, superseded or made irrelevant by a later change. The essay identifies longer-term memory as unresolved, and this distinction explains part of the difficulty.

The same issue appears in team handovers. A developer leaves a project, and an agent can still retrieve their old recommendations. Some may explain why an interface looks the way it does. Others may have been tentative and should never shape a future patch. The origin and status of remembered information are as important as its content. A versioned policy can answer certain authority questions. Technical history may require references to a decision record, accepted pull request or current document. Saving more text will not by itself preserve the difference.

Another unresolved boundary is the point at which a worker should ask a person. The published philosophy says the agent should stop for decisions whose impact exceeds the job. In a team, the identity of the person who can answer may vary with the question. An infrastructure owner can decide how a test service is used, while a product owner may decide what behaviour clients should see. Escalation needs a map of responsibilities as well as a signal that the model is uncertain. Without that map, an agent can accurately identify a blocker and still interrupt the wrong people.

There is also an economic boundary between local deployment and a more managed service. A local research bundle makes its code inspectable and lets a team experiment with its own rules. A larger shared service would need clear agreements about uptime, data retention, identity, operator access and recovery. The obligations grow when a prototype becomes part of how several teams accept work. The research release can demonstrate the routing design. A production deployment calls for separate evidence about those operating obligations.

One productive way to read the wider proposal is to look at the decisions it makes explicit. It gives sources a role in supplying provenance. It assigns a persistent record to each job. It allows direct delivery when a relationship already exists. It treats background work as capable of receiving new information. It considers how computation and execution could be replaced independently. Each of these decisions admits its own tests. None depends on a claim that a model has become a reliable general-purpose manager.

The deeper change is in what teams will expect to inspect. In an ordinary chat session, a user can look up what was asked and read what came back. In a persistent system, a supervisor also needs to know why an event was treated as a request, which rule allowed it and what changed while the worker was acting. The route from a message to an external action becomes part of the product. If that route cannot be reconstructed, the team has traded the inconvenience of switching windows for a loss of visibility into its own work.

This is why the proof of the architecture will be in its ordinary cases. A reviewer posts a correction and the right worker receives it. A bot reads a related thread without adopting instructions from it. A maintainer stops a job and can see the status of an already created branch. A worker reports a failed test honestly and leaves enough evidence for another person to continue. Those are small, verifiable acts of coordination. They are the results a team can count against the time it used to spend carrying messages between sessions.

A capable model still matters. An agent can route a task impeccably and fail to understand its code. It can produce a useful diagnosis and misunderstand what evidence the reviewer needs. But the coordination system can make those failures easier to locate and repair. Good orchestration gives errors an address. It can show which event was admitted, which worker acted and which step needs human judgement. That is a more durable contribution than the promise of a model that simply makes fewer mistakes in the next demonstration.

Return to the developer facing the broken import, the checkout investigation and the review comment. The best outcome is prosaic. The review comment reaches the worker that owns the patch. The checkout investigation continues undisturbed. The import report starts only the work the team authorised. The developer sees a result in the place where it can be checked and a question only when a decision is needed. DeepSeek’s bet is that this ordinary sequence can become a property of the system. The work worth preserving is the clear chain from request to authority to evidence, even when the worker, the machine and the conversation have all changed.

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

DeepSeek开源Super-agent，AI开始自己给AI派活，Agent竞争有了新方向
The originating news report on the coordination problem, DeepSeek’s prototype release and the preliminary scheduling comparison.

Super-agent 设计探索：迈向更自主的 Agent 系统
A Chinese republication of the design essay that describes the Router and Worker layers, event routing, context retrieval, remote execution, the Watchdog and the experiments.

Exploring DeepSeek Super Agent Design
Offloop’s English translation of the design essay with diagrams, examples and reported experiments.

DeepSeek Super Agent Explained: What It Is, How It Works, and Why It Matters
Technical commentary distinguishing the essay from the public implementation and transcribing all four scheduling results.

DeepSeek 提出 Super-agent 架构设计：Router 与 Worker 双层架构，探索更自主的 Agent 系统
Chinese reporting on the architecture, asynchronous interaction and the preliminary routing and batching experiments.

dsh-superagent
DeepSeek’s repository defines the public release as a research prototype and states its single-repository scope, optional Feishu connection and MIT licence.

000 Philosophy
DeepSeek’s operator guidance on attention, observed inferred work, restrained communication and escalation.

001 Domain model
The prototype’s definitions and lifecycle rules for sources, triggers, threads, evaluations, mandates, tickets and assignments.

002 Authorization
The project’s admission rules, follow-up ownership, context-only subscriptions, policy and hand-back behaviour.

003 Execution
DeepSeek’s documentation on preparation, concurrency, assignment recovery, input delivery and retry.

004 Prompts
The project’s explanation of role-specific instructions, Trigger cards, policy text, prompt overrides and code-enforced controls.

005 Panel
The public supervisor interface and its views of source health, decisions, ticket ownership and execution state.

006 Deployment
Primary documentation on accounts, role-specific model settings, the local host environment and the managed presets’ access limits.

007 Architecture
The implementation map for the Engine, application ports, transactions, Outbox, state and adapters.

008 Cookbook
The project’s connector example and guidance on mapping persistent event, thread, actor and reply identifiers.

DeepSeek Harness Architecture
DeepSeek’s account of the underlying harness, including its model, tool, session and plugin composition.

git-worktree
Git’s reference on linked worktrees, distinct checkouts and their relationship to shared repository state.

About protected branches
GitHub’s documentation on required reviews, status checks, branch restrictions and policy bypass settings.

Making retries safe with idempotent APIs
An engineering account of caller-provided request identities and the need to preserve intent when retrying operations with side effects.

ReAct: Synergizing Reasoning and Acting in Language Models
The paper introducing an approach that interleaves model reasoning and actions, used here to explain the underlying loop.

LLM01:2025 Prompt Injection
OWASP’s treatment of direct and indirect instructions that can alter a model’s behaviour through its inputs.

LLM06:2025 Excessive Agency
OWASP’s discussion of damaging actions enabled by excessive functionality, permissions or autonomy.

Building effective agents
Anthropic’s engineering guide to workflows, agents and the orchestrator-worker decomposition pattern.

How we built our multi-agent research system
Anthropic’s account of a lead agent dispatching parallel research tasks and bringing the findings together.

Scaling Managed Agents: Decoupling the brain from the hands
Anthropic’s explanation of its separate session, harness and sandbox interfaces and on-demand execution environments.

Why Do Multi-Agent LLM Systems Fail?
The paper supplying a taxonomy of failures in multi-agent system design, coordination and verification.

This article was prepared with the assistance of artificial intelligence tools. The content underwent expert human review, and Webiano Digital & Marketing Agency assumes editorial responsibility for its final version and publication.