AI AgentsRequest Channels, Priorities, and Shared Rules for 12 AI Agents
· AlgoSu
- #ai-dev
- #agent
- #governance
Problem
Running 12 agents as a team broke down without control. Who verifies whose code, who mediates conflicts, and how do shared rules stay consistent?
Decision
Three things. Narrow communication to a single channel, the lead agent Oracle; split the agents into three priority tiers (echelons); and gather the shared rules into one file (persona-base.md).
Result
Consistent quality all the way to sprint 67 (sprints are short work cycles). In exchange, the context cost of re-reading rules and an Oracle bottleneck remained, and domain intuition was still a human job.
Turning 12 Agents into a Team
Calling agents one at a time wasn't hard. The trouble started when I tried to run 12 of them as a team.
Three questions kept coming up. Who verifies whose code? Who mediates when there's a conflict? How do the shared rules stay consistent?
Without control, each agent churned out code on its own, and technical debt piled up faster than any human could create it. When 12 agents wrote code by their own judgment, style, quality, and direction all diverged. The very advantage of fast output was turning into a risk.
One Channel: Oracle
Talking to all 12 was impossible. With the first eight agents, calling each one directly was fine. With 12, I couldn't even keep track of who was doing what. So I narrowed communication to one channel.
The lead agent, Oracle, became the only agent that talks to me, the PM. Oracle directs the other 11.
The flow goes one way: PM → Oracle → the agent in charge → Oracle → PM. Agents don't talk to each other directly.
Services talking over HTTP is not the same as agents talking to each other. For example, when the submission service (code owned by Conductor, the submission-flow agent) asks the problem service (code owned by Curator, the problem-management agent) for a deadline, that's an internal HTTP call between programs. The agents that build them never talk to each other directly.
PM (Human)
Task requestOracle
Analyze · pick who does itAgent in charge
Work in its own areaOracle
Consolidate · verifyPM (Human)
Final review
Oracle decides what to do; each agent decides how. How to implement a Saga (running a task across several services step by step, and undoing the steps if one fails) is Conductor's call. How to write the Kubernetes (k8s) deployment files is up to Architect, the infrastructure agent.
Decisions followed a priority order: Service Stability > Development Velocity > Feature Completeness. If Herald, the frontend agent, asked for a new UI component while Gatekeeper, the auth and security agent, reported a vulnerability in JWT validation, Oracle went straight to the security issue.
Oracle had rules of its own.
- It doesn't write code.
- It doesn't make decisions that break the core design principles: each service owns its own database and treats it as the source of truth (Database per Service), and work that spans services is coordinated with a Saga.
- It doesn't take sides with any agent.
Oracle is the referee between agents, after all.
Echelons: Priority Tiers
Keeping all 12 agents equal meant having no priorities. So I borrowed the idea of echelons from multi-agent system (MAS) research and split them into three tiers.
"Echelon" implies a chain of command and delegation. It doesn't get confused with server tiers (3-tier architecture), and it expresses both priority and execution order among agents.
Tier 1
Mission Critical
Oracle (lead), Conductor (submission flow), Gatekeeper (auth and security), Librarian (database). If these four break, the whole service stops. All agents ran on Anthropic's Claude models, and tier 1 used the most powerful Claude model at the time (Opus).
Tier 2
Core
Architect (infrastructure), Postman (GitHub integration), Curator (problem management), Scribe (documentation). They handle the infrastructure foundations and core business logic.
Tier 3
Enhancement
Sensei (AI analysis), Herald (frontend), Palette (design system), Scout (user testing). Roles that add value to the service; they start only after tiers 1 and 2 are stable.
The tiers weren't just labels; they were also the execution order. Tier 1 set up the safety nets first, tier 2 built, and tier 3 finished. Following this order cut dependency conflicts sharply.
Twelve agents in three priority tiers (echelons)
One Source of Truth for All 12
For 12 agents to behave consistently, they needed shared rules. One file, persona-base.md, played that role. It was the single source of truth (SSoT): the one place the rules are kept.
Each agent's own definition file carried the same line:
Shared Rules: Reference:
agents/_shared/persona-base.md(mandatory read before starting)
The file had three key rules. The time limits below (4 hours, 24 hours) are rules written in that shared rules file. They were modeled on a human team's rules, so rather than anyone timing them, they worked as ordering rules: "don't sit on it alone, report it" and "announce a change before making it."
Escalation (passing it upward): When a decision was beyond an agent's scope, or agents conflicted, it went up to Oracle. If it couldn't be decided within 4 hours, it was reported to the PM. Agents don't know everything either; the point was to pass it up instead of guessing. In practice, when Palette (design system) and Herald (frontend) disagreed on a component spec, Oracle mediated.
Interface contracts: When changing an API spec, the affected agents were notified 24 hours ahead. Backward compatibility came first, and breaking changes needed Oracle's approval. The goal was to keep one service's change from breaking another in a microservice setup.
Code rules: One responsibility per function, 20 lines max, DRY, SOLID. A descriptive comment at the top of every file (header annotation) was mandatory. No values hardcoded inline. These rules applied the same way to all 12. Whether Conductor or Herald wrote the code, it followed the same style and the same quality bar.
Changing persona-base.md changed the behavior of all 12 agents at once. That was the core of control.
Control structure
What It Gave and Didn't
I ran 67 sprints under this structure. It gave some things and couldn't give others.
It gave consistent code quality. Because persona-base.md worked as the single source of truth, annotation rules, naming conventions, and error handling stayed the same from start to finish. But it came with a context cost. Every time an agent started work, it spent part of its context window (how much it can handle at once) reading the shared rules and its own definition file.
It gave context retention. Three records kept the context: the per-sprint decision records (ADRs); MEMORY.md, a memory file loaded automatically every session; and sprint-window.md, read first in every session, which holds only the last finished sprint and the one in progress. With these, I could find a decision from three months ago in five seconds. But it created an Oracle bottleneck. Since all work went through Oracle, tasks could be handed to several agents at once, but final verification happened one at a time.
It gave safe changes. Librarian (database) made database changes ship in 3 phases, Gatekeeper verified security rules, and Architect checked resource limits. But the lack of domain intuition stayed unsolved. "Does the user actually need this feature?" was a question agents couldn't answer. Carrying out technical decisions could be handed to agents; setting direction was still a human job.
The Value of Controlled AI
Letting AI write code wasn't the hard part. The hard part was making that AI follow the project's rules, stay out of other areas, and be reversible when it made mistakes.
Oracle, the referee, makes the calls; the priority tiers set the order; and one file keeps everything consistent. It wasn't a perfect system, but it was the structure that kept quality consistent all the way to sprint 67. Uncontrolled AI is dangerous; controlled AI held its consistency without wavering.