How Eight AI Agents Coordinate Without a Slack Channel

Armada Works runs eight AI agents against its own codebase. They produce blog posts, keyword audits, outbound prospect research, lead triage, email nurture sequences, LinkedIn posts, prospect discovery on X, and a daily synthesis of all of it. None of them share a Slack channel. None of them send each other messages. There is no queue service, no event bus, no webhook chain connecting them. They coordinate through files committed to main.

This is the part of the architecture that draws the most questions. This post covers the philosophy: why we built coordination this way, what it feels like to operate, and what 175 days of continuous operation taught us about where it holds and where it breaks. If you want the technical deep-dive (cron cadences, state-file formats, single-writer rules, the actual file paths), read How the Fleet Actually Coordinates. That post is the companion to this one.

The Problem With Agent-to-Agent Communication

The first instinct when you have multiple agents is to let them talk to each other. Agent A finishes a keyword audit, sends the result to Agent B, which writes a blog post targeting that keyword. It sounds clean. In practice, it creates the same problems you get with a team of humans on Slack: context gets lost in transit, messages arrive out of order, and debugging means tracing a conversation across multiple threads.

We tried a version of this early on, when we built the system that became Armada Works. The SEO agent would write a brief and pass it directly to the Content agent. The Content agent would draft a post and notify the CMO. Within a week, the CMO agent was receiving malformed briefs because the Content agent had reformatted the SEO agent's output. Nobody was wrong. The chain just decayed with each handoff, the way a message decays in a game of telephone.

So we threw it out and replaced it with something simpler.

Git Is the Coordination Layer

Every agent in the fleet writes to files in the same repository. The SEO agent writes its state to docs/agents/state/seo-agent-state.md. The Content agent reads the content queue at docs/agents/state/content-queue.md and writes finished drafts to docs/content/blog/. The Sales Lead agent writes qualification notes. The Outbound agent writes prospect research. Each agent posts a daily brief to the dashboard through a shared API endpoint.

No agent writes to another agent's files. They read from shared state and write to their own output locations. The coordination happens through git: every change is committed, timestamped, and attributed to the agent that made it. If you want to know why the Content agent wrote a post about marketing automation instead of agent coordination last Tuesday, you run git log on the content queue and see which item the CMO agent moved to the top. The full decision chain lives in the commit history.

This is not clever engineering. It is the absence of clever engineering. Files in a repo, committed to main, readable by anyone with access. The same coordination mechanism your team already uses for code, applied to marketing operations.

The CMO Agent: One Brief to Read Them All

Eight agents producing output on staggered schedules means eight sets of state files and a growing pile of markdown that no founder is going to read every morning. This was obvious from the first week we ran the system. The raw output of a multi-agent marketing system is more information than any single person should process daily.

The CMO agent exists to solve exactly this problem. It runs after every other agent has finished its scheduled work. It reads all seven sub-agent briefs, reads the latest state files, and writes a single synthesis: the three to five things that actually need the founder's attention. A keyword that dropped. A blog post that shipped. An outbound prospect who replied. A credential that expired.

The founder reads one document each morning. Not eight. Not a Slack channel with 40 unread messages. One brief, written by an agent whose only job is deciding what matters today.

When we first introduced the CMO agent to our agent-first consultancy architecture, it changed the dynamics of the entire fleet. Before synthesis, the founder was the bottleneck. After synthesis, the founder was the reviewer. That distinction is the difference between a system you operate and a system that operates for you.

State Files Replace Meetings

In a human team, coordination happens in meetings. Monday standup: what did you do last week, what are you doing this week, what is blocking you. The meeting exists because there is no other shared surface where all the context lives at once.

Agents have that surface. It is the state file. Each agent maintains a persistent state file that records what it shipped, what it plans to do next, and what is blocking it. The CMO agent reads all of them. If the SEO agent flags a new keyword opportunity in its state file, the CMO agent can add a corresponding item to the content queue on its next run. No meeting, no handoff, no message. Just a commit.

This pattern scales in a way that meetings do not. The fleet started at six agents in early May 2026 and grew to eight by adding a Social Media agent (LinkedIn posts via Buffer) and an X Prospecting agent (scanning X for founders actively seeking AI agent help). Each integration cost was exactly one prompt file, one state file, one cron schedule, and one more entry in the CMO's read list. No architectural changes. No message routing to redesign. The hub-and-spoke model is flat. The CMO is the hub. Every other agent is a spoke. The spokes never need to know about each other.

If you have built your own marketing agent fleet, this is the architectural piece that makes it manageable at scale. Without a synthesizer agent, you are the synthesizer. And that defeats the purpose of having the fleet in the first place.

For the full technical breakdown of how this coordination model works in practice, including cron cadences, single-writer rules, and the actual state file format, see How the Fleet Actually Coordinates.

What 175 Days of Coordination Taught Us

The system described above is simple. That simplicity is what makes it work. But 175 days of continuous operation also revealed failure modes that the original design did not anticipate, and the coordination model had to absorb them without becoming complex.

State files grow. The Outbound agent's state file reached 1,800 lines. The X Prospecting agent's hit 1,291 lines. When a state file grows past a certain size, the agent spends more of its context window reading history than doing new work. The fix is manual compaction: a human reviews the file, archives completed items, trims resolved threads, and commits the shorter version. This is coordination maintenance. It is not automated because the judgment call about what to keep is exactly the kind of decision a human should make. We now treat compaction as a scheduled operational task, the same way you would treat database maintenance.

Credentials fail silently. The Social Media agent's Buffer API token expired on Day 89. The agent reported the failure in its brief, but nothing in the coordination model escalated the failure automatically. The CMO agent flagged it. Then it flagged it again the next day. And the next. As of this writing, the auth failure has persisted for 103 days across 37 consecutive briefs reporting the same problem. The coordination model surfaced the issue correctly every single time. The bottleneck was human action. This taught us something important: coordination is not the same as resolution. A system that reliably tells you something is broken is valuable, but it does not fix the thing.

Escalation counts accumulate. The CMO agent tracks how many consecutive sessions it has flagged an unresolved issue. The CTA/funnel decision has been escalated 106 times across 161 days. The Apollo degradation has been flagged for 71 consecutive sessions. These counts are not noise. They are the coordination model's way of distinguishing between "this is new" and "this has been broken for four months." When a carry-forward counter passes 30 sessions, the CMO's brief starts marking it differently. This was not designed upfront. It emerged from operating the system and noticing that flat-priority issue lists hide the difference between a one-day problem and a chronic one. For more on what these failure modes look like in practice, see What Happens When Agents Break.

Fresh-session agents need institutional memory in plain text. Every agent in the fleet starts cold. No conversation memory, no fine-tuning, no vector store. The Content agent is on run 107. It knows which Unsplash photos it has already used, which pricing figures it verified against the canonical config, which content clusters exist and how they are cross-linked, and that date-bump refreshes have a 0/8 success rate. All of that lives in a "Things To Remember Next Session" section at the bottom of its state file. The same pattern holds across the fleet. The SEO agent carries 153 sessions of ranking trend data. The Outbound agent carries 730+ evaluated companies across 141 sessions. None of this requires a database. It requires discipline about what gets written down and committed.

What the Founder Actually Does

My morning takes about five minutes. I open the dashboard, read the CMO synthesis, and decide whether anything needs a human response. Most days, the answer is nothing. The agents ran, the work shipped, the briefs look reasonable.

When something does need attention, it is usually a judgment call that no agent should make autonomously. A prospect replied to a cold email and wants to talk pricing. The SEO agent flagged a keyword that conflicts with our positioning. The Content agent drafted a post that references something we have not published yet. These are the right escalations. They are the moments where founder context matters and agent context is not enough.

The rest of the time, I work on the product, talk to prospects, and review code. The fleet runs in the background, committed to main, visible in the dashboard, and auditable at any point through the git history. After 175 days and 107 Content runs, the state files have become the institutional memory of the operation. Each agent leaves notes for its future self: which photos have been used, which pricing figures were verified, which prospects are stale, which content clusters need cross-linking. That persistent context, written to plain markdown and committed to git, is what makes fresh-session agents feel like they have continuity.

This is what I mean when I say agents should free you from coordination overhead, not add to it. A multi-agent marketing system that requires an hour of daily management is just a different kind of meeting. The coordination model has to be cheap enough that you forget it is there most mornings.

Why This Works (and Where It Falls Short)

The coordination model works because it is simple. Files in a repo. One agent reads them all. The founder reads one summary. There are no race conditions because agents run on scheduled cadences, not event triggers. There are no lost messages because everything is committed to git. There is no shared mutable state that two agents can corrupt simultaneously.

Where it falls short: latency. If the SEO agent discovers a critical keyword shift at 9:05 AM and the Content agent already ran at 9:00 AM, the content response happens on the next scheduled run, not immediately. This system trades real-time responsiveness for auditability and simplicity. For marketing operations, that tradeoff is almost always correct. For incident response or customer support triage, you would want a different architecture entirely.

The other limitation is the CMO agent itself. If its prompt drifts or its synthesis gets sloppy, the founder's view of the entire fleet degrades. The CMO is the single point of trust in the system. We tune its prompt more frequently than any other agent in the fleet, and we review its output more carefully than anything else. The hub matters more than any individual spoke. Protecting the quality of that synthesis is the highest-leverage maintenance task in the whole operation.

The third limitation, visible only at scale, is maintenance labor. State-file compaction, prompt updates, credential renewals, cron schedule corrections: these are all human tasks that the coordination model surfaces but cannot resolve. Over 175 days, the fleet has required approximately one human intervention per week on average. That is cheap for the output it produces. But it is not zero, and anyone evaluating whether to build their own fleet or hire a consultancy to run one should know what the real maintenance burden looks like. For a detailed breakdown of what a production runbook for this kind of system includes, see What a Production Runbook Looks Like.

The System You Can Inspect

Everything described here runs in the open. The state files are in git. The briefs land in the dashboard. The CMO synthesis arrives every morning before the founder opens a laptop. If you want to understand how this coordination model works before you consider whether a similar system could run for your business, read how we engage or book a 30-minute discovery call. We will walk you through the actual repo, not a slide deck.