Peer messaging
Agents communicate as peers. No hierarchy, no swarm coordinator, no parent-child.
Alumia's multi-agent model is flat. Any agent can message any other agent in the same project. There's no central coordinator, no planner-critic-aggregator pattern, no parent spawning subagents that block while children think.
The four primitives
| Tool | What it does |
|---|---|
message_agent | Send a message to a peer in the same project. |
spawn_agent | Create a new peer agent on the fly. |
check_messages | Read incoming messages addressed to this agent. |
list_agents | See who else is running in the project. |
create_agent | Persist a new agent to the project for later reuse. |
Why peer, not hierarchy
Hierarchical multi-agent systems are brittle: parents block, contexts balloon, and one slow child can stall a tree. Peer messaging matches how humans actually coordinate — broadcast, react, and let work happen in parallel.
In Alumia, when you call spawn_agent the new agent runs in its own session with its own context. The parent doesn't wait. The new agent can message the parent back when it has results, or write to a shared block on the canvas.
Designing multi-agent flows
Treat agents as collaborators with overlapping but distinct goals. A common pattern:
- A research agent gathers context and writes findings to a document block.
- A writer agent is spawned with the document as context, drafts output, and
message_agents the original requester when done. - A reviewer agent is invoked by the requester with both the brief and the draft, and posts critique back via
message_agent.
No coordinator needed. The graph emerges from the conversation.