Shared context for multi-agent teams

When you run several OpenClaw agents on crons—SEO, content, strategy, and so on—they can be individually strong but collectively disconnected. One agent finds a high-value keyword; another writes content about something else. The fix is not more agents or complex messaging: it’s one shared directory that every agent can read and write, so they share priorities, outputs, and feedback. This page shows how to do that with a single directory and symlinks into each agent’s workspace. No custom protocol, no N² connections—just files and one folder.

Multiple agents on schedules often run in silos. Agent A writes its report to its own workspace; Agent B never sees it. You get great SEO insights in one place and unrelated content in another. Coordination then depends on you—or on building agent-to-agent messaging, handoffs, and state machines. That scales poorly: N agents mean N² possible connections. The pattern that scales is the one real teams use: a shared source of truth everyone reads. Not “agents talking to each other,” but “agents reading and writing the same files.”

Create a single directory (e.g. shared-context/) and symlink it into each agent’s workspace. Same path relative to each agent, same inode on disk—so when one agent writes to shared-context/priorities.md, every other agent sees the update on its next run. No API, no sync daemon. You can put priorities, each agent’s outputs, feedback you give (approve/reject), KPIs, and a synthesis area in that directory. Each agent’s instructions: “Before every action, read shared-context/.”

One common layout that works for 3–10 agents:

• priorities.md — Current priority stack (e.g. from a morning voice standup). All agents read this so work aligns with what you said matters.
• agent-outputs/ — Each agent drops its reports or findings here (e.g. oracle-seo-2026-02-09.md). Other agents read these to coordinate (e.g. content agent uses SEO findings).
• feedback/ — Your approvals and rejections (e.g. “not high intent”) in a simple format. Every agent reads this so one decision teaches the whole team.
• kpis/ — Live metrics or snapshots every agent can reference.
• calendar/ — Today’s meetings or relevant contacts if agents need context.
• content-calendar/ — What’s planned, published, and where there are gaps.
• roundtable/ — Daily or weekly cross-agent synthesis (one agent can curate this).

Adjust names and subfolders to your domains (e.g. agent-outputs/seo/, agent-outputs/content/ as you add agents).

Assume each agent has its own workspace directory (e.g. /oracle/workspace, /flash/workspace, /alfred/workspace) and one shared directory lives at /shared-context/. From the host, run:

ln -s /shared-context/ /oracle/workspace/shared-context
ln -s /shared-context/ /flash/workspace/shared-context
ln -s /shared-context/ /alfred/workspace/shared-context

That’s it. Each agent now has workspace/shared-context/ pointing at the same directory. Verify with ls -i: the inode number for shared-context/priorities.md should be identical from inside each workspace. Same file, three (or more) agents.

ls -i /alfred/workspace/shared-context/priorities.md
ls -i /oracle/workspace/shared-context/priorities.md
ls -i /flash/workspace/shared-context/priorities.md

If the inode is the same, all agents are reading and writing the same file. Add “Read shared-context/ before every action” (or similar) to each agent’s SOUL or AGENTS.md so they use it on every cron run.

When you approve or reject an agent’s suggestion, write that to shared-context/feedback/ (e.g. a JSON or Markdown file per week). Every agent’s next run can read that folder. So when you reject “tool-query keywords” for the SEO agent, the content agent can also avoid that angle; when you approve a content type, both can align. One place, one source of truth. Over time the folder becomes a small history of decisions that the whole squad respects.

It’s tempting to build agent-to-agent messaging, handoff protocols, or state machines. For 3 agents that’s already complex; for 10 or 30 it’s fragile and slow. The robust pattern is: one shared “wiki” (the directory) and specialized readers (each agent). Not “Agent1 sends to Agent2,” but “Agent1 and Agent2 read and write the same directory.” Same idea as a company: marketing and sales don’t send API calls to each other; they read the same docs and update the same boards.

3 agents: One shared-context/, symlink into each workspace. One curator agent (e.g. “Alfred”) can summarize and clean roundtable/ or priorities.md so it doesn’t become a junk drawer.

10 agents: Add subdirectories under agent-outputs/ (e.g. seo/, content/, sales/). Same layout, same symlink pattern. New agent: create workspace, add one symlink, add “read shared-context” to its instructions.

Many more: You can introduce read permissions (not every agent needs every file), write queues (agents submit to staging, curator merges), and domain namespacing (shared-context/seo/, shared-context/sales/). Optionally put shared-context/ under version control so you can see what changed, when, and why. The architecture stays “shared files, specialized readers.”

1. Week 1: Get one agent doing something useful and put it on a cron. See Multi-Agent Team and Automation.
2. Week 2: Add a second agent in a different domain. Create shared-context/, add priorities.md and agent-outputs/. Symlink into both workspaces. Instruct both to read shared-context before acting.
3. Week 3: Add the feedback loop. When you approve or reject something, write it to shared-context/feedback/. Point both agents at that folder so they learn from your decisions.
4. Week 4: Add a synthesis agent that reads all outputs and writes a short roundtable or digest. You now have one shared brain and many hands.

Start with 3 agents and this structure before scaling. Building for 100 agents on day one is the same trap as “we need microservices” with two developers.