DeepSeek open-sourced a Router-and-Worker coding agent, and the docs warn you first 🤖

Most coding agents still feel like one chat window with tools bolted on. You start a task, the context fills up, and when you want two jobs at once you open a second session and hope you remember which is which. This week DeepSeek published something different: a research prototype that splits the work into one resident coordinator and many isolated workers. The repo is deepseek-ai/dsh-superagent-prototype, it's MIT-licensed, and the README is refreshingly honest about what it is and what it isn't.

What shipped

The package is a bundle for DeepSeek Harness, DeepSeek's open agent runtime. It watches one GitHub repository and, optionally, Feishu chat. When someone on an allowlist asks for work, it opens a work item, runs that job in its own agent session and directory, and answers back in the original conversation, for example with a pull request. A small web panel shows only what still needs a person.

DeepSeek calls it a research prototype for reference only, not an official product. The code grew out of the team's day-to-day work, much of it written by coding agents, and the published version is not identical to their internal one. Some ideas in the design article are future directions, not features in this release. I like that framing a lot more than a splashy "agent 2.0" launch.

The design idea I care about

In the accompanying design write-up, DeepSeek frames the system as a Super-agent with two layers. One resident session talks to people and decides who does what. Separate worker sessions get isolated context and full tools, do one job each, and report back instead of chatting with humans directly. In the published code that maps onto a main session that evaluates triggers and an executor that runs assignments.

A few choices stand out for anyone building agents:

  • Events, not endless prompts. GitHub notifications, CI results and chat messages arrive as triggers. Code filters most of them first, for example with sender allowlists, before a model judges what remains.
  • Subscriptions. Once a worker owns a thread such as a pull request, later events on that thread go straight to that worker.
  • Attention as a scarce resource. The philosophy doc puts it cleanly: take as little human attention as possible, and give as much value as possible. The agent acts only when asked, or when a written team rule allows it. Unsolicited work starts in a mode that only records what it would have done.

Why this is useful, with eyes open

For builders, the useful part is the written reasoning. It names problems many of us hit in practice: mixed context, noisy event streams, and agents that burn a whole team's attention. The docs also warn hard. By default the presets run with full operator access, so a worker can run programs and read the operator's home directory. The deployment guide says to use a dedicated OS account and the agent's own GitHub user, not a GitHub App. That honesty is a feature.

As of writing, the repo has tens of thousands of stars, which tells you the community was hungry for an open harness design, not only another model. If you build agents for real repos, read the philosophy and execution docs before you clone anything into a machine you care about.

Sources

Would you rather one resident coordinator, or keep juggling separate agent chats yourself?

Reacties

Een reactie posten

Populaire posts van deze blog

Meta just shared the full recipe for a 30B agent model you can run at home 🧠

When Meta released Muse Glimmer in August, the pitch was simple: an open-weight, Apache 2.0 model built for AI agents that run on your own Mac or PC. What was missing was the "how". On 19 October, Meta Superintelligence Labs published the full technical report, and for anyone who cares about distillation and local agents, it is one of the most useful reads in a while. What the model is Muse Glimmer is a dense model of about 29.6 billion parameters, including a 1.8B perception encoder, so it reads text and images and writes text. It has a 128K+ context window and was trained on data from more than a hundred languages. The design goal was strict: everything has to fit in 32 GB of GPU memory, and a smaller 4-bit variant targets 24 GB cards. The parts I found most interesting Dense beat mixture-of-experts here. That surprised me. The team trained scaling ladders for a dense model and two MoE designs with the same memory footprint. Under a fixed memory ceiling and their compu...
Meer lezen

AI that can actually "see" a crystal 🔬

Most of the solid stuff around us, from battery materials to chips, is made of crystals: atoms stacked in neat, repeating 3D patterns. Large language models are great at reading papers about those materials, but they have never really looked at the structures themselves. A team at MIT just showed a clever way around that, and the trick is one I keep coming back to: good synthetic data. What they built The model is called CLaC, short for Contrastive Language-Crystal model, and it is described in a paper in Nature Communications by Yang Jeong Park, Mayank Kumaran, Chia-Wei Hsu, Elsa Olivetti and Ju Li. MIT News covered it on 18 October 2026. If you know CLIP, the model that taught image generators to connect pictures and words, you already get the idea. CLaC has two branches: a graph neural network that reads the 3D crystal structure, and a text encoder that reads a description. Contrastive training pulls matching structure-text pairs together in one shared space and pushes mismatche...
Meer lezen

A 35B model on a Mac mini, using just 2.9 GiB of memory 🚀

There's something special about running a capable language model on hardware you own: no API bill, no data leaving the house, just a small box on your desk doing the thinking. A paper that's currently #2 on Hugging Face's trending list takes that idea further than I expected: it runs a 35-billion-parameter model on a Mac mini at about 20 tokens per second while using under 3 GiB of memory. The trick: leave the experts on the SSD The paper is called The Other Half of the Memory Wall: Serving 35B MoEs from SSD with Trained Routing Prediction , and the system is named Edge0 . It builds on a Mixture-of-Experts (MoE) model, Qwen3.6-35B-A3B. In an MoE, each token only uses a few "experts" per layer (here 4 out of 256 in each of 40 layers), so most of the weights sit idle at any given moment. Edge0 takes that literally. The expert weights (quantized to int4) stay on the SSD and are streamed in only when needed. The clever part is a small prerouter : a tiny trained he...
Meer lezen