Agent Communication — Experience
This page is about what team coordination feels like when you watch an Agentweaver team work. The surprising part, the first time you see it, is what you don't see: there is no chat window where agents talk to each other. No agent DMs another agent. No negotiation thread. Yet the team clearly coordinates — work splits up, knowledge accumulates, boundaries get respected.
That is by design. Agents coordinate through a shared brain and a coordinator, not through conversation. This page walks through what that looks like on screen and which surfaces you use to follow along. For the reasoning, see the Agent Communication deep dive; for the exact tools and endpoints, see the Agent Communication reference.
What you watch: three views, no chat
You follow a working team through three places, each corresponding to one coordination channel:
| You look at… | To see… | Channel |
|---|---|---|
| The Decisions page | Proposals arriving in the inbox and hardening into the ledger | Shared state |
| The Team Memory page | Learnings accumulating across agents | Shared state |
| The Coordinator graph | A goal fan out into subtasks and results flow back up | Handoff |
None of these is a conversation. They are a shared record and a topology.
Decisions appearing in the inbox, then the ledger
Open the Team Memory page and select the Decisions tab. This is the team's governance view, and it is split into two zones: proposed decisions (the inbox) and finalized decisions (the ledger).
While agents work, you watch decisions move from left to right in your mind's eye:
- An agent discovers something that should constrain the whole team — say, "use the existing auth library, don't add a new one." It doesn't announce this to other agents. It submits a proposal to the inbox.
- The proposal appears as "Proposed — awaiting Coordinator," carrying the agent's name, type, and rationale, with Merge / Promote and Reject actions.
- When the proposal is accepted, it becomes a canonical decision in the finalized list — title, type, agent, content, and rationale — with the audit link back to the proposal retained. Rejected proposals stay visible too, so the record explains what the team declined.
Acceptance and rejection require a project owner or verified Coordinator run. Only active, approved architectural and scope decisions are eligible as compiled team boundaries; being in the finalized list is not sufficient by itself. The compiler serializes the content as untrusted historical JSON data, not executable instructions. The mechanics behind this are in the Memory & Decisions deep dive and the Memory reference.
Memories accumulating across the team
Switch to the Agent Memory tab on the same page. Here you watch the team's knowledge grow entry by entry: each item shows the agent name, importance, type, created time, and content. Early in a project this is sparse ("No agent memory recorded yet"); as agents run, learnings and patterns pile up.
The cross-agent part is what makes it coordination rather than private note-taking:
- Search spans the whole project. You (and agents) can search memory across all agents, not just one — so a useful learning is findable even if the agent that recorded it was later re-roled, renamed, or retired.
- Cross-team sharing requires approval. A
cross-teamtag alone is insufficient. Cross-agent selection requires approved, high-importance learning or pattern records, subject to selection budgets. Legacy records are excluded even for their named agent.
Recording a useful observation makes it findable, not automatically authoritative. An eligible approved observation can later be selected for another agent's context without peer messaging. Coordinator children may receive the narrower decisions-only context instead of the full memory stack. This is the Team, Casting & Memory experience in action; the read-side compilation is documented in the Memory reference.
The coordinator graph: handoffs you can see
Start a coordinator run and open its graph. This is where the second channel — handoffs — becomes visual. Define Outcome drafts an OutcomeSpec and pauses for confirmation; Direct and unattended pickup skip that manual gate. The goal decomposes into subtask nodes connected by dependency edges in a top-down layout.
As work runs, the graph animates:
- Independent subtasks light up in parallel; dependent ones wait for their prerequisites — you can see the ordering.
- Each node carries a status label — Dispatching, Awaiting assembly, Assembling, In review, Complete, Blocked, Failed — projected live from the run stream.
- Subtask cards also surface the child run's cost chip when usage exists and the executing sandbox pod chip when the run is in Kubernetes.
- When a child needs a clarifying answer or a tool approval, the request surfaces on the coordinator, not on a sibling. You answer once, in one place, and the answer routes back to the child that asked. Tool approvals and run-level automation options are durable, so a different API replica can receive the click and the child worker still resumes with the same decision.
Dependency arrows between subtasks mean scheduling prerequisites, not peer chat. The coordinator dispatches work and receives results for assembly; layout alone is not proof of communication or transport behavior. The full topology, steering controls, and assembly flow are covered in the Coordinator orchestration experience and Coordinator Internals.
Steering goes through the coordinator
If you want to change direction mid-flight, you steer through the coordinator — Stop, Redirect, or Amend from the graph toolbar or a subtask card. You target one child or broadcast to all active children. You never reach into one agent to have it renegotiate with another; the coordinator relays your direction at the child's next turn boundary.
Why you never see agents "chatting"
Put together, the experience makes the design legible:
- Agents leave records, not messages. Proposals land in the inbox; learnings land in memory. You read state, not a transcript.
- The coordinator is the only meeting point. Work fans out from it and results flow back to it. There is no side channel between workers.
- Eligible boundaries inform future context. Active approved architectural and scope decisions can be compiled from the database without peer conversation.
This is what makes a team's behavior auditable and repeatable: you can always answer "why did the team do that?" by looking at the decisions ledger, the memory log, and the coordinator graph — three durable views instead of an ephemeral chat.
Where execution happens is a separate concern
When an agent turn uses pod-per-run execution, a single leaf turn is remoted from the worker to a sandbox pod over A2A, while the orchestration graph and its gates stay in the worker. That is execution plumbing — where a turn runs — and it has nothing to do with how the team coordinates. The governance model is the same, but the UI can show each node's executing pod and visible transport failures. A pod chip is placement information, not peer communication. If you want to understand that layer, see the A2A bridge deep dive and A2A reference. A2A is leaf-turn execution transport, not peer chat between team members.
Related reading
- Agent Communication deep dive — the model and the reasoning.
- Agent Communication reference — the MCP tools and API endpoints behind each view.
- Team, Casting & Memory experience — the Decisions and Team Memory pages in depth.
- Coordinator orchestration experience — the coordinator graph, steering, and assembly.
Diagram details and constraints
| Element | Contract |
|---|---|
| title | Handoffs, not peer chat |
| subtitle | The Coordinator owns the dependency frontier and assembles child results. |
| group-title0 | Intent → execution contract |
| group-title1 | Children and assembly |
| Human goal | Human goal |
| Human goal | Define the desired outcome |
| Human goal | intent input |
| OutcomeSpec | OutcomeSpec |
| OutcomeSpec | Confirm before dispatch |
| OutcomeSpec | confirmation gate |
| WorkPlan DAG | WorkPlan DAG |
| WorkPlan DAG | Subtasks + dependencies |
| WorkPlan DAG | eligible frontier |
| Child run A | Child run A |
| Child run A | One assigned subtask |
| Child run A | isolated worktree |
| Child run B | Child run B |
| Child run B | Another eligible subtask |
| Collective assembly | Collective assembly |
| Collective assembly | Integrate settled work |
| Collective assembly | one reviewed integration |
| e1 | draft |
| e2 | confirm |
| e3 | dispatch A |
| e4 | dispatch B |
| e5 | result A |
| e6 | result B |
| assurance-title | DEPENDENCIES ARE CONTROL |
| assurance-line1 | A dependency edge is scheduling, not a conversation channel. |
| assurance-line2 | A2A transports one agent turn between worker and sandbox; it is not peer chat. |
| Human goal | Input |
| Human goal | Desired outcome |
| Human goal | Scope |
| Human goal | Human intent |
| Human goal | Gate |
| Human goal | Confirm or revise |
| Human goal | Owner |
| Human goal | Coordinator intake |
| OutcomeSpec | State |
| OutcomeSpec | Persisted contract |
| OutcomeSpec | Fields |
| OutcomeSpec | Scope / assumptions |
| OutcomeSpec | Human confirmation |
| OutcomeSpec | Next |
| OutcomeSpec | Workflow selection |
| WorkPlan DAG | Model |
| WorkPlan DAG | Subtasks + edges |
| WorkPlan DAG | Bounded assignee |
| WorkPlan DAG | Ready |
| WorkPlan DAG | Dependencies satisfied |
| WorkPlan DAG | Store |
| WorkPlan DAG | Persisted WorkPlan |
| Child run A | Binding |
| Child run A | ParentRunId / SubtaskId |
| Child run A | Files |
| Child run A | Per-child worktree |
| Child run A | Charter + decisions |
| Child run A | Output |
| Child run A | Result to parent |
| Child run B | Eligible frontier only |
| Child run B | Failure |
| Child run B | Blocks dependents |
| Child run B | Chat |
| Child run B | No sibling channel |
| Collective assembly | Settled child branches |
| Collective assembly | Action |
| Collective assembly | Integrate collective work |
| Collective assembly | Gates |
| Collective assembly | Configured checks |
| Collective assembly | Review |
| Collective assembly | One human decision |
| goal | Outcome, scope, assumptions; Coordinator drafts the contract |
| spec | Human confirms or revises; Persisted intent, not execution |
| plan | One owner per bounded subtask; Only satisfied dependencies run |
| a | Active decisions + charter; Result returned to Coordinator |
| b | Parallel only when eligible; No direct child-to-child chat |
| assembly | Child results flow upward; Failed / RAI child blocks dependents |
| notes | DEPENDENCIES ARE CONTROL; A dependency edge is scheduling, not a conversation channel.; A2A transports one agent turn between worker and sandbox; it is not peer chat. |
| groups | Intent → execution contract; Isolated work → collective assembly |