Skip to main content
Agent-to-agent communication lets Traycer agents coordinate with each other. Agents can reach your other agents in the same Task, in your other Tasks, and on your other hosts. Use it when running agents need to split work, ask another agent to investigate something, get a review, or share results without losing the larger Task context. This page is the reference for what agents can do to each other and when. Other pages link here rather than repeating the rules.

​
What It Does

An agent can:
  • create a child agent, in its own Task or another Task you can edit, on its own host or another of your hosts
  • send another agent instructions, either asking for a reply or as a fire-and-forget message
  • list agents and Tasks, and read another agent’s transcript
  • rename, stop, archive, fork, or reconfigure an agent
  • claim a role, so other agents can see who owns what, when Agent roles is on in General settings
The result is still visible in the Task. Child agents appear in the Agents tree under the agent that created them, so the lineage is not hidden. A child created in another Task appears at the top level of that Task’s tree instead, so open that Task to find it. To see the messages themselves, open the Agent office.
The tree shows where each agent came from. It does not restrict which agents you can reference: referencing is not limited to a parent or a child. Dashed edges are references, which are always available inside a Task. Whether a message can actually be delivered along one of those edges depends on the rules below.

​
Lineage And Sessions

The agent that starts another agent is the parent. The new agent is the child. The child agent has its own session, model, transcript, and run state. It does not merge into the parent agent. The parent can read the result, continue the conversation, or use the child agent’s work as context for the next step. This is why agent-to-agent work shows up as hierarchy in the Agents panel instead of as one flat transcript. Hierarchy is provenance only: any agent can reference any other agent in the Task, not just its own parent or children.

​
Agent Selection

Traycer uses agent-selection instructions to choose the right coding agent, model, and reasoning effort for delegated work. Configure the global defaults in Settings > Agent selection. A workspace can refine them with .traycer/agent-selection-guide.md.

​
Three Separate Capabilities

Referencing an agent, reading its transcript, and sending it a message are different capabilities with different requirements. An agent can be fully referenceable while its transcript is unreadable from where you are, and while it cannot receive a message at all. Those are normal states, not errors. Referencing is the broad capability. Transcript access is narrower, and delivery is narrowest.

​
Agent-To-Agent Support

This table shows what each coding agent can do on each interface. Can send means the agent has the agent-to-agent tools: it can create agents, send messages, list agents, and read transcripts. Can receive means it has an inbox, so other agents can message it. Read this by interface, not by product:
  • On the Chat interface, every coding agent can send and receive.
  • On the Terminal interface, only Claude Code has an inbox. Codex and OpenCode Terminal agents can send, but they can’t receive, so:
    • they can’t ask for a reply. They send fire-and-forget messages and read the other agent’s result from an artifact or its transcript.
    • another agent can’t create a Codex or OpenCode Terminal agent, because the new agent could never receive its brief.
  • Which coding agents can back the Terminal interface at all is listed in Agents & Models.

​
Messages

A message can go to any of your own agents that can receive:
  • In the same Task, or in another Task you can edit, including a Task someone shared with you as an editor.
  • On any of your hosts. The message is sent from the host the sending agent runs on. If the receiver runs on a different one of your hosts, Traycer delivers the message through the cloud, and the receiving host picks it up from there. The send returns queued once the cloud has accepted the message; this does not confirm delivery to the receiving agent. The sender’s card shows no visible delivery badge or note unless something fails, apart from a note when the receiving host looked offline at send time. The receiving host can collect the message when it comes back online. If it has not collected the message within 24 hours, the message expires: the card reads Not delivered, and a sending agent waiting for a reply is told.
A message is rejected, not queued, when:
  • the receiver has no inbox (a Codex or OpenCode agent on the Terminal interface)
  • the receiver belongs to another user, including a collaborator’s agent in a shared Task
  • the receiver’s host has been revoked from your account
  • the sender asks for a reply but has no inbox for the reply to reach
  • the message is larger than 16 MB
When a message asks for a reply, the reply comes back to the sending agent’s inbox, in the sender’s own Task, even when the receiver is in another Task.

​
Transcripts

  • Your Chat agents can be read from any of your hosts. A Chat agent that runs on another host may be read from its synced copy. That copy is read-only and says it can lag the live chat.
  • Your Terminal agents are read on the host that runs them. From another host, Traycer sends the read to that host, so it has to be reachable. See Durability Is Not Availability.
  • In a shared Task, another user’s Chat agent is readable, read-only, while they share the Task. Their Terminal agents are not readable.
  • In another Task, reading needs editor access to that Task.

​
Durability Is Not Availability

Closing a Terminal surface does not erase the agent’s history. Traycer reads a Terminal-interface transcript from the coding agent’s own session history rather than from terminal scrollback, so the record survives the terminal, and the app, closing. That is durability, not universal readability. Reading it still requires the host that runs the agent to be reachable and the coding agent’s own session history to still be present. If either is missing, the transcript read fails rather than returning a partial or empty result. Plain Terminals do not take part in any of this. They are shell sessions, not agents. For the broader distinction, see Terminal Agents VS Terminals.

​
Agent Office

The Agent office shows a Task’s agents and the messages between them, across all your hosts. To open it, either:
  • in the Agents panel header, open More agent actions (⋯) and choose Agent office, or
  • open the pane opener with ⌘T / Ctrl+T, or from an empty pane, and choose Agent office.
It opens as a tab. A Task has one Agent office; opening it again brings the existing tab forward.

​
Office And Graph

Switch views with the Office / Graph toggle.
  • Office draws each agent as a person at a desk. Each host is a floor, each top-level agent has a cabin, and its child agents sit in pods inside it. Messages travel as envelopes. The Office view menu switches between layouts, and the zoom buttons include Fit the office floor.
  • Graph draws agents as nodes and messages as edges between them.
Archived agents stay in view, marked as archived. In the Graph view, agents from another Task that exchanged messages with this one are marked Other task. In the Office view, what people and desks are doing shows the agent’s state. The info button, What the office signals mean, opens the full key.

​
Details And Replay

  • Select an agent to see its details and messages. Open agent opens its conversation.
  • Select a message edge to see every message between that pair: each one is a Request, Reply, Notice, or Created event.
  • The timeline at the bottom replays what happened. Play timeline starts playback, the speed button changes its rate, and Follow live returns to the present, where the timeline reads Live.
Agent office › Default view in Appearance settings sets the office layout for Tasks where you haven’t picked one.