{
  "id": 17073724,
  "title": "I Planned a Multi-Agent Coding System. Here Are the 7 Decisions That Matter",
  "url": "https://urgent.news/2026/10/29/i-planned-a-multi-agent-coding-system-here-are-the-7-decisions-that",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-29T14:44:58.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/apex97/i-planned-a-multi-agent-coding-system-here-are-the-7-decisions-that-matter-38kp"
  },
  "original_language": "en",
  "account": "At Zyntari, I am developing a multi-agent coding system that enables several AI coding agents to collaborate on real software projects. Before writing any code, I create a comprehensive technical specification outlining every architectural decision, tradeoffs, and intentional omissions. This spec serves as a blueprint for anyone attempting to manage multiple coding agents working on practical projects. I am sharing the seven most crucial decisions that underpin this system and the rationale behind them.\n\nDecision 1: A state machine governs the system, not a conversation. Unlike many other agent systems that function as a chat that remembers previous interactions, our system maintains task state in PostgreSQL. Agents can only request changes to this state, and transitions between explicit states (proposed, planned, running, awaiting_review, merging, completed) occur through a single pure function that returns the new state along with any emitted events. This ensures that no agent or human can alter the state directly in the database. Once an agent has completed its task, it must return a validated structured output indicating its status, summary, commit SHA, changed files, and acceptance criteria. The system does not accept incomplete tasks.\n\nDecision 2: Durability and determinism are non-negotiable. Unlike typical web requests, agent runs can last for extended periods, waiting for human approvals or even surviving server crashes. To ensure reliability, we utilize Temporal, a workflow engine specifically designed for such long-running tasks. Temporal enforces the rule that all workflow code must be deterministic, as it replays the code from history after failures. This means no live data access, random IDs, or non-deterministic functions within the workflow code. Instead, any side effects are handled through Activities, which are recorded and can be replayed from history should a failure occur. This approach guarantees that the system can recover seamlessly from crashes.\n\nDecision 3: Agents should be driven by an SDK, not terminal keystrokes. Running coding agents in a terminal and scripting keystrokes is not a viable long-term solution. It lacks structured events, reliable cost data, and the ability to resume sessions after crashes. Instead, we leverage the Claude Agent SDK, which provides a programmable agent loop in TypeScript and Python. This SDK allows us to interact with Claude Code programmatically, accessing features such as messages, session IDs, tool permissions, hooks, budget limits, and structured output. Every run is assigned a unique session ID, enabling the system to resume a crashed run without restarting it. We also enforce policy checks in the host process to ensure that model context cannot be manipulated or ignored by prompts.\n\nDecision 4: Each task operates within its own Git worktree, protected by a sandboxed worker environment. To prevent conflicts, we assign a unique Git worktree to each implementation task. The system enforces a conservative write set, including only the paths owned by the task and any files those paths might affect, such as lockfiles and shared configurations. Tasks with overlapping write sets are prevented from running concurrently. When tasks modify shared resources like lockfiles or perform database migrations, they must acquire a repository-wide lock to avoid disrupting other in-progress work. To enhance security, we run each worker process in a Linux sandbox, using rootless Docker, a non-root user, and strict network and seccomp profiles that limit the worker's capabilities to only what is strictly necessary.\n\nDecision 5: The scheduler operates as a deterministic algorithm, not an arbitrary mood. Managing multiple tasks and a limited number of agents requires an efficient scheduling mechanism. Rather than leaving this responsibility to the whims of an agent, we employ a deterministic algorithm to select the next task. The task graph is validated deterministically, ensuring that all dependencies are met and that no cycles exist. Each objective is mapped to an acceptance criterion, and priority is assigned using a weighted formula that considers business priority, critical path dependencies, wait time, and expected cost. Agents can classify tasks based on attributes like security sensitivity. This algorithmic approach ensures that scheduling decisions are transparent, predictable, and free from subjective biases.",
  "summary": "At Zyntari, my engineering studio in Israel, I am building a system where multiple AI coding agents work on real software projects: taking tasks, writing code, running tests, opening pull requests, and waiting for approvals. Before writing code, I wrote a full technical specification with every architecture decision, every tradeoff, and every thing we deliberately will not build. A spec is…",
  "key_points": [
    "A state machine governs the system, not a conversation",
    "Durability and determinism are non-negotiable requirements",
    "Agents are driven by an SDK, not terminal keystrokes"
  ],
  "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."
}