← All posts

Tamer's multi-agent supervision patterns: what we learned in 12 weeks

Three patterns that turned a chaotic swarm of agents into a reliable production pipeline.

· tamer team · 9 min read

When we started building tamer, we had a vision of a "Master Agent" driving dozens of specialized workers. We imagined a perfectly efficient hive mind. Reality, as it often does, hit back hard. Agents halluncinated, they stepped on each other's toes, and they spent hours arguing about architectural patterns instead of writing code.

After 12 weeks of intensive development and dozens of shipped features, we've stabilized three supervision patterns that actually work. Here is what we learned.

1. The Skill-Matching Gate: Stop the Wrong Dispatch

In the beginning, the Master Agent would broadcast a Work Item (WI) to any available worker. If Aider was free, Aider got the job. If Claude Code was free, it was the lucky winner.

We quickly realized that generalist agents have specialized "vibe" gaps. Aider is exceptional at surgical refactoring but can struggle with massive greenfield boilerplate. Claude Code has a deep understanding of complex context but can sometimes be "too creative" with local conventions.

We implemented a Skill-Matching Gate. Before a WI is assigned, the Master Agent performs a quick "Capability Check":

  • Does the task require deep dependency analysis? (Prefer Claude).
  • Is it a high-volume, low-complexity file change? (Prefer Aider).
  • Does it involve experimental system calls? (Prefer the Sandbox-specialized Gemini worker).

By auto-detecting these skill gaps before dispatch, we reduced worker abort rates by nearly 40%.

2. 3-Way Consensus: Archi, Dev, and Master

This is our "Anti-Regression" pattern. For complex features, we now use three agents in a loop:

  1. The Archi-Worker: Analyzes the spec and produces a technical design doc (the "How").
  2. The Dev-Worker: Implements the code based on that design.
  3. The Master Agent: Verifies that the implementation matches both the original spec and the Archi-Worker's design.

When the Master sees a divergence, it doesn't just fail the task. it triggers a Consensus Round where the Dev-Worker must either justify the deviation or fix the code. This 3-way check catches the "silent architectural drift" that single-agent workflows inevitably introduce.

3. Max-Autonomy + Blockers-Aside

This was a psychological shift for our orchestration logic. Originally, if an agent hit a blocker (e.g., a missing dependency or a vague AC), it would stop everything and wait for human input.

In a 24/7 pipeline, this is a productivity killer. We shifted to the "Blockers-Aside" strategy:

  • The agent is instructed to drive the validated path as far as possible.
  • If it hits an obstacle, it marks that specific sub-task as "BLOCKED", provides a one-paragraph summary of what it needs, and moves on to the next independent task.

The Master Agent then aggregates these blockers for the human supervisor. This allows the pipeline to continue providing 80% value while waiting for the 20% clarification. Autonomy shouldn't be binary; it should be granular.

The Honest Truth

We didn't get here because we were smart. We got here because we missed our deadlines, broke our builds, and watched agents burn $50 of tokens on a single infinite loop.

Multi-agent orchestration isn't about making agents "smarter"—it's about building the guardrails that make their current level of intelligence useful in a professional environment.

Next steps: