When you run multiple AI agents in parallel — one handling SSL certificates, another configuring email delivery, a third updating WordPress plugins — they all need to coordinate. They need to know what’s done, what’s in-progress, and what’s blocked. The obvious answer is to use your project management tool as the coordination layer. Linear, GitHub Issues, Jira — whatever your team already uses.
That’s the wrong answer.
The Rate Limit Problem
When an agent completes a chunk of work, it typically needs to update state across multiple systems — create tickets, update statuses, add comments, create documents. A single agent session might make 10-15 API calls to Linear in rapid succession. At Linear’s ~50 requests per minute limit, that’s fine for one agent. But with three agents finishing tasks simultaneously? You’re hitting rate limits within seconds.
The real problem isn’t the rate limit itself — it’s what happens during the gap. Agent A finishes configuring DKIM records and tries to update Linear, but gets rate-limited. Agent B starts its session, reads Linear for current state, and doesn’t see Agent A’s completed work. Agent B either duplicates the DKIM setup or starts a dependent task before its prerequisite is actually done.
The window between “work completed” and “state visible to other agents” is where coordination breaks.
The Pattern: Shared Memory Bus First
The fix is straightforward: write order determines coordination reliability. Instead of treating your project tracker as the source of truth, use a shared memory layer that you control — no rate limits, instant visibility, durable persistence.
The convention is simple:
- Write to shared memory first. This is your coordination bus. Every agent reads from it before starting work. No rate limits, instant cross-agent visibility. When Agent A finishes DKIM setup and writes here, Agent B sees it immediately on its next context load.
- Write to local session state second. This is the agent’s own cache — fast, but only visible to the current session. Think of it as working memory that supplements the shared layer.
- Sync to external APIs last. Linear, GitHub, Jira — these are human-facing dashboards. They can lag behind by minutes without breaking agent coordination. Space API calls 3-5 seconds apart, batch them at session end if needed.
Why This Order Matters
The key insight is that your project tracker serves two different audiences with different latency requirements:
- Agents need sub-second state visibility to avoid conflicts and duplicate work. They check state before every task.
- Humans check dashboards periodically — minutes or hours between glances. A 30-second delay in Linear updates is invisible to a human but catastrophic for agent coordination.
By making the shared memory bus authoritative and the project tracker a downstream sync target, you get the best of both: agents coordinate instantly through the memory bus, and humans see a clean dashboard that catches up within the same session.
Handling Failures
If any write fails, the rule is simple: shared memory is authoritative. If Linear is rate-limited or down, agents still coordinate correctly because they read shared memory first. The Linear sync catches up when it can — it’s a nice-to-have for human visibility, not a requirement for agent coordination.
Other practical rules we’ve adopted:
- Minimize API round-trips: Set ticket status on creation rather than creating then updating. Combine comments with status changes when the API supports it.
- Conflict detection: Before starting work, agents check shared memory for in-progress tasks touching the same resources. If another agent is mid-task on the same server or domain, wait or pick different work.
- If rate-limited, don’t retry immediately. Finish other work first, collect all pending API writes, then batch them at session end with spacing between calls.
Implementation
We built this on the Model Context Protocol (MCP). Our shared memory layer is an MCP server deployed on Cloudflare Workers — agents connect to it the same way they connect to any other tool. The key operations are simple: read context before starting, write facts/decisions/completions after finishing, and record run metadata for observability.
The memory schema is deliberately simple — facts (key-value state), decisions (architectural choices with rationale), and runs (execution logs). No complex state machines, no distributed locks. Agents are stateless between sessions; the memory bus provides continuity.
This pattern isn’t specific to any particular project tracker or AI agent framework. Whether you’re using Linear, GitHub Issues, Jira, or Notion as your dashboard — and whether your agents are Claude, GPT, or custom — the coordination principle is the same: write to your shared bus first, sync to rate-limited APIs last.
This pattern emerged from running multi-agent infrastructure automation at IKEO Group — managing WordPress deployments, OCI cloud provisioning, DNS configuration, and email delivery setup across multiple domains simultaneously. We’ll be open-sourcing the agent-memory MCP server and coordination conventions.