A Company, Not a Swarm
Archon Merkaba's 30+ agents are organized as a corporate hierarchy with defined reporting lines, spawn permissions, and model tiers. This is a deliberate rejection of the "undifferentiated swarm" pattern: swarms are hard to audit, hard to budget, and hard to debug. An org chart makes every action attributable to a role.
Org Chart
Additional specialists (immersive/3D experiences, chaos engineering, personal ops) attach to this structure as needed; the fleet has grown from 17 to 34 agents over successive waves.
What Makes an Agent
Every agent is defined by a small set of durable files, cached locally and synced to the cloud plane:
| File | Purpose |
|---|---|
SOUL.md |
Identity, personality, values, and mission — the stable core |
IDENTITY.md |
Role framing: title, reporting line, scope boundaries |
TOOLS.md |
Which tools/APIs this agent may use, and how |
MEMORY.md |
The agent's own accumulated knowledge, appended over time |
| Goals registry | Mission + 2–4 measurable objectives, injected into the agent's system prompt at spawn time |
This means an agent is portable: the same TraderBot identity can be spawned locally as a subagent, run as a scheduled cloud job, or answer a chat-ops message — and it behaves consistently because its definition travels with it.
Routing
All inbound work — human requests, chat messages, scheduled triggers, alerts — enters through the orchestrator, which routes by domain:
- Single-domain task → spawn the matching specialist directly. The orchestrator does not do specialists' jobs.
- Cross-domain task → spawn several specialists in parallel with the same brief, then synthesize their outputs (e.g., a strategy evaluation runs the CIO, TraderBot, and Researcher concurrently).
- Trivial task → handled directly; spawning has overhead, and routing a 10-second job to a subagent is waste.
Chat channels are mapped one-to-one to agents (a channel per specialist), so a message in the trading channel reaches TraderBot with no ambiguity. Delivery is logged; failures fall back through a secondary messaging path and, ultimately, a dead-letter queue that can be replayed.
Spawn Permissions
Agents can spawn other agents — but only along audited, explicitly-configured edges that mirror the org chart. Department heads can spawn their reports; a few cross-department escalation paths exist (e.g., trading ↔ engineering); and advisory agents like Cerebrus have no spawn authority at all. This prevents runaway recursive delegation and makes every spawned session attributable to a chain of command.
Model Tiers
Agents are assigned to capability tiers with fallback chains across model providers:
| Tier | Who | Rationale |
|---|---|---|
| Critical (frontier models) | CEO, CIO, CTO, VP Eng, Head of Trading, CISO, Head of ML, Chief Auditor, Cerebrus, SysOp | Decisions with capital, security, or architectural blast radius |
| Standard (mid-tier models) | Researcher, QA, data/ML workers, creative team | High-volume skilled work where mid-tier quality is sufficient |
| Lightweight (small models) | Task coordination, rate limiting, community, vault ops | Mechanical work; paying frontier prices here is waste |
Routing between tiers is further refined per-message (see 03 — Orchestration).
Multi-Model Intelligence: Cerebrus
One agent deserves special mention. Cerebrus is the market-intelligence synthesizer: it queries a panel of heterogeneous frontier models (different vendors, different failure modes), scores their agreement, records disagreement events as signal, and produces a synthesis with calibration tracking. Its accuracy is measured continuously against outcomes, and an internal study on adaptive panel sizing was rejected for cost/benefit — a decision recorded and enforced, not just discussed. Cerebrus is deliberately advisory-only: it informs the CIO and TraderBot but cannot act on markets itself.