7thWardMadeMe

I've already read this three times today no exaggeration, it's one of the most valuable articles I've read on building agents this is how DeepSeek runs their fully autonomous AI agent setup, and you can apply almost all of it to your own their starting point is that the bottleneck has moved, in their words "a single task is limited by model capability, but multi-tasking is limited by human attention", and they say a person can usually follow only 3 to 5 active sessions at once so this is what they do: 1. split the agent into two layers a router that talks to you and hands out tasks, and workers that do the work the router "only interacts with humans and dispatches tasks, and it can run without a Bash tool at all", so they say "a lighter model can usually provide both speed and quality" each worker gets one task, an isolated context, a full set of tools and the most capable model, and it reports back to the router instead of messaging you their take on sessions: "Sessions should be an implementation detail of the system, not a mental burden on its users" 2. let the router batch work when things get busy events that arrive while the router is thinking get queued and handled together in its next turn when they pushed it from about 1 to 40 events a minute, time per request only went from 2.5s to 3.9s, and the time per decision dropped from 6.4s to 1.6s so one router session was enough for their whole team, no need to split it up early 3. filter events with code before any model sees them they borrow the "Fast Path / Slow Path" idea from computer systems fast path is plain code checking the source, the group, and user or bot allowlists, with each source set to "respond only to explicit requests", "treat as candidate events", or "ignore" slow path is the LLM, which only sees what's left and judges it against policies written as prompts, so you can add or turn off a rule by editing a prompt 4. send follow-ups straight to the worker that owns them consecutive events on the same PR, chat topic or email chain form what they call a Thread the first event goes through the router, which creates a worker that subscribes to that Thread, and every follow-up skips the router and goes straight to that worker two workers on the same PR both get the same events, so they can spot conflicts without talking to each other without this, their router made about 30% more decisions and total tokens went from 23.2M to 31.8M per run 5. treat the context window like a cache "Wasting the context window is wasting the model's intelligence" they call it Inline & Spill: start with just an object's ID and a summary, then inline what it'll likely need soon, like the first 50 characters, the messages around it, and the message it replied to anything too long gets truncated with a pointer, so the model can read the rest only when it needs it every object carries the IDs of related ones, so the model can follow them hop by hop to dig up old context, which they call Chain of Recall 6. make slow tools async in a normal loop, a long tool call blocks everything until it finishes they swap that for start() and stop(), where "a call to start() returns "Started" immediately" and the result shows up later as a new event so new messages get handled "as soon as the current inference step ends, rather than after background tools finish" DeepSeek Harness already has this, it's just not on by default yet 7. match the channel in group chats the agent should "notify people only when a decision or sign-off is needed, ask only direct questions, and give short conclusions" and their one hard rule: "a cap of 100 words per reply" on GitHub and email it does the opposite, full structured writeups, like a PR with the problem background, the change description and the verification results 8. keep the agent loop in the cloud and your machine as a tool "The compute that runs the Agent Loop can be stateless, and only the session state has to persist" so the loop runs in cloud containers, sessions live in a database, and your computer just runs a lightweight daemon that "does nothing but execute commands and return results" your laptop going to sleep doesn't stop the agent, and when it reconnects the agent picks up the tasks that needed it 9. run a watchdog session on a schedule "Many anomalies are not crashes: the process is still running, but the model is stuck in an unproductive loop or has drifted from its goal" so a separate watchdog session checks whether each worker is making real progress, fixes failures, and keeps retrying until they're resolved and since it's an agent too, you can ask it in plain English why something failed 10. do the work before anyone asks they run a "silently reproduce and fix" policy in their own team chat when someone reports an issue, the agent tries to reproduce it and find a fix in the background, and "it delivers a result only after it has confirmed the issue and found a simple fix. Otherwise, it stays quiet the whole time" 11. don't count on prompts to make it delegate with a neutral prompt, a single session never handed work to a subagent once in 5 runs with a delegation-first prompt it delegated in 4 of 5, and in the last run it decided the work was "small" and did it itself so the delegation has to be built into the architecture, not left to the model's judgment 12. what they haven't solved yet an always-on agent reads a lot of untrusted input, and if a prompt injection compromises the cloud loop, every device connected to it is exposed their conclusion: "The agent therefore needs a way to use credentials without ever seeing them" in their test, the full setup finished tasks in 12.4 minutes at p50 vs 20.4 for a single session with subagents