Agent-to-Agent Communication Patterns

The most powerful workflows in the Hermes + NanoClaw architecture are not single-agent tasks but multi-agent pipelines — where one agent's output becomes another agent's input, where specialised agents handle specific subtasks in parallel, and where a coordinating agent assembles the results into a coherent outcome. The case for multi-agent orchestration comes from specialisation. A single agent asked to 'research the market, write a proposal, format it as a PDF, and send it to the client' is asked to context-switch constantly between different types of reasoning. An orchestrating agent that delegates each step to a specialised sub-agent can produce better results faster — because each sub-agent is given a focused, well-defined task. In the Hermes context, agent-to-agent communication can happen via shared file state (Agent A writes to a file, Agent B reads from it), via IPC (inter-process communication through the IPC directory), or via direct invocation through a tool that spawns a sub-agent. The specific mechanism matters less than the principle: define clear interfaces between agents — what one agent outputs, the next agent expects as input. Practical example: a research-and-briefing pipeline. Agent 1 (Research) is woken by a NanoClaw task every morning. It searches the web for mentions of your target topics, collects relevant links and summaries, and writes a structured JSON file to a shared location. Agent 2 (Editorial) is woken 10 minutes later by another NanoClaw task. It reads the JSON from Agent 1, applies editorial judgement ('is this worth including in today's briefing?'), and writes a curated summary. Agent 3 (Delivery) formats the summary for the target channel and sends it. Three specialised agents, one coherent workflow.

Multi-agent workflows introduce failure modes that single-agent tasks don't have: Agent A might not produce output before Agent B runs. Output from Agent A might be in an unexpected format that Agent B can't parse. One agent's error might cascade silently through the pipeline. Patterns that make multi-agent workflows reliable: Contract-first design: Before building any multi-agent pipeline, write down the exact format of the interface between agents. 'Agent A will write a JSON file at /workspace/group/agent-pipeline/research.json with this exact schema: { date, topics: [{ title, url, summary, relevance_score }] }.' If both agents are designed to this contract, changes to one don't break the other. Heartbeat files: Each agent in a pipeline writes a 'heartbeat' file with a timestamp when it completes successfully. The next agent checks for this file before running. If the heartbeat is older than expected (indicating the upstream agent failed or hasn't run), the downstream agent can skip the run or alert you to the failure. Idempotent tasks: Design each agent's task so that running it twice produces the same result as running it once. This makes it safe to retry on failure without producing duplicate outputs or side effects. Explicit error handling in prompts: Include in every agent's prompt: 'If you encounter an error or cannot complete the task, write a brief error summary to /workspace/group/errors/[task-name].txt and send me a message describing what failed.' Silent failures are the enemy of reliable automation. Staged complexity: Start with a single agent doing the full task. Only split into multiple agents when the single agent is consistently failing at one specific step, or when the task is time-sensitive enough to require parallelisation. Over-engineering multi-agent pipelines is a real risk — most tasks don't need more than one agent.