Poor Man's Agent Team: Roles, Routing, and the SDD Pipeline
Three model endpoints don't make a team. Roles, routing, and independent review — how I turned my home AI cluster into a real agent team.
Three endpoints with models behind them don’t make a team. A team appears when every task knows which model should handle it, how it moves through the workflow, and who reviews the result independently.
In part one I built the cluster and gave each machine a role by guesswork. In part two I benchmarked until the guesswork turned into data. This part is what the whole series was building toward: how Olympus became a team of AI agents, not a pile of endpoints.
The benchmark in part two didn’t crown a single winner. It produced a division of labor. That turned out to be the actual lesson, and this post is the payoff: assigning roles to models, the Spec-Driven Development pipeline that moves a task from vague idea to archived change, and the routing skill that decides which model works on which phase.
Who works on what: the team
The cluster wasn’t a team just because models could be queried. It became one when each model got a role — and roles were assigned against the grain of intuition. The biggest model isn’t always the best choice for a task. Sometimes the biggest model is the worst choice, because it’s too slow to hold a conversation, or too expensive to wake up for a one-line fix.
| Role | Model / layer | What it’s for |
|---|---|---|
| Main coder | Mars / Qwen3.6 35B | most implementation, technical decisions, the interactive agent loop |
| Coding specialist | Deimos / Ornith 35B | harder logic, isolated modules, quality-first code |
| Large-context endpoint | Phobos / Bonsai 27B | analysis of big inputs, exploration, code review with large diffs |
| Planner / research | Iris / Hy3 295B (OpenRouter free) | architecture exploration and proposals, always async |
| Independent reviewer | Iris / GPT-OSS 20B (OpenRouter free) | verify, code review, a genuinely second point of view |
In practice:
- Mars is the default executor for most serious work — fast enough (~61 tok/s) and roomy enough (128K context) to actually sit in an agent loop.
- Deimos gets tasks where code quality and solving a well-defined problem matter more than speed — algorithmic modules that should come back right the first time.
- Phobos never enters the agent loop. Its whole value is swallowing a large input and returning a short analysis. That’s not a consolation prize; it’s the job it was picked for in part two.
- Iris fills the gaps: huge context for planning, independent review, and any model that isn’t worth running locally.
SDD: how work flows through the team
A roster of roles is still just a roster. What makes it a team is a process every task moves through. I use Spec-Driven Development for that: instead of starting from “write me this function,” the process breaks a task into phases:
init → explore → propose → spec → design → tasks → apply → verify → archiveEach phase has a specific job:
- init — gather the project’s context and define the starting point;
- explore — understand the problem, its dependencies, and the possible directions;
- propose — compare approaches and pick one;
- spec — write down the requirements and acceptance criteria;
- design — decide on components, interfaces, architecture;
- tasks — break the work into executable tasks;
- apply — implement, test, fix;
- verify — independently check the result against the spec;
- archive — tidy the artifacts and close the change.
Not every phase needs the same model — that’s the whole point of the pipeline. Exploration benefits from the huge context of Iris or Phobos, which can swallow a codebase and a pile of docs. Architectural decisions and the spec go to Mars, which has both the context and the reasoning to carry them. Implementation can be split between Mars and Deimos. And verification is deliberately handed to Iris Reviewer — so the check comes from a different model family than the one that wrote the code. If your reviewer is the same model as your implementer, you’re not reviewing anything; you’re asking a system to agree with itself.
The routing principle, in one picture:
Task arrives
│
├─ explore / research? → Iris planner (async) or Phobos (big context)
├─ propose / spec / design? → Mars
├─ apply (implementation)? → Mars (main) / Deimos (isolated modules)
├─ verify? → Iris reviewer (different model family)
└─ init / tasks / archive? → lightweight workerlocal-team: routing instead of manual choice
All of this mapping lives in a skill called local-team. It contains the instructions for the orchestrator: which task type goes to which worker, when to use the cloud, when to kick off an async job, and when not to delegate at all.
The core rule is simple and I’ll state it loudly: pick a model by role, not by prestige. A fast model is better for a short task. A large context matters more when analyzing many files. An independent reviewer only makes sense when it isn’t the model that wrote the solution. The model whose name sounds most impressive in a benchmark table is often the wrong tool for the job right in front of you.
What this buys in practice: an agent calling a local worker never needs to know its address, port, or start command. It receives a role-appropriate task, and local-team — together with LiteLLM and the cluster config — handles the rest. I can swap models underneath without rewriting a single workflow. That’s the difference between “three computers with an LLM on each” and an actual team: the cluster provides the compute, local-team provides the rules of collaboration.
Skills that changed the economics of local models
Roles and routing decide who works. But local workers are slower than the best cloud models, have smaller context windows, and make every token cost visible. So I added a few skills that change how models behave — each one solving a different problem: the way of speaking, the way of building, the choice of worker, and the state of the documentation.
caveman — fewer words, more work
caveman controls how a model answers. It strips out narration, pleasantries, prompt repetition and long explanations when the task primarily wants the work done. That matters enormously on local models, where every extra token is real generation time. On my workers it cuts about 65% of the unnecessary output tokens.
I don’t apply it unconditionally. The verify phase needs detailed findings, and the design phases need full explanations of assumptions. caveman is compression of communication, not a command to think less. Used well it shortens the answer; used badly it hides the important parts. For the philosophy behind it, grugbrain.dev says it best.
ponytail — less code, smaller problem
ponytail controls what a model builds. It enforces YAGNI: first check whether the feature is needed at all, then reach for an existing helper, the standard library, or a native platform feature. A new abstraction comes last, not first.
This isn’t just style — it’s context economics. A shorter implementation means fewer tokens to generate, fewer places to break, and a smaller diff to review. On my workers it cuts generated code by roughly half — about 54%. What it doesn’t do is remove quality requirements: validation, error handling, security, accessibility and tests are all still mandatory. It prunes the code, not the standards.
In the Olympus config, caveman and ponytail are used primarily in the apply phase, where the model is generating code. I deliberately don’t apply them in explore, propose, spec, or design — there, aggressive compression would shrink the reasoning itself:
| Phase | caveman | ponytail |
|---|---|---|
| init | ✅ | ❌ |
| explore | ❌ | ❌ |
| propose | ❌ | ❌ |
| spec | ❌ | ❌ |
| design | ❌ | ❌ |
| tasks | ✅ | ❌ |
| apply | ✅ | ✅ |
| verify | ❌ | ❌ |
| archive | ✅ | ❌ |
local-team — the delegation rules
I mentioned local-team above; in the skill stack it answers which model should work. It doesn’t force every worker onto the same task — it maps the kind of work to the available capabilities. Fast model handles short implementations, Deimos takes the harder modules, Phobos reads big inputs, Iris does independent research or review.
The separation matters: caveman and ponytail describe how a worker behaves. local-team decides which worker gets used at all.
cluster-docs — documentation as part of the infrastructure
Documentation is the easiest thing to forget exactly when the cluster is changing fastest. Adding a model doesn’t end with downloading a GGUF file. It touches the machine registry, model paths, systemd units, LiteLLM config, the agent roster, benchmarks, the changelog, and the handoff for the next session.
So I added a cluster-docs skill — part automation, part enforced habit — whose job is to treat config changes and documentation changes as one process. It’s built around four operations:
add-model— register a model on a machine and everything wired to it;benchmark— record results in one standardized place;handoff— generate a summary of state and open tasks for the next session;status— detect documentation drift: the situation where different files describe different versions of the cluster.
This looks like bureaucracy right up until you change the model on Phobos and half the documents still describe the previous config. Then documentation stops being an add-on and becomes part of the cluster’s operating system.
Skills don’t replace verification
caveman doesn’t guarantee short answers. ponytail doesn’t guarantee good code. local-team doesn’t guarantee correct routing. And cluster-docs doesn’t guarantee every decision was interpreted correctly. These mechanisms constrain repeatable problems — but benchmarks, tests and independent review are still the actual checkpoints.
The biggest win wasn’t that the models suddenly got smarter. It was that the number of decisions I had to make manually on every task went down. On a local cluster, that repeatability is exactly what separates a useful tool from a collection of interesting experiments.
What works, and what’s still a compromise
It would be easy to show just the working diagram and the model list and call it a day. That wouldn’t be honest about what this project actually is. The cluster works, but it is not a hands-off cloud. Every advantage has a specific cost attached.
What works: all models behave as one team behind a single API. I can match a model to a task type and don’t have to remember which physical computer runs which endpoint. A local benchmark lets me test new models before they enter the workflow. Documentation records decisions that would otherwise evaporate into session history. And the vast majority of work runs locally, with no per-token bill — though let’s not pretend local AI is free: I pay in electricity, setup time, hardware wear and attention. The free OpenRouter tier has its own limits and latency. What I gained is choice: local inference as the baseline, cloud as the complement, not the only path.
What’s still a compromise: every worker has different memory, context and speed limits. Models need warm-up time. Phobos is useless in a fast tool loop. A control-plane or LAN failure makes the whole cluster harder to use. Benchmarks are a sample, not a guarantee — they don’t predict every repository and task type. And there’s the ongoing maintenance tax: config, updates, logs, docs.
The honest summary is this: it’s not a system without limits. It’s a system whose limits I can name and plan around. That’s a much more useful property than it sounds like.
The end of the series — and the point of it
Olympus isn’t my private version of cloud infrastructure. It doesn’t compete with the biggest models on scale, convenience, or reliability. It’s something else: a laboratory where I can test models, tools, and ways of working on hardware I actually own.
The most valuable thing I learned is how to match a tool to a task. A model that looks great in a short test can be useless in a long agent loop. A slow model with a huge context can be an excellent consultant. A free cloud tier can complement local workers — but it shouldn’t be a hidden single point of failure.
And the next step isn’t a bigger cluster. It’s finding what this one is good for: small, personalized agents for my own workflows, maybe n8n automations that scan the network and analyze the results. Every new element should solve a specific problem that appeared while using the thing — not make the setup look more impressive.
If you’re building something similar, I’d genuinely like to know: which limit turned out to be the one that mattered on your hardware — memory, bandwidth, or model quality? And did you assign roles, or are you still throwing every task at one model?
The series
- Part 1: Poor Man’s AI Cluster — When You Can’t Afford a DGX, You Build an Olympus
- Part 2: Poor Man’s Model Selection — Not Every Model That Boots Is Useful
- Part 3: this post