Right now, if you use Claude Code, Cursor, or OpenCode to fix an isolated bug or add an API endpoint, the output is usually solid. What really wears you down is juggling several small development tasks at the same time. One moment you switch to the first window to check whether the test suite passed, the next you copy an error screenshot a teammate posted in a Feishu chat and paste it into the second window, and then you spin up a separate branch in the third window so the two tasks do not overwrite each other’s files. Writing code takes less effort than before, yet you end up working as a full-time dispatcher.
The real bottleneck in day-to-day development has shifted from writing a piece of code to acting as a project manager for a fleet of parallel agent windows. That is a completely different problem from what we explored in late October in What Multi-Agent Teams Actually Buy You. That piece examined how to break down one massive, complex problem that a single agent cannot solve alone and hand it to several agents working together. Engineering teams face the opposite headache every day: any single agent can finish each small task on its own, but dozens of unrelated chores keep pouring in alongside everyday group chat discussions. Watching windows, creating branches, relaying context, and checking progress by hand quickly drains human attention.
On October 31, the DeepSeek team open-sourced their internal always-on agent research prototype and published a companion design post. According to their internal tally, while building their own agent framework, over 90% of the PRs were submitted either independently by this system or in collaboration with engineers. Their setup assigns a full-time online project manager to a repository. The project manager sits in Feishu group chats and GitHub listening to messages, opens a ticket whenever a request comes in, assigns a background subagent to edit code and run tests in an isolated directory, and reports back to the group once the job is done. Yet when you read through the design post and its 30,000 lines of source code, a strong last-generation engineering mindset jumps out at you: every time the model does something foolish, engineers write another state machine and database table to patch around the AI. The multi-window coordination tax and group-chat chaos it targets are real pain points, but piling patch on top of patch makes the solution far too heavy.
Let us start with a thought experiment. Imagine you are the only human in a Feishu group chat, with no teammates chatting or interrupting, and you only assign tasks to a single repository. In that one-on-one setting, why not just run a main window that can spawn subagents? Why did DeepSeek insist on splitting the project manager and background subagents into two separate layers?
DeepSeek ran a controlled comparison in their post to explain why. A script fed the system hundreds of messages mixing everyday chatter and CI notifications, with 20 coding tasks tucked inside, to measure scheduling and response latency. When they ran a single standard session without special instructions, the model never called a subagent once. Every task queued up inside the main window, and the slowest one took 29.5 minutes to finish.
When they tightened the prompt to strictly instruct the model to delegate to subagents first and only do small things itself, it delegated properly most of the time, cutting the median completion time by more than half. Yet in 1 out of 5 runs, the model decided a task looked small enough to handle on its own, freezing the chat window on the spot and sending tail latency right back to 29.0 minutes.
To cure this habit, DeepSeek stripped all coding tools away from the project manager so it could only dispatch tickets. Because both the project manager and the background subagents had to read context, cache token reads jumped by 3.8x, but tail completion time stayed reliably down at 15.7 minutes. From this, the team concluded that prompts alone cannot restrain a model’s hands, so you have to strip its tools in code.
That conclusion is only half right. Look back at the exact wording of their prompt: it explicitly told the model to only do small things itself. If you leave a loophole in your own rules inviting the model to judge what counts as a small task, you cannot blame it for walking through that door. The deeper reason is the gap in instruction-following across lead models. As Cohere showed in its cross-model benchmarks, older or mid-tier models sitting in the lead seat struggle to resist writing code themselves, whereas newer frontier models delegate reliably.
In our day-to-day use of the public Principal Investigator and Coordinator workflow, the main thread runs on the frontier model GPT-6 Astra. The rule draws a single clear line: even if the main thread already holds the relevant context in memory, that is never an excuse to write code itself, and every long-running task must be delegated to a background subagent. Once you close that loophole and remove any permission to do small tasks on the side, Astra acts as a steady project manager without ever freezing the conversation.
Inside DeepSeek, the team naturally had to use their own model as the project manager. To cope with their model’s occasional urge to jump in and write code, the engineers built a physical cage to enforce discipline: the project manager only mounts read-only and dispatch tools, dispatch notes are capped at 30 words so it cannot write implementation plans for subagents, foreground commands running longer than 5 seconds are forced into the background, and an extra priority concurrency slot is reserved specifically for human follow-ups even when background slots are full. If you run a frontier model as your project manager in a personal terminal, you do not need to copy this physical lockdown; it is a workaround for a weak lead model that cannot keep its hands off the keyboard in a one-on-one session.
If all you need is to stop a model from coding in a single-user window, switching to a disciplined frontier model with a few lines of rules solves the problem. Moving that project manager from a 1-person terminal into a 20-person Feishu group and shared GitHub repository, however, brings three genuine headaches. As we noted in early September when discussing the interaction dilemma of group-chat rooms, a human can skim past side chatter in a group at zero mental cost, whereas an agent has to load the entire session’s context cache into memory even if it decides to ignore a message. Once several tickets are moving forward in the group at the same time, follow-up replies repeatedly wake up the main window and burn money, casual comments from teammates in a thread can easily trigger out-of-scope edits, and an eager bot chiming in on everyday conversations will annoy everyone in the room.
For the first problem, DeepSeek made the one architectural change that genuinely belongs in code: routing follow-up messages around the project manager straight to the background. Once the project manager creates a ticket, the system binds the original Feishu thread and the corresponding PR to that ticket. From then on, whenever someone adds a comment under that thread or PR, or whenever CI fails, the system delivers the event directly into the background subagent’s inbox without waking the project manager. In their comparison tests, this shortcut saved the project manager roughly 30% of its wake-ups and 27% of its cache reads. That layer of plumbing is indispensable, because every wake-up that forces the project manager to re-read the group context cache is a literal token bill that no amount of model intelligence can waive.
When tackling the other two headaches, however, the engineering team fell right back into piling on heavy patches. To stop teammates from sneaking extra work into comment threads, the system issues an immutable mandate the moment a ticket is created, locking in both the exact scope of code the subagent is allowed to touch and a version hash of the permission allowlist at creation time. Group comments delivered to the subagent’s inbox count only as reference context, never as authorization to expand the job. If someone casually asks to refactor the login API inside a thread about fixing a button color, the subagent must call a dedicated tool to hand the message back to the project manager for a new ticket evaluation. Even if someone replies to a closed thread days later hoping to resume the task, the host first checks the allowlist version hash on the original mandate and blocks the wake-up on the spot if that person has since been removed from the allowlist.
To keep the bot from interrupting everyday group chatter, they built an equally rigid admission and interception pipeline. The system first filters out messages from anyone outside the allowlist, then requires the model to verify three conditions for any unmentioned group message: the speaker is explicitly asking for a change to this repository, the target state is clearly specified, and no unresolved product or design trade-offs remain. If there is the slightest ambiguity, the iron rule is to stay silent rather than ask a clarifying question. Worried that the bot might still speak out of turn when first added to a group, they set its default proactive mode to observe: the project manager still runs its evaluation in the background, but hard-coded logic intercepts the ticket creation at the final step and merely logs a database entry noting that it would have accepted the task.
To be fair, the boundary problems they identified are spot on: a casual group-chat reply should never act as a blank check to rewrite code, and when an unmentioned request is vague, staying quiet is far better than pestering humans with follow-up questions. Yet their implementation reflects a classic last-generation software engineering reflex. Because they do not trust the model’s judgment, every potential boundary violation is met with a new SQLite table, a policy version hash, hard-coded state transitions, and code-level interceptors. Today, when your foundation runs on a frontier model with strong instruction-following, rules like sticking strictly to the current ticket’s scope, asking teammates to open a new ticket for extra requests, and staying silent whenever an unmentioned message is ambiguous can be enforced with a few clear lines of natural-language instructions in a rules file. Writing thousands of lines of state-machine code to patch over a model’s comprehension turns all of those heavy guardrails into technical debt the moment the next model generation arrives.
Once you recognize this patch-stacking mindset and compare the open-source repo against the official design post and outside coverage, it becomes easy to separate what actually works in production from distant blueprints that only exist on paper. For instance, the design post sketches out a decoupled architecture pairing stateless cloud containers with a lightweight daemon on the user’s own machine, along with an independent watchdog session that diagnoses reasoning loops in subagents. If you search the open-source repository, not a single line of code has been written for either feature.
The actual runtime environment behind this system is remarkably bare-bones: a single tmux session on one machine, a local append-only SQLite file holding all state, and an hourly cron script checking whether the process is still alive. While the design post claims that background subagents never speak directly to the outside world, the source code shows subagents sending initial acknowledgment messages and replying directly to review comments on GitHub PRs. Both the project manager and the background subagents run with the operator’s full local OS permissions without a sandbox, and the widely cited 90% PR figure is an internal self-reported metric that outsiders cannot independently verify from a single-commit open-source repository.
Precisely because the underlying setup is little more than a single-machine script that survived daily team use through layers of patches, it reveals a deeper truth: keeping an always-on agent alive inside an engineering team does not depend on futuristic cloud containers or 30,000 lines of state-machine code. It depends on the design philosophy stated on the very first page of their docs: consume as little human attention as possible. Today, we do not need to deploy their heavy state-machine foundation at all. We only need a thin message-routing layer plus the four attention-saving rules they discovered the hard way, copied straight into our own lightweight agent instructions.
First, cap group-chat notifications at 100 words, defaulting to a single sentence that delivers the outcome and PR link, and strictly forbid reporting which library was chosen, which files were touched, or how many tests ran. Second, put a circuit breaker on bot-to-bot chatter: respond to automated review bots on a GitHub PR for at most 3 rounds, and resolve fixed review threads silently instead of replying “Fixed” and generating notification noise.
Third, yield immediately when colliding with human work: if a background subagent discovers that a teammate has already pushed a branch or opened a PR addressing the same issue, it closes its own competing PR right away rather than racing a human. Fourth, guard the auto-merge line: allow auto-merge only when total changes are under 200 lines and the latest commit has collected every required human approval. Last-generation engineering writes code and state machines to patch over model weaknesses; this generation keeps the system foundation thin and distills the management boundaries that actually matter into a few clear rules.