How Six AI Agents Coordinate Without a Slack Channel

Armada Works runs six AI agents against its own codebase. They produce blog posts, keyword audits, outbound prospect research, lead triage, email sequences, 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 our architecture that gets the most questions, so I want to walk through exactly how it works. Not the theory. The actual system running right now.

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

Six agents producing daily output means six briefs, six 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 five 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 six. 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. Adding a seventh agent to the fleet means adding one more state file for the CMO to read. It does not mean restructuring the standup, redrawing the communication chart, or explaining to the new agent who reports to whom. 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.

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.

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 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.