Design guide
Multi-agent systems.
Useful coordination starts with a clear account of who can see, decide and change what.
What makes a system multi-agent?
A multi-agent system contains several decision-making agents whose actions affect a shared task or environment. The important design question is how their decisions interact. Three agents producing independent summaries create a different coordination problem from three agents editing the same project plan.
For computer-use and phone-use agents, that environment can include applications, files, messages and persistent records. A successful local action may change what another agent should do next. Shared context needs a defined owner, a history and a way to resolve disagreement.
Choose the interaction model
Start by deciding when each agent may act. A review workflow may advance one decision at a time; a shared scheduling task may allow concurrent proposals. PettingZoo provides a useful formal reference: its Agent Environment Cycle API represents agent turns, while its Parallel API handles simultaneous actions and observations.
For an application workflow, write down the equivalent rules before selecting an orchestration framework. Define which state is shared, which observations are private, and which actions require exclusive access. Record whether messages are delivered immediately or become visible on the next turn. These choices change the problem an agent is being evaluated on.
A concrete example: coordinating a team visit
Consider a hypothetical task with three agents. A planner gathers availability, a researcher compares venues, and a reviewer checks the proposed plan. The shared record contains participants, dates, requirements and the current proposal. Each agent also retains the evidence behind its contribution.
The venue agent should not overwrite a date that the planner has just changed. Give each proposal the version of the shared record it used. Before committing a change, check that the relevant fields are still current. A stale proposal can be reconsidered without silently discarding another agent’s work.
Make completion equally explicit. A plan is ready when it satisfies the recorded constraints and the reviewer accepts it. A booking is a separate action with its own authorization. This example separates communication, decision and execution so that a trace can explain where coordination succeeded or failed.
Measure the group and the individual
| Dimension | Evidence to retain |
|---|---|
| Task outcome | The final state and checks against the original requirements. |
| Coordination | Messages, handoffs, conflicting changes and their resolution. |
| Contribution | Each agent’s observations, actions and accepted outputs. |
| Efficiency | Elapsed time, actions, resource use and repeated work. |
| Recovery | The failure, the response and the resulting task state. |
Compare the coordinated system with a simpler baseline on the same tasks and budgets. More agents add communication and scheduling costs. A useful evaluation establishes whether those costs buy better outcomes, broader coverage or more reliable recovery.
Design the difficult cases first
A useful test suite should include an unavailable agent, a delayed message, conflicting instructions and an observation that becomes stale. Decide what the system should preserve after each failure. Then check the resulting state, rather than accepting a fluent explanation as evidence of success.
Keep task definitions separate from agent instructions and preserve the environment version with every run. Repeat tasks across several starts and report the distribution of outcomes. This helps distinguish a repeatable coordination improvement from one fortunate interaction.
Where Coasty fits
Coasty brings models, environments, data and evaluation into one platform for agents that act and interact across computers and phones. Explore the Coasty platform to discuss the tasks and shared context you want to model. The examples in this guide are design patterns, not a specification of a packaged orchestration API.