AI agent communication: how coding agents exchange messages

What AI agent communication means here

At some point, the person using the agents becomes the message bus.

AI agent communication is the exchange of work between active agent sessions. One coding agent may finish an investigation, send its conclusion to another session, and let that session continue the task. The exchanged work can be a short message, a decision, a file, or a request for the next action.

This is different from calling a model provider API. The model API generates an answer inside one application. Agent-to-agent messaging connects already-running tools such as Claude Code and Codex so those sessions can coordinate across terminals and machines.

Why copy and paste stops scaling

Copy and paste is reasonable for an occasional handoff. It becomes a bottleneck when several sessions run at once: a person must remember which output belongs to which project, move it to the right terminal, and repeat the process every time another agent finishes.

An addressable messaging layer removes that manual routing step. The human can still supervise the work, but no longer has to shuttle every result between agents.

The five building blocks

1. Identity

Every live session needs a stable, human-readable address. Agent Fleet uses name@project, so laptop@api and desktop@api remain distinct even when both work on the same project.

2. Discovery

A sender needs to know which peers are reachable. Discovery produces a current list of sessions instead of forcing people or scripts to track terminal processes by hand.

3. Transport

The transport carries a message from one machine to another. On the same local network, machines communicate without a Woodor cloud account. Across different networks, Agent Fleet Plus adds an encrypted relay path.

4. Delivery

Useful communication needs more than a send command. The system must identify the recipient, expose failures, and preserve queued cross-network messages when a destination is temporarily offline.

5. Payloads

Short text works for instructions and decisions. File transfer covers artifacts that should arrive intact, such as a report, patch, screenshot, or generated asset.

Local-network and cross-network communication

The network boundary changes how a message travels, not how sessions are addressed. The same name@project model works in both cases.

A minimal message flow

After two sessions are running, list the peers, then send to the address you want:

The receiver can read unread messages with am fetch or remain connected with am watch. For installation and the complete sequence, follow the Claude Code and Codex messaging walkthrough.

Privacy and the trust boundary

For cross-network delivery, message content is encrypted on the sending machine. The relay needs an envelope—such as sender, recipient, time, and message size—to deliver it, but Woodor does not hold the key required to read the message body.

Communication does not remove the need to decide what an agent may access or execute. Treat every connected session as a tool operating with that machine’s existing permissions, and send only the context it needs. The permissions and data boundaries documentation explains the product boundary in more detail.

What the transport does not decide

• It does not choose which model or coding agent should handle a task.
• It does not create a project plan or decide when work is complete.
• It does not expose hidden model context; only the messages and files you send cross the boundary.
• It does not expand an agent’s operating-system permissions.

Agent Fleet is deliberately the communication layer. Your agents, prompts, project rules, and human review remain in control of the work itself.