When people talk about making AIs communicate, they often imagine two chatbots holding a clever conversation with each other. I have found that the useful version is usually much less theatrical.

Most of my best multi-AI workflows use shared files, clear handoffs and one coordinator. Direct agent-to-agent calls are valuable, but they are only one part of the system.
I divide AI coordination into two categories:
- Indirect coordination through durable shared information.
- Direct coordination where one agent actually calls, spawns or delegates to another.
The indirect methods are less exciting and more reliable. The direct methods add speed and parallelism when the task is well bounded.
Method 1: Shared instruction files
The simplest coordination tool is a file every agent can read.
I use workspace files such as:
AGENTS.mdfor common project rules;CLAUDE.mdfor Claude-specific entry points;CODEX.mdfor Codex-specific instructions.
These define the source directories, testing expectations, deployment boundaries, documentation rules and what the assistants must never touch.
This avoids repeating the same background in every prompt. More importantly, it gives different agents the same definition of “done.”
Best for
- repository conventions;
- safety rules;
- test and build commands;
- shared definitions of authoritative files;
- cross-agent completion requirements.
Weakness
The file can become bloated or stale. Keep it short enough that agents actually receive and follow it, and link to detailed runbooks rather than pasting everything.
Method 2: Obsidian as common durable memory
Chat windows are temporary. My Obsidian vault records durable decisions, project direction, stable preferences and concise conversation outcomes.
Hermes, Claude and Codex can all read ordinary Markdown. They do not need a special live protocol to share this context.
The important rules are:
- search before writing;
- update existing authoritative notes;
- add one dated log for substantial discussions;
- link to source repositories;
- never store secrets.
Best for
- long-term context;
- decisions and reasoning;
- project and system indexes;
- handover between providers or tools.
Weakness
Shared memory is only useful if someone curates it. Agents that blindly append summaries create contradictions and duplication.
Method 3: Handoff files
For a bounded task, a dedicated handoff document is often better than a permanent knowledge note.
A good handoff contains:
- the goal;
- current state;
- completed work;
- authoritative paths;
- blockers;
- exact next actions;
- verification requirements;
- safety boundaries.
I have used handoffs when work moved between a browser session, Hermes Desktop, Claude Code and another operator. The next agent did not need the entire previous conversation; it needed a reliable operational brief.
Best for
- unfinished deployment work;
- moving between tools;
- work that needs human approval in the middle;
- temporary multi-stage campaigns.
Weakness
A handoff becomes stale after the task is complete. Archive it or update the durable project record rather than treating every old handoff as current truth.
Method 4: A shared task system or work queue
Shared memory answers “what do we know?” A task system answers “who should do what next?”
The task layer can be:
- Notion or another phone-friendly human task manager;
- a local dashboard;
- a database-backed kanban board;
- a repository issue tracker;
- a Hermes work queue for autonomous profiles.
For my own use, the human-facing system must work well on a phone. Agent-native kanban is useful for background workers, but it is not automatically the best master list for a person.
Best for
- assignment and ownership;
- status and dependencies;
- recurring work;
- separating human approval from agent execution.
Weakness
A task card should not become the only copy of important context. Link it to the project note, handoff or repository.
Method 5: One coordinator delegates to specialist agents
This is direct communication.
Hermes can delegate independent tasks to subagents. I use this for work such as:
- three independent research streams;
- a security review separate from implementation;
- parallel inspection of several projects;
- a fresh-eyes review before commit or publication.
The coordinator provides each agent with a self-contained brief. The workers return summaries, and the coordinator verifies consequential claims before acting.
Best for
- parallel research;
- independent reviews;
- bounded subtasks;
- reducing one conversation’s context load.
Weakness
A subagent has no magical awareness of the parent conversation. If the brief omits a constraint, the worker may produce a perfectly coherent answer to the wrong task.
Direct delegation is also not durable by itself. Important results still need to be written to the repository, handoff, task system or Obsidian.
Method 6: Launch independent agent processes
Sometimes the job needs a full independent process rather than a short-lived subagent.
A local dashboard can launch a fresh Hermes session with:
- a self-contained prompt;
- a defined working directory;
- a saved run ID;
- live logs;
- stop and follow-up controls.
Claude Code or Codex can also be launched for a specialised coding task while Hermes remains the coordinator.
Best for
- longer jobs;
- different toolchains;
- interactive follow-up;
- tasks that need their own session history.
Weakness
Independent processes can edit the same files. Use separate branches or worktrees, assign clear ownership and avoid simultaneous changes to shared indexes or deployment files.
Method 7: MCP and APIs
The Model Context Protocol allows an AI client to use tools exposed by an external server. This is less like two AIs chatting and more like one agent gaining a controlled capability.
Hermes can connect to MCP servers and expose their functions as first-class tools. APIs and webhooks can do something similar for specialised services or other agent runtimes.
Best for
- structured tool access;
- external services;
- stable machine-readable operations;
- capability sharing without copying data through chat.
Weakness
MCP and APIs introduce authentication, permissions, failure handling and versioning. Give an agent the narrowest tools it needs and log consequential actions.
Method 8: Messaging as an event fabric
I use Telegram extensively for completion and failure notifications. It is useful for:
- “the build finished”;
- “the site was published”;
- “this automation failed at a specific stage”;
- human approval or follow-up.
Messaging can connect humans and agents, but it should not be the durable system of record. A notification tells me something happened; the repository, task system or knowledge vault records what matters afterward.
Method 9: Scheduled and event-driven coordination
Cron jobs, webhooks and background scripts let agents act without a live chat window.
Examples include:
- scheduled briefings;
- recurring health checks;
- a script collecting data before an agent summarises it;
- a webhook launching a response to an external event;
- one scheduled job passing its latest output to another.
Best for
- recurring work;
- monitoring;
- event-triggered actions;
- predictable data-to-summary pipelines.
Weakness
Scheduled agents cannot ask clarifying questions at run time. Their prompts and safety boundaries must be self-contained, and failures need specific alerts.
My rule of thumb
I use:
- shared files for rules;
- Obsidian for durable context;
- handoff files for unfinished work;
- a task system for ownership;
- delegated agents for parallel research and review;
- MCP or APIs for controlled capabilities;
- Telegram for notifications and approvals;
- cron and webhooks for recurring or event-driven work.
If the result matters next month, it must be written back into the indirect layer. A brilliant exchange between two agents is useless if it disappears with their sessions.
Safety rules that matter
- Keep credentials out of prompts, handoffs and shared notes.
- Give each agent a bounded task and clear authority.
- Prefer read-only review agents before allowing edits or publication.
- Do not let two agents edit the same files without coordination.
- Verify external side effects—uploads, emails, deployments and submissions—rather than trusting a worker’s summary.
- Keep humans in the approval path for expensive, public or irreversible actions.
- Record durable outcomes outside the transient conversation.
The rule I keep coming back to
Making AIs work together is mostly an information-design problem. The reliable system is not the one with the most animated agent-to-agent conversation. It is the one where every participant can find the rules, understand the current state, perform a bounded job and leave useful evidence for whoever comes next.