# Eve Agents: Why Twelve Specialists Beat One God-Agent > I built a fleet of twelve agents instead of one that does everything. Not because twelve is better at the work — because when one of them breaks, I know which one. Here's the roster and the reasoning. > > Published: 2026.07.28 · 14 min · AI, AGENTS, EVE, ARCHITECTURE, GUIDE > Canonical: https://cyperx.dev/blog/eve-agents-fleet-model --- Everyone's first agent is a god-agent. You give it bash. You give it web search. You give it file reads and writes and a Discord channel and a GitHub token, and then you write a two-thousand-word system prompt explaining all the different jobs it does and when it should do which one. It kind of works. It works well enough that you keep adding to it. Then one Tuesday it posts a half-finished draft to a public channel while trying to answer a question about your database, and you spend the afternoon reading a 40k-token transcript trying to work out which sentence in your prompt it decided to follow. I built twelve agents instead. This is the reasoning, the roster, and the honest cost. ![One overloaded god-agent holding every tool versus a narrow root agent delegating to small specialists](/images/blog/eve-fleet-hero.svg) ## The series Five parts, beginner to advanced. Each one stands alone, but they stack: 1. **The fleet model** — why twelve specialists beat one god-agent *(you are here)* 2. [Anatomy of one Eve agent](/blog/eve-agents-anatomy) — the five files, and building your first 3. [Root lockdown and forced fan-out](/blog/eve-agents-root-lockdown) — deleting tools as an architecture 4. [Eval-gating](/blog/eve-agents-eval-gating) — a judge subagent and a typed verdict 5. [The orchestrator capstone](/blog/eve-agents-orchestrator-capstone) — composition, plus scoring the whole fleet ## What this is actually built on Quick grounding so the code snippets make sense. The fleet runs on [Eve](https://www.npmjs.com/package/eve), a beta agent framework where an agent is a directory. Not a graph, not a YAML pipeline — a folder with a model file, a markdown instruction file, and a `tools/` directory of typed TypeScript functions. It builds to a Nitro server, has a real eval runner, and gets out of the way. I'm not selling you on Eve specifically. Every idea in this series ports to Claude Code subagents, the Agents SDK, LangGraph, whatever you're already using. The framework is the least interesting part. What matters is the shape. Models come through OpenRouter — mostly `deepseek/deepseek-v4-pro`, with `kimi-k2.7-code` on the one agent that writes real code. That's a config fact, not a religious position; it'll be a different model next month. The whole thing lives at `~/github/eve-agents`, twelve sibling directories and a scorecard script at the root. That's the entire architecture. There is no central registry, no shared runtime, no `core/` package. Twelve folders. ## The god-agent problem, stated properly The argument against one big agent isn't "it's not smart enough." Models are smart enough. Frontier models will happily hold twelve jobs in their head and do a decent job at eleven of them. The problem is that you can't tell which one it's doing badly. Here's the concrete version. Say your do-everything agent has eighteen tools, and one of them posts GitHub comments. You change three lines of your prompt to fix how it summarises research. Now: did that change make it more or less likely to post something dumb to a public issue thread? You genuinely cannot answer that. Not "it's hard to answer" — there is no test you can run that answers it, because every behaviour is entangled with every other behaviour through one shared prompt and one shared toolbox. Your only feedback loop is production, and production means a real comment on a real repo. Three specific failures fall out of that, and I hit all three: **Blast radius is the whole system.** One bad turn can reach anything the agent can reach. If it can post *and* push *and* spend money, then any confusion at all is potentially expensive. The agent doesn't have to be malicious or broken — it just has to misread which job it's on. **Attribution is impossible.** When output quality drops, you're bisecting a prompt. Not code — prose. There's no `git bisect` for "the tone got worse." **Nothing is testable in isolation.** You can't write a test for "does it refuse to answer without an index" if the same agent also handles seven other tasks that legitimately answer without an index. The test has no clean boundary to sit on. Notice that none of these are about capability. They're all about *observability*. The god-agent isn't bad at the work. It's bad at telling you what it did. ## The fleet model So: one agent, one job, one toolbox, one eval suite. Each agent in the fleet is a separate directory with its own `package.json`, its own model config, its own instructions, and its own `evals/` suite. They don't import each other. They don't share a runtime. Vault Oracle knows nothing about Cost Sentinel, and that's the feature. The trade you're making is explicit: you give up cross-cutting cleverness and you buy back a *boundary*. A boundary is the thing you can put a test on. What that buys, concretely: - **A failure has an address.** "Triage Desk is red" is a sentence you can act on. "The agent is being weird" is not. - **The blast radius is one agent's tools.** Vault Oracle can read my notes and literally cannot post anything anywhere, because the tools to do that aren't in its directory. - **You can swap one out.** Rewrite Research Desk from scratch, and the other eleven don't know or care. - **Every one gets its own suite.** Twelve small eval suites you can actually keep green, instead of one giant one you gave up on. And the part I didn't expect going in: **each agent teaches you something you use in the next one.** That turned out to be the actual value. The fleet isn't twelve tools I use every day — some of them I've run twice. It's twelve lessons, built in order, each one small enough to hold in your head. ## The roster Twelve agents, numbered in build order. The number matters because each one exists to teach exactly one thing, and the ordering is the curriculum. ![The twelve-agent roster grid, each with the one lesson it teaches, ending with the orchestrator capstone](/images/blog/eve-fleet-roster.svg) **#1 Release Radar** — the smallest whole agent. Once a day it checks what moved in the AI coding tools I build with and posts a tight Discord digest. One read-only tool, one channel, one cron. *Lesson: an agent is a directory, and the smallest useful one is tiny.* ```ts // release-radar/agent/schedules/daily.ts import { defineSchedule } from "eve/schedules"; import discord from "../channels/discord"; // cron is evaluated in UTC. 08:00 Australia/Brisbane (UTC+10, no DST) = 22:00 UTC. export default defineSchedule({ cron: "0 22 * * *", async run({ receive, waitUntil, appAuth }) { waitUntil( receive(discord, { message: "Run your daily release check and post the digest.", target: { channelId: process.env.RADAR_CHANNEL_ID ?? "" }, auth: appAuth, }), ); }, }); ``` That's a scheduled autonomous agent. The whole scheduling layer. **#2 Sandbox Coder** — hand it a repo and a task; it clones into an isolated sandbox, edits, runs the build and tests, iterates, then opens a PR. Uses `kimi-k2.7-code` because it's the one agent doing real code work. *Lesson: isolate execution, and give the agent exactly one door out.* Its `open_pr` tool is the only thing that leaves the sandbox, and it's approval-gated. Rejected work never touches my real repos. **#3 Ghostwriter** — reads my actual git commits across repos and drafts build-in-public posts in my voice. *Lesson: ground the agent in real inputs and it stops inventing.* The eval is literally called `no-invented-work`. **#4 Research Desk** — decomposes a question, fans out parallel research subagents, synthesises a cited report. *Lesson: fan-out — and that asking for it doesn't work.* More on that in a second, because it's the best failure in the whole build. **#5 Triage Desk** — watches GitHub issues, clusters duplicates, delegates each cluster to a `triager` subagent that reproduces and drafts a reply. *Lesson: root lockdown.* The root has no outbound tools at all, and every reply goes through a human gate. **#6 Godot Nightly QA** — fans out one `playtester` subagent per scenario, each launching headless Godot, screenshotting, and diffing against a baseline. *Lesson: fan-out by workload, not by topic.* One subagent per scenario, one wave, no batching. **#7 Site Warden** — crawls my sites, runs Lighthouse, reports broken links and perf regressions. *Lesson: monitor-first.* It reports by default and only opens a PR for a mechanical fix. General refactors are Sandbox Coder's job, and keeping that line is the point. **#8 Eval Grader** — scores another agent's output against a named rubric and returns a typed verdict. Zero tools. *Lesson: a judge that can't investigate grades what it was actually given.* This is the one that unlocks the capstone. **#9 Project Manager** — conversational PM that reads my Obsidian project registry, sweeps the mapped repos for ground truth, and patches project notes on request. First *inbound* agent — I talk to it. *Lesson: durable multi-day memory instead of one-shot execution.* **#10 Vault Oracle** — RAG over my own notes, answers grounded only in retrieved chunks, cited by absolute path and heading. *Lesson: cite or shut up.* Every built-in file tool is disabled, so an answer physically cannot leak in from outside the retrieved context. **#11 Cost Sentinel** — watches spend on the OpenRouter key funding the fleet. *Lesson: the deterministic part shouldn't be an LLM.* A plain cron script does the math and exits 2 on an anomaly; the agent explains it and proposes a fix behind the hardest gate in the fleet. **#12 Fleet Orchestrator** — the capstone. Decomposes a goal, routes each part to a specialist, grades every result before accepting it, parks what never passes, synthesises a report. *Lesson: composition.* Nothing new — lessons 4, 5, and 8 wired together with a file that remembers. ## The failure that justified the whole thing Research Desk (#4) is the one I'd point at if you only wanted one story. The design was: root decomposes the question, fans out three to six `researcher` subagents in parallel, synthesises what comes back. I wrote instructions that said exactly that. Clear, numbered, unambiguous. First real run: it worked. Excellent cited report. And it had done **forty web searches directly from the root**, without spawning a single subagent. It had the search tools. Using them itself was easier than delegating. So it did. My instructions said "delegate" and the model read that as advice, weighed it against the path of least resistance, and quietly picked the other one. Here's the note I left in the README that day, unedited: ``` ## Finding (2026-07-18 first run) Works end-to-end and produces excellent cited reports — but with deepseek-v4-pro it researches DIRECTLY (40 searches) instead of fanning out to subagents. Subagent fan-out is model-dependent. Fix (v2): scope web_search/fetch_page to a declared agent/subagents/researcher/, give the root NO web tools → root is forced to delegate → fan-out guaranteed regardless of model. ``` The fix wasn't a better prompt. It was moving the tools into the subagent directory and leaving the root with nothing. Now the first line of its instructions can say something that's actually true: ```md You are Research Desk. You answer a question thoroughly by delegating parallel research to `researcher` subagents, then synthesising a cited report. You have no search tools of your own — you cannot look anything up yourself. Your only way to gather evidence is to delegate. So you must. ``` "You have no search tools of your own." That's not a rule, it's a fact about the world the agent lives in. It holds under a long context. It holds when the model changes. It holds at 2am. That's the thing the fleet model gives you that a god-agent structurally can't: **the ability to make a constraint true rather than requested.** In a single agent with every tool attached, "don't use bash for this task" can only ever be a sentence in a prompt. Part three of this series is entirely about that move. ## What it costs — the honest bit I'm not going to pretend this is free. **Twelve `package.json` files.** Twelve `node_modules`. Twelve times you upgrade the framework. It's real duplication and it's genuinely annoying, especially on a machine where disk is tight. **No shared context.** Vault Oracle can't see what Project Manager knows. If a task genuinely spans two agents, you're either wiring an integration or doing it by hand. **Fan-out costs tokens.** A root that delegates to three subagents pays for four model contexts, not one. Eval-gating on top of that means a grader call per artifact. The orchestrator running a three-part goal with one retry is easily eight model calls where a god-agent would've made two. That's a real bill. **Coordination is the hard part, and it's on you.** Nothing in this design solves "how do twelve agents work together." That's what agent #12 exists to attempt, and it's the least finished thing in the repo. Worth being straight about that last one. The orchestrator does *not* currently cross-invoke the other eleven deployments — that needs each agent's endpoint and auth wired in, and it's parked. It composes a subagent that *plays the role* of three specialists, which proves the composition shape without proving the integration. The README says so in a section titled "Live vs stubbed specialists (be honest about this)," and I'd rather ship that heading than a fake diagram. Would I do it as one agent if I were shipping a product to users tomorrow? For a narrow product, maybe. For a system I have to keep alive and keep changing for a year — no. The duplication is a cost I pay once per agent. The un-debuggability of a god-agent is a cost I pay every single time something goes wrong. ## The thing that makes it a fleet and not twelve hobby projects Twelve independent agents with twelve independent eval suites is only useful if you can ask one question across all of them. So there's one script at the root: ```bash ./scorecard.sh # score every agent that has an evals/ suite ./scorecard.sh site-warden # score one (or several) named agents ./scorecard.sh --diff old.json # compare a prior scorecard against a fresh run ``` It walks every directory with an `evals/` folder, runs `npx eve eval --json`, normalises each result into one row, and prints a table. Run it before a change, run it after, `--diff` the two. That delta is the only honest answer to "did that change make things better or worse." Here's a real run, not a mockup: ``` AGENT PASS FAIL SKIP ERR EXIT STATUS ---------------------------------------------------------- cost-sentinel 2 0 0 0 0 ✔ green eval-grader 2 0 0 0 0 ✔ green ghostwriter 1 0 0 0 0 ✔ green godot-qa 2 0 0 0 0 ✔ green orchestrator 0 0 0 0 1 ✖ no parseable --json output project-manager 2 0 0 0 0 ✔ green release-radar 0 1 0 0 1 ✖ RED research-desk 1 0 0 0 0 ✔ green sandbox-coder 1 0 0 0 0 ✔ green site-warden 1 0 0 0 0 ✔ green triage-desk 2 0 0 0 0 ✔ green vault-oracle 2 0 0 0 0 ✔ green ---------------------------------------------------------- TOTAL 16 1 RED: orchestrator, release-radar ``` Sixteen green, one red, one that didn't even emit parseable output — and that one's the capstone. Release Radar failed on `MODEL_CALL_FAILED`, which is an infrastructure problem, not a logic one, but red is red. I'm putting the real numbers in the post for the same reason I put them in the repo: a scorecard you only publish when it's all green isn't a scorecard, it's marketing. The number is useful precisely because it can be bad. Part five goes through the aggregator properly, including the one design decision I care about most in that file — the swap seam that means replacing Eve entirely doesn't break the tooling around it. ## The rule, if you take one thing **One agent, one lesson, one toolbox, one eval suite.** If you're staring at an agent that's grown eight tools and a thousand-line prompt, the move isn't a better prompt. Pick the one job it does that has a different *risk profile* from the rest — the one that posts, or pushes, or spends — and pull that out into its own directory with its own tools and its own test. You'll immediately be able to answer a question you couldn't answer before: is that specific thing working? Then do it again. Next up: [what one of these agents is actually made of](/blog/eve-agents-anatomy) — five files, a real one taken apart line by line, and a build order that starts with the eval instead of the agent.