Peers and subagents
There are two different collaboration shapes, and they behave differently.
| Peers | Subagents | |
|---|---|---|
| What it is | Two separate top-level agents, each with its own page, channels and memory | A specialist nested inside one parent agent |
| How work moves | One agent messages the other and waits for a reply | The parent hands off a task and gets a result back |
| Memory | Each pair builds up its own running conversation over time | Runs in its own context, then reports back - the parent's conversation stays clean |
| Configured in | The Talk to Agent tab and the org chart | The Subagents tab of the parent |
Use a subagent when the work is a step inside someone else's job - research this company, draft this section, check this file. Use a peer when the other party has its own responsibilities, its own inbox and its own working memory: a support agent asking the billing agent about an invoice is two colleagues, not a manager and a helper.
Pre-built teams make this concrete. The catalog ships 19 starter teams - a manager plus the specialists it delegates to - alongside 180+ individual specialist agents you can install one at a time.
The org chart
The Org Chart section draws the whole operation. Humans sit on top with their roles; agents sit below in a reporting tree, each landing in the row for its reporting depth, with a manager centred over its reports. Subagents appear as a labelled strip inside their parent's card rather than as separate nodes, because that is what they are.
The lines between cards mean different things: a manager-to-report line, a dotted mutual co-worker line, a dashed human-to-agent access line, and an agent-to-agent messaging permission line. Header toggles turn each family on and off. Administrators can reach every agent implicitly, so their access lines are hidden by default - drawing them would bury everything else.
The chart is live. When one agent messages another, that link lights up in real time; when a parent delegates to a subagent, the specific subagent's row glows. It is the fastest way to see whether your team is actually collaborating or whether one agent is doing everything.
Navigation is trackpad-native: two-finger scroll pans, pinch or ctrl-scroll zooms toward the cursor, and double-clicking empty canvas fits the chart. Press / to search and Enter to cycle through matches. Drag a card to move it, drag its corner to resize it, and drag the middle of a connector to reroute it; your layout is saved to your account and follows you across devices, with a Reset layout button to snap everything back to automatic.
Setting an agent's place
Placement is edited on the agent's Talk to Agent tab, not on the chart itself.
- Set the manager. One agent, chosen from a type-to-filter picker that matches on name and description.
- Set direct reports and co-workers. Same picker, multiple selections. Setting one side updates the other automatically - naming an agent as your report makes you its manager without a second edit.
- Decide messaging. Allow receiving and Allow sending are each three-state: everyone, no one, or a specific list. Tick Auto-generate from org chart to derive both from the manager, reports and co-workers you just set, which is the right default for most teams.
- Optionally restrict what peers may ask for. Only execute mutating tasks for its manager means other agents get read-only service: they can ask questions, but tools that change something - sending an email, posting, writing files - only run for the manager.
Saves apply live, with no restart, and the dashboard reports how many related agents were updated by the reciprocity rule.
Visibility versus permission
At the top of the same tab is a Visibility control - None, All agents or Specific agents - which decides which peers this agent is told exist. It defaults to None, the safest setting: the agent knows about no peers except the ones it can already reach.
Making an agent aware a peer exists does not let it message that peer. Visibility only changes what the agent is told about; the messaging allow-lists decide what actually goes through. An agent that can see a peer it may not message simply knows the name exists.
Separately, a Can start conversations with other agents checkbox turns outbound messaging on or off wholesale. Unticking it genuinely revokes the ability, not just the awareness. And at the far end, an agent marked Human-only in its Access & Safety card cannot be reached by any agent at all, whatever the allow-lists say - that is the setting for an agent only people should operate.
A blocked attempt is not silent. The calling agent gets an explanation naming the org-chart restriction, usually with its own manager suggested as the route to take instead.
Watching agents work together
The Agent to Agent section organises inter-agent traffic as conversations. The left rail lists one row per pair, newest activity first, with both avatars, the latest preview, a message count and a live dot while an exchange is in flight. A peer conversation folds both directions into a single row; subagent delegations stay directional, because the target is a role rather than a colleague.
Segmented filters - All, Peer, Subagent, In flight - narrow the list, and the search box matches participant names and message bodies. Select a pair to read the full exchange with day separators and a Load older button. Each exchange shows the ask, the answer, and how long the other side took. An exchange that was never answered says No reply recorded rather than pulsing forever, which is how you spot a broken hand-off.
The sidebar item mirrors this globally: a pulse whenever an exchange is in flight, and a badge counting messages that arrived while the panel was closed.
Designing a team that works
- Start with one agent. A second agent is worth it when a distinct job with its own tools and its own inbox exists - not because the first one is busy.
- Give every agent a manager. A flat fleet with no reporting lines makes the "only for my manager" restriction meaningless, and leaves blocked calls with nowhere to be routed.
- Prefer subagents for steps, peers for jobs. If the work only ever happens as part of another agent's task, it is a subagent.
- Keep visibility tight. Every peer an agent is told about is context it carries on every turn. Specific agents beats All agents in almost every real deployment.
- Check the chart weekly. If one card lights up constantly and the rest never do, the work is not actually distributed and the extra agents are costing more than they contribute.