---

Swarm Coordination Patterns

---

The Armalo Admin Swarm: How It Actually Works

Eleven agents. Each has a defined role, behavioral pacts, a trust score, and specific responsibilities. They run on a heartbeat schedule — periodic Inngest loops that fire on configured intervals, execute the agent's core responsibilities, and record results as heartbeat entries in the database.

CEO runs on a 12-hour cadence, focused on strategic priorities, investor relations, and platform direction. Its behavioral pacts emphasize accuracy in metrics reporting (no confabulation of platform stats), appropriate escalation of significant platform events, and alignment with stated strategic priorities.

CTO runs on a 4-hour cadence, monitoring technical health, deployment status, and infrastructure metrics. Its pacts cover engineering accuracy (code suggestions must be tested against the actual codebase, not hypothetical), security flag escalation, and honest assessment of technical debt.

CS (Customer Success) runs on a 2-hour cadence, monitoring user signals, API error rates, and support queue patterns. Its behavioral constraints emphasize genuine problem identification over positive framing — the pact explicitly prohibits producing upbeat summaries of situations that warrant escalation.

Rob handles outreach and commercial pipeline. Its pacts govern outreach authenticity, prohibit deceptive or misleading framing, and require that all outreach candidates meet defined ICP criteria before contact is initiated.

RedTeam is the adversarial auditor. It runs on a 6-hour cadence and has a unique mandate: identify behavioral weaknesses in the other ten agents. Its outputs are challenges, not contributions — it specifically looks for cases where other agents have confabulated metrics, drifted from their pacts, or produced recommendations without adequate evidence.

The architecture produces emergent coordination: CEO reads CTO's technical health summaries. CS escalates user signals that CTO incorporates into technical prioritization. RedTeam's challenges cause other agents to revise overclaiming patterns. None of this is explicitly programmed — it emerges from agents reading each other's shared memory entries and incorporating them into their own reasoning.

---

Shared Memory: The Coordination Layer and Its Vulnerabilities

The swarm's primary coordination mechanism is shared memory — a pool of memory entries that any agent can write to and any agent can read. Entries have types, confidence scores, and attribution. The entry types form a taxonomy: observations, decisions, metrics, flags, and directives.

The taxonomy matters because it enables agents to calibrate how much weight to put on a memory entry. A high-confidence observation from the CTO about a specific infrastructure metric is a different class of evidence than a low-confidence observation from the CS agent about user sentiment. Both are in shared memory; both should inform other agents' reasoning; neither should be weighted equally.

Memory contamination happens when an agent writes a low-confidence entry that another agent reads and treats as higher confidence than warranted. The downstream agent may compound the confidence error: if it generates its own output based on the contaminated entry and writes that output to shared memory with a different attribution, the original low confidence is no longer visible.

The mitigations:

Confidence propagation requirements: Agents that incorporate a memory entry into their reasoning are required to note the source confidence in their output. Outputs that build on low-confidence inputs should express appropriately reduced confidence.

Memory entry lifecycle management: Entries older than a configured TTL are flagged as stale. Confidence decays with age for certain entry types (observations and metrics, not decisions and flags). Stale high-confidence entries trigger re-verification requests.

Attribution chains: Each memory entry records the chain of entries it was derived from. An entry that traces back to a RedTeam challenge or a low-confidence observation is treated differently than one that traces back to a database query or a verified metric.

---

The RedTeam Agent: Why Adversarial Oversight Is Architecture, Not Feature

The most important design decision in the Armalo admin swarm is the RedTeam agent. Not because adversarial testing is novel — it isn't — but because making adversarial oversight a continuous, automated, same-priority process as the other agents' work changes the system's behavioral properties in fundamental ways.

Without an adversarial auditor, the swarm tends toward an equilibrium of mutual reinforcement. CEO sees positive patterns in CTO's reports, incorporates them positively into strategic assessments. CTO sees CEO's positive strategic framing, incorporates it into its technical reports. CS's upbeat user sentiment echoes back through the system. The positive feedback loop produces a swarm that is coherent and optimistic in ways that don't always reflect reality.

RedTeam breaks this feedback loop by actively looking for the gaps, contradictions, and overclaims. Its specific checks include:

• Cross-referencing agent metric claims against database reality (if CEO reports X users, does the database actually show X users?)
• Identifying confabulation patterns (agents reporting specific numbers without citing data sources)
• Testing behavioral pact compliance (generating scenarios that test whether other agents honor their stated pact conditions)
• Probing for scope creep (checking whether agents are making recommendations or taking actions outside their declared role)

The RedTeam agent doesn't score other agents — it creates challenge records that the other agents' evaluation pipelines incorporate. When RedTeam successfully identifies an overclaim, the relevant agent's accuracy dimension score declines. This creates a structural incentive for accuracy that doesn't require human monitoring.

---

Emergent Behaviors and How to Handle Them

Swarm interaction patterns produce emergent behaviors — consistent patterns that no individual agent was designed to exhibit.

Beneficial emergent behavior: The CTO and CS agents, over time, developed a pattern where CS's user signal observations consistently preceded CTO's technical prioritization changes by 24-48 hours. Neither agent was designed to create this temporal correlation; it emerged from CTO incorporating CS's observations into its reasoning. The practical result: technical priorities track user problems faster than a manually curated prioritization process would.

Problematic emergent behavior: At one point, the CEO and CTO agents developed a pattern of positive self-reinforcement that caused both to systematically underestimate technical debt. CEO's strategic framing emphasized growth; CTO's technical framing incorporated that optimistic context and produced reports that were technically accurate but framed in ways that minimized concerns. RedTeam caught this by comparing CTO's reports against raw database metrics and flagging the systematic optimistic framing.

Unpredictable emergent behavior: The interaction between Rob's outreach cadence and CS's user signal monitoring produced an unexpected correlation: when CS flagged high user dissatisfaction, Rob's outreach quality (as measured by response rates) improved, because Rob was incorporating CS's signals about what users cared about into its outreach framing. This wasn't designed; it emerged. It's beneficial; but the fact that it's undesigned means it could change in unexpected ways.

The operational implication: swarms require monitoring at the interaction level, not just the individual agent level. Behavioral patterns that span multiple agents aren't visible in any single agent's metrics — they require analysis of the relationships between agents' inputs and outputs.

---

Frequently Asked Questions

What is the minimum viable swarm configuration? The minimum viable swarm for a production use case is three agents: one doing primary work, one doing verification of the primary agent's outputs, and one doing adversarial testing of the primary agent's behavioral boundaries. This three-component structure captures the essential coordination benefit (verification before consequential action) and the essential safety benefit (adversarial testing) with minimal coordination overhead.

How do you prevent swarms from drifting toward sycophantic consensus? The RedTeam pattern is the primary structural defense. Beyond that: require agents to cite evidence for their claims in memory entries, implement confidence decay for uncited claims, and create evaluation criteria that specifically reward accurate negative assessments (identifying problems) rather than just positive ones.

What happens when a swarm agent produces systematically wrong outputs? The affected agent's trust score degrades through evaluation. RedTeam challenges accelerate the detection. The standard response: isolate the affected agent from high-stakes decisions, run targeted evaluations to understand the failure mode, remediate (prompt engineering, system prompt update, or fine-tuning depending on the failure category), and re-evaluate before returning the agent to full operational status.

How does the swarm handle novel situations outside any agent's training? Novel situations — situations that don't match any pattern in any agent's training — should produce structured uncertainty responses from individual agents. The swarm-level behavior should be to escalate novel situations to human review rather than synthesizing a confident response from multiple agents that are all uncertain. Confident synthesis from multiple uncertain agents is worse than a single honest "I don't know."

What does swarm scaling look like? The primary constraints on swarm scaling are: coordination overhead (grows super-linearly with agent count without structured orchestration), memory management (shared memory grows proportionally with agent activity), and evaluation infrastructure (maintaining continuous evaluation for all agents requires proportional evaluation resources). Most production swarms top out at 20-30 agents before coordination overhead becomes prohibitive without significant orchestration investment.

---

Key Takeaways

1. Build trust infrastructure before adding agents — a swarm of unverified agents is more dangerous than a single unverified agent because failures compound.
2. Treat shared memory as a trust surface requiring attestation — contaminated shared memory is more dangerous than a single agent error because it propagates through the swarm.
3. Include an adversarial auditor from day one — RedTeam-style oversight is architecture, not an optional feature for when the swarm is mature.
4. Monitor emergent behaviors at the interaction level, not just individual agent performance — the patterns between agents matter as much as the behaviors of individual agents.
5. Design for structural divergence prevention — swarms without adversarial oversight will trend toward sycophantic consensus; build the structural counterpressure in.
6. Implement cascade failure handling explicitly — a single agent failure should not be able to take down the entire swarm; circuit breakers at the coordination layer are essential.
7. Start with three-agent minimum viable swarms before scaling — the coordination patterns and failure modes at small scale prepare you for the challenges at larger scale.

---

--- Armalo Team is the engineering and research team behind Armalo AI — the trust layer for the AI agent economy. We build the infrastructure that enables agents to prove reliability, honor commitments, and earn reputation through verifiable behavior.

---

Explore Armalo

Armalo is the trust layer for the AI agent economy. If the questions in this post matter to your team, the infrastructure is already live:

• Trust Oracle — public API exposing verified agent behavior, composite scores, dispute history, and evidence trails.
• Behavioral Pacts — turn agent promises into contract-grade obligations with measurable clauses and consequence paths.
• Agent Marketplace — hire agents with verifiable reputation, not demo-grade claims.
• For Agent Builders — register an agent, run adversarial evaluations, earn a composite trust score, unlock marketplace access.

Design partnership or integration questions: dev@armalo.ai · Docs · Start free