Multi-Agent Coordination Architecture: How to Keep 4 AI Agents from Stepping on Each Other
Table of Contents
- One agent is useful, four agents are a disaster
- The fix: borrow the methods used to manage human teams
- Layer 1: Role definition (IDENTITY.md)
- Layer 2: Shared memory (Markdown files)
- Layer 3: Content Relay (cross-agent handoffs)
- Layer 4: Team Briefing (daily alignment)
- Layer 5: Weekly strategy meeting (Weekly Strategy)
- Layer 6: Cross-Agent Engagement
- Architecture overview
- Why markdown and not a database
- Next post
Disclosure: Ultra Lab, MindThread and Ultra Advisor are products of the same group, Ultra Creation (傲創實業).
Update, 27 September 2026. This post describes the OpenClaw fleet as it ran when the post was written in April 2026. OpenClaw's agent functions were retired in June 2026 and the fleet moved to Hermes Agent; the schedules and coordination mechanisms below are how it worked at the time.
One agent is useful, four agents are a disaster
When I had only one agent, everything was simple. It published its posts, I read my reports, and each of us did our own thing.
Then I added a second agent.
On day two, the two agents published posts on almost the same topic. One wrote "The Future Trends of AI Agents", the other wrote "Where AI Agents Are Heading in 2026". Essentially the same article, just phrased differently.
Once I got to four agents, the problems grew exponentially:
- Duplication: several agents writing about the same topic
- Contradiction: one agent says "we focus on AI security" while another pushes "social media automation"
- Resource conflicts: simultaneous API calls hitting rate limits
- Everyone going their own way: no agent knows what the other agents are doing
It is like hiring four interns, never letting them hold a meeting, never giving them shared documents, and never telling them the others exist. The result is chaos.
The fix: borrow the methods used to manage human teams
Eventually it clicked: the multi-agent coordination problem is, at its core, a team management problem.
How do human teams collaborate?
- Clear division of labour: everyone has a clear role and clear responsibilities
- Shared information: documents, meetings, and Slack keep everyone's status in sync
- Regular alignment: weekly meetings, daily reports, strategic planning
- Handoff mechanisms: when one person finishes something, another person can pick it up
An AI team works exactly the same way, except "documents" become markdown, "meetings" become cron jobs, and "Slack" becomes a shared directory. The open-source TradingAgents framework applies the same idea to a trading firm, running its analysts, researchers, trader, risk managers and portfolio manager as separate agents; we break down its roles in our roundup of open-source AI finance repos on GitHub.
Layer 1: Role definition (IDENTITY.md)
Every agent has its own IDENTITY.md that defines who it is:
# Main Agent: UltraLabTW
## Role
CEO / strategic thinker
## Expertise
- AI industry trend analysis
- Brand strategy and positioning
- Open-source ecosystem observation
## Tone
Professional but not cold. Like an experienced tech lead sharing insights.
## What it does not do
- No talking about specific product features (that is the other agents' job)
- No how-to tutorials (unless they are at the strategy level)
- No repeating topics other agents have written about recently
The other three agents each have their own positioning too:
| Agent | Role | Focus area |
|---|---|---|
| Main | CEO / strategy | Industry trends, brand thinking |
| MindThread | Marketing | Social media management, content strategy |
| Probe | Technical | AI security, vulnerability analysis |
| Advisor | Finance | Personal finance knowledge, market observation |
The key is not what the file says, but that it spells out "what it does not do." Telling an agent what it should not do matters more than telling it what it should do. This is the first line of defence against overlap.
Layer 2: Shared memory (Markdown files)
This is the core design of the whole multi-agent architecture: markdown files used as shared memory.
Why not a database? Why not a vector store? Why not a message queue?
Because markdown has a few advantages nothing else can replace:
- LLMs understand it natively: no serialize/deserialize step, it goes straight into the prompt
- Human-readable: I can open it at any time and see what the agent is thinking
- Git-friendly: changes can be tracked, rolled back, and diffed
- Zero dependencies: no services to run, a file system is enough
Each agent's workspace contains these shared files:
workspace/
├── RESEARCH-NOTES.md ← daily intel (produced by research-chain)
├── POST-PERFORMANCE.md ← performance data (produced by post-stats)
├── COMPETITOR-INTEL.md ← competitor analysis (produced by competitor-watch)
├── STRATEGY.md ← this week's strategy and OKRs
├── INQUIRY-STATUS.md ← customer inquiry status
└── HEALTH-STATUS.md ← system health status
These files are updated automatically by different cron jobs:
05:00 research-chain.sh → updates RESEARCH-NOTES.md
06:30 competitor-watch.sh → updates COMPETITOR-INTEL.md
22:00 post-stats.sh → updates POST-PERFORMANCE.md
every 6h inquiry-tracker.js → updates INQUIRY-STATUS.md
every 1h health-monitor.sh → updates HEALTH-STATUS.md
Before posting, each agent reads all the relevant markdown files. That means every agent knows:
- What happened in the industry today (RESEARCH-NOTES)
- What kinds of posts have performed well recently (POST-PERFORMANCE)
- What competitors are doing (COMPETITOR-INTEL)
- The company's current strategic direction (STRATEGY)
This is the essence of the Pre-Compute architecture: the intelligence is prepared in advance, and the agent is only responsible for thinking and producing.
Layer 3: Content Relay (cross-agent handoffs)
Not duplicating each other is not enough. Real teamwork means when one agent finishes something, another agent can carry it forward.
That is what the Content Relay Queue is for.
The mechanism is simple: after an agent publishes a post, it can put a message into the relay queue:
# content-relay.json
[
{
"from": "probe",
"to": "main",
"message": "剛發了一篇 OWASP Top 10 分析，適合從策略角度展開",
"post_id": "abc123",
"timestamp": "2026-04-14T07:00:00Z"
}
]
When the next agent runs, it checks whether any relay is addressed to it:
# Check whether any relay is addressed to me
my_relays=$(jq "[.[] | select(.to == \"$AGENT_NAME\")]" \
"$DATA_DIR/content-relay.json")
if [ "$my_relays" != "[]" ]; then
# Add the relay content to the prompt
RELAY_CONTEXT="你的隊友最近做了這些事：
$my_relays
考慮是否從你的角度延伸。"
fi
This creates a kind of emergent collaboration. I don't need to hard-code "after probe writes a security analysis, main writes a strategy post." I only need the relay mechanism to exist, and the agents decide for themselves whether to pick up the handoff.
What it looks like in practice:
Probe 07:00 → posts: OWASP Agentic Top 10 vulnerability analysis
→ relays to Main: "a good fit to expand from an enterprise strategy angle"
Main 08:00 → reads the relay
→ posts: Why your company needs an agent security strategy (citing Probe's analysis)
→ relays to MindThread: "could make a social media version as a summary"
MindThread 09:00 → reads the relay
→ posts: The 10 biggest AI agent risks in one graphic
One piece of content, three angles, three posts. I didn't plan this. The relay mechanism let it happen naturally. When we later audited this pipeline, we found all six messages in the queue addressed to Main, and the gateway Main ran on was eventually shut down to save money while the senders kept adding to the queue.
Layer 4: Team Briefing (daily alignment)
Every morning, a script called team-context.sh generates a fleet briefing:
# Aggregate from each source
BRIEFING=""
BRIEFING+="## 客戶動態\n$(tail -20 INQUIRY-STATUS.md)\n"
BRIEFING+="## 昨日績效\n$(tail -20 POST-PERFORMANCE.md)\n"
BRIEFING+="## 競品動態\n$(tail -15 COMPETITOR-INTEL.md)\n"
BRIEFING+="## 系統狀態\n$(tail -10 HEALTH-STATUS.md)\n"
echo -e "$BRIEFING" > fleet-briefing.md
This briefing is injected into every agent's prompt. It amounts to holding an all-hands meeting every morning, without anyone having to show up.
Layer 5: Weekly strategy meeting (Weekly Strategy)
Every Sunday at noon, weekly-strategy.sh does something more interesting:
- It asks each of the 3 agents separately: "What do you think we should do next week?"
- It collects the three proposals
- It hands them to the Main agent (the CEO role) for the final synthesis
# Step 1: each agent makes a proposal
mindthread_proposal=$(ask_agent "mindthread" \
"根據本週績效和趨勢，你建議下週的內容策略是什麼？")
probe_proposal=$(ask_agent "probe" \
"根據最新的安全趨勢，下週應該關注什麼？")
advisor_proposal=$(ask_agent "advisor" \
"從市場和競品角度，下週有什麼機會？")
# Step 2: the CEO synthesises
strategy=$(ask_agent "main" \
"以下是團隊的提案，請綜合成下週策略：
行銷提案：$mindthread_proposal
安全提案：$probe_proposal
市場提案：$advisor_proposal
請輸出：3 個優先事項 + 每個 agent 的具體任務")
echo "$strategy" > STRATEGY-NEXT-WEEK.md
Cost: roughly 5 LLM calls. Once a week.
Result: the agents no longer each do their own thing; they share one weekly strategy. And I didn't write that strategy. They worked it out among themselves.
Layer 6: Cross-Agent Engagement
Every Tuesday and Friday, the agents do something quite interesting: they reply to each other's posts.
# cross-engage.sh
# Rule: only reply to other agents' posts, never to your own
for agent in main mindthread probe; do
others=$(get_other_agents "$agent")
target_post=$(get_recent_post "$others")
reply=$(generate_reply "$agent" "$target_post" \
"從你的專業角度，對這篇文章提出一個有建設性的觀點")
post_reply "$reply" "$target_post"
done
This creates a conversation that looks very natural: the security expert replies to a strategy post with "From a security angle, I'd like to add…", and the marketing expert replies to a security analysis with "This point is a really useful reference for brand promotion…"
It is not fake engagement. It is different roles in the same company showing their professional depth in public. Replies between agents need limits, though: when we let 4 agents reply to each other freely on Discord, token usage blew up, and we ended up setting rules for who may speak anytime and who only answers when @-mentioned or when relevant data appears.
Architecture overview
┌─────────────┐
│ Weekly │
│ Strategy │ ← every Sunday
└──────┬──────┘
│
┌──────▼──────┐
│ STRATEGY │
│ .md │
└──────┬──────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
┌───▼───┐ relay ┌─────▼─────┐ relay ┌─────▼─────┐
│ Main │ ◄──────── │ Probe │ ────────►│ MindThread│
│ (CEO) │ │ (Security)│ │ (Marketing)│
└───┬───┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└──────────┬──────────┴──────────────────────┘
│
┌──────▼──────┐
│ SHARED MEM. │
│ RESEARCH │
│ PERFORMANCE │
│ COMPETITOR │
│ HEALTH │
└─────────────┘
Six layers, each solving one problem:
| Layer | Solves | Mechanism |
|---|---|---|
| IDENTITY | Role overlap | Clearly define what to do and what not to do |
| Shared memory | Information silos | Markdown files + automatic cron updates |
| Content Relay | Everyone going their own way | JSON queue + automatic handoffs |
| Team Briefing | Lack of context | Daily summary injected into the prompt |
| Weekly Strategy | No direction | Agent proposals + CEO synthesis |
| Cross-Engage | Looking isolated | Replying to each other to build conversation |
Why markdown and not a database
I know a lot of people will think at this point: "Why not Redis? Why not Postgres? Why not a vector store?"
Because:
- The agent itself is a language model, and markdown is its most natural input format
- I only have one machine, and every extra service is one more thing to maintain
- When debugging, I can just
cat RESEARCH-NOTES.mdand see the agent's "thoughts" - The cost is $0, no cloud services required
When your scale is 4 agents and 100 operations a day, markdown is entirely sufficient.
If I ever need to manage 40 agents, I'll consider a database then. Don't build architecture for problems that don't exist yet.
Next post
The agents now have roles, intelligence, and a collaboration mechanism. But one problem is still unsolved: quality.
How do you make sure automatically produced content isn't garbage? How does an agent know by itself whether it wrote well? How do you lift quality above "readable" without adding too much cost?
Next: Automated AI Content Doesn't Have to Be Junk: Three Quality Gates in Practice
This is part 4 of the "An AI Team for a One-Person Company" series. Part 1 · Part 2 · Part 3
All source code: GitHub: free-tier-agent-fleet
FAQ
When several AI agents run at once, how do you stop them from writing about the same topics?
In this architecture every agent has an IDENTITY.md that defines its role, and the key part is spelling out what it does not do, such as no talking about specific product features and no repeating topics other agents have written about recently. Telling an agent what it should not do matters more than telling it what it should do. This is the first line of defence against overlap.
Why use Markdown instead of a database or vector store as shared memory for multiple agents?
LLMs understand Markdown natively, so it goes straight into the prompt with no serialize/deserialize step. It is human-readable, so you can open it at any time and see what the agent is thinking. It is Git-friendly, so changes can be tracked, rolled back and diffed. And it has zero dependencies: no services to run, and the cost is $0. At a scale of 4 agents and 100 operations a day, markdown is entirely sufficient.
How do AI agents hand work off to each other? What is a Content Relay?
After an agent publishes a post, it can put a message into the relay queue (content-relay.json) saying which agent it is for and which angle would be a good fit to expand on. When the next agent runs, it checks whether any relay is addressed to it and, if so, adds it to the prompt. The agent then decides for itself whether to pick up the handoff, so nothing about who follows whom has to be hard-coded.
How do multiple AI agents stay aligned on information and strategic direction every day?
This describes the setup when the post was written in April 2026; OpenClaw's agent functions were retired in June 2026 and the fleet moved to Hermes Agent. Every morning, team-context.sh aggregates customer activity, yesterday's performance, competitor activity and system status into a fleet briefing that is injected into every agent's prompt. Every Sunday at noon, weekly-strategy.sh asks each of the 3 agents what to do next week and hands the proposals to the Main agent, in the CEO role, to synthesise into next week's strategy. That costs roughly 5 LLM calls, once a week.