{
  "id": 5416905,
  "title": "Subagents design @ zerostack",
  "url": "https://urgent.news/2026/09/03/subagents-design-zerostack",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-03T21:10:24.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/gi-dellav/subagents-design-zerostack-16e7"
  },
  "original_language": "en",
  "account": "The @zerostack architecture features subagents, which are parallel, read-only child agents designed to work with simple text input-output contexts. When an agent needs to understand a codebase, it must choose between probing files one by one (slow and token-intensive) or dumping everything into context (impossible for large projects). To address this, subagents were developed, adhering to the UNIX-like minimal philosophy of zerostack.\n\nSubagents are read-only child agents spawned by the main agent through a task tool. Each subagent is given a precise technical question and returns a focused answer. Multiple prompts can be given, and they run in parallel via tokio::spawn. The main agent and subagents communicate via task tool calls, with each subagent running with permission: None for safety, as they can only read.\n\nKey constraints include being read-only, having no write, edit, bash, memory_write, or mcp_tool capabilities, being an opt-in feature gated behind a Cargo feature, and ensuring no dangerous actions or race conditions occur between subagents. Parallel execution is achieved by spawning a separate async task for each prompt passed to the task tool, with results ordered by the original prompt index. If a subagent fails (panic or error), its error is displayed to the agent, allowing for re-sending the subagent or completing the task with other tools.\n\nSubagents are treated by main agents as subordinates that receive high-level questions and provide low-level answers. They are not used for listing directories, grepping one pattern, reading known files, or any single-step operation. Instead, they should be used when a task requires searching through 3+ distinct files and cross-referencing their contents. If a subagent has already been run and results were obtained, those results should be used instead of re-spawning the subagent.\n\nIn the system prompt, subagents are described as being used for multi-step read-only investigations, with only one turn spawning 3-5 parallel investigations. Each subagent has read, grep, find_files, list_dir, and memory access capabilities and returns structured findings. Subagents enable the main agent to delegate deep exploration without context bloat, automatically receiving architecture context for design awareness. This approach results in a 25% gain in code exploration time. The implementation is simple, with only 414 lines of Rust code.",
  "summary": "tldr Subagents architecture made of parallel read-only child agents with simple text input-output context zerostack is my lightweight CLI coding agent; give it a try! The problem When an agent needs to understand a codebase, it has two choices: start probing files one by one (slow, burns tokens) or dump everything into context (impossible for large projects). Either way, the main agent's context…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}