How the Agent Fleet Actually Coordinates

I wrote a post a few weeks ago about how six AI agents coordinate without a Slack channel. That post was the conceptual version: why git instead of a message bus, why a synthesizer instead of peer-to-peer routing. People asked follow-up questions. Most of them were the same question in different words: "But how does it actually work? Show me the files." This post is the answer. Armada Works runs seven agents on cron schedules against a single git repository, and what follows is the technical coordination model that keeps them from stepping on each other.

Every Session Starts Cold

The first thing to understand about this system is that no agent has memory between runs. Each scheduled execution is a fresh Claude Code session. The agent does not remember what it did yesterday. It does not have a conversation history from its prior run. It wakes up, reads its prompt file, reads the state files in the repository, does its work, writes its output, commits, and stops.

This is not a limitation. It is the design.

Persistent sessions accumulate context drift. An agent that remembers forty prior runs starts hallucinating about work it thinks it did but didn't, or about conversations that happened in a different branch of execution. Fresh sessions eliminate that entire failure class. The tradeoff is that anything the agent needs to remember between runs has to be written down in a file and committed to the repo. If it is not in the state file, it does not exist.

The agent's prompt file at docs/agents/content-agent-prompt.md tells it where to look: which state file to read, which queue file to consume, which output directories to write to. The state file at docs/agents/state/content-agent-state.md tells it what happened last time: which drafts are in flight, which items it shipped recently, which questions it left for the CMO, and any notes it left for itself. The agent reads both on every run, rebuilds its understanding of the world from scratch, and picks up where the prior session left off.

This pattern works because the state file is small (under 100 lines), structured, and committed to git. If an agent writes bad state, you can revert the commit. If an agent misreads state, you can diff the file against the prior version and see exactly what went wrong. There is no hidden memory, no opaque vector store, no session database. The full picture of what any agent knows is visible in a git show.

Git as the Message Bus

Agents in the Armada fleet do not send messages to each other. There is no inter-agent API, no pub/sub topic, no shared database table for coordination. Instead, every agent writes to files in the same repository, and every agent reads from the files it needs.

The SEO agent writes its state to docs/agents/state/seo-agent-state.md. That file contains the current keyword rankings, traffic snapshot, indexed pages, and any content recommendations. The Content agent, when it picks up a queue item that says "target keyword: agentic marketing," reads the SEO state file to understand the current search landscape before it drafts. The Content agent never asks the SEO agent for this information. It reads the file.

The CMO agent writes the content queue at docs/agents/state/content-queue.md. The Content agent reads it, picks the highest-priority pending item, marks it in progress, and drafts. When the draft is done, the Content agent moves the item to completed and writes the output path. The CMO sees the update on its next run by reading the same file.

This is message passing through commits. The "message" is a change to a shared file. The "bus" is git. The "acknowledgment" is the next agent's commit that shows it read the change.

What makes this work in practice:

No agent writes to another agent's state file. The SEO agent writes seo-agent-state.md. The Content agent writes content-agent-state.md. The CMO writes the queue and its own briefs. Ownership is unambiguous. If two agents could write to the same file, you would get merge conflicts on every overlapping cron window. Single-writer, many-reader eliminates that.

Commits are ordered. Git timestamps every change. If you want to know whether the Content agent saw the SEO agent's latest keyword recommendation before it drafted a post, you check the commit timestamps. The audit trail is built into the version control system you already have.

Rollback is trivial. If the CMO agent writes a bad queue item, or the Content agent mismarks something as completed, you revert the commit. The state returns to exactly what it was before. No database migration, no API call to undo, no "soft delete" flag.

Cron Cadences and Why They Matter

Every agent runs on a cron schedule. The current cadences:

• SEO, Content, Sales Lead, Outbound, CMO: Monday, Wednesday, Friday at 9:00 AM PT
• Email Marketing: Daily at 9:00 AM PT
• Social Media: Monday, Wednesday, Friday at 9:30 AM PT

The ordering matters. All sub-agents run at 9:00 AM. The CMO agent also runs at 9:00 AM, but it reads the briefs and state files that the other agents have just written. In practice, the sub-agents finish their work within 5 to 15 minutes of starting. The CMO's scheduled task reads whatever state existed at the moment it started, which usually includes the fresh output from the same morning's sub-agent runs.

This is not real-time coordination. If the SEO agent discovers a keyword shift at 9:02 AM on Wednesday, the Content agent (which started at 9:00 AM and may already be mid-draft) will not see it until Friday's run. The system trades latency for simplicity. For marketing operations, where nothing is urgent on a minute-by-minute basis, this tradeoff is correct. If you needed sub-second coordination (incident response, real-time bidding), you would use a different architecture entirely.

The cron cadence also prevents resource contention. Agents that run at the same time operate on different files. They commit sequentially (git handles that). Because each agent writes only to its own output locations, parallel execution does not produce conflicts. We have run seven agents in overlapping windows for weeks without a single merge conflict.

Why not event-driven? Because events create coupling. If the SEO agent's completion triggers the Content agent, then a failure in the SEO agent cascades into a missed Content run. With cron, each agent runs regardless of what the others did. If the SEO agent failed on Monday, the Content agent still runs on Monday with the last good state. The system degrades gracefully instead of cascading.

The CMO as Synthesizer

Seven agents producing output three times a week generates a volume of information that no founder should read in full. The CMO agent exists to compress that volume into a single document.

On every run, the CMO reads all sub-agent briefs and state files. It writes a synthesis: which posts shipped, which keywords moved, whether any outbound prospects replied, what the Sales Lead agent flagged, and what needs the founder's attention. The founder reads one brief. Not seven.

The synthesizer is the load-bearing piece of the architecture. Without it, you have seven agents producing seven reports, and you (the founder) become the synthesizer. That is the failure mode this role exists to prevent. The moment you are manually reading every sub-agent's output and mentally stitching it together, you have recreated the coordination overhead the fleet was supposed to eliminate.

The CMO also acts as the routing layer. When the SEO agent identifies a content gap, the CMO decides whether to add it to the content queue. When the Outbound agent exhausts its prospect list, the CMO surfaces that to the founder. Sub-agents do not make cross-functional decisions. They report their findings. The CMO decides what to do about them. This is the same pattern you see in well-run human teams: specialists report up, and the manager routes work across functions.

Protecting the CMO's prompt quality is the highest-leverage maintenance task in the fleet. If the synthesis degrades (too verbose, misses a critical escalation, hallucinates about a metric), every downstream decision the founder makes is informed by bad data. We tune the CMO's prompt more carefully and more frequently than any other agent's.

What the State File Actually Contains

The Content agent's state file (docs/agents/state/content-agent-state.md) is a short, structured markdown document. It records:

• Current drafts in flight: title, file location, word count, blockers.
• Recently shipped (last 14 days): title, date, file path.
• Queue snapshot: how many pending, what is top priority, how many completed this month.
• Open questions for CMO: anything the Content agent cannot resolve on its own.
• Things to remember next session: style decisions, terminology choices, which Unsplash photos have been used (to avoid reuse), pricing figures verified against project-config.yaml.

That last section is important. Because each session starts cold, the "things to remember" section is how the agent passes institutional knowledge to its future self. If the Content agent decided in session 12 that "flotilla" should be used sparingly, it writes that down. Session 13 reads it and respects the decision. If the founder gives feedback on voice or structure, the agent records it in that section so the next session inherits the correction.

This is persistent memory implemented as a plain text file in version control. It is not elegant. It is auditable, reversible, and readable by any human who opens the file. Those properties matter more than elegance when you are running autonomous agents against a production codebase.

The Warts

This system is not perfect. Here is what I would tell you if you were sitting across the table.

The state file can grow stale. If an agent writes "open question: should we cross-link the handoff cluster?" and nobody answers for three weeks, the question sits there, session after session, until someone cleans it up. There is no automatic expiration. Maintenance is manual.

The cron cadence means the system responds in days, not hours. If a prospect replies to an outbound email on Tuesday afternoon, the Outbound agent does not see it until Wednesday morning. For a founder used to checking Slack in real time, this feels slow. It is slow. The system optimizes for consistency and auditability, not speed.

The CMO agent is a single point of failure. If its prompt is wrong, the founder's view of the entire fleet is wrong. We mitigate this by reviewing the CMO synthesis manually every morning (it takes five minutes), but the risk is real. A subtle drift in synthesis quality is harder to catch than a total failure.

And the coordination model assumes discipline. Every agent must write clean state, commit after every run, and not touch files outside its scope. If an agent's prompt drifts and it starts writing to the wrong directory, you get chaos. The fix is strict scoping rules in each agent's prompt (which files it may read, which it may write, which commands it may run) and a review process for prompt changes.

Why This Matters for Your Fleet

If you are building a multi-agent system, the coordination model is the architecture decision that will either save you or bury you. Peer-to-peer messaging between agents sounds flexible until you are debugging a chain of six handoffs at 2 AM. Event-driven triggers sound responsive until one failure cascades into a full fleet outage.

The pattern Armada Works uses (cron schedules, single-writer state files, git as the bus, a synthesizer at the top) is simple enough that you can explain it in a paragraph and audit it with git log. That simplicity is the feature, not a limitation.

If you want to see the actual repo structure and state files before deciding whether this model fits your operation, book a discovery call. We will walk you through the real system, not a diagram of it.