Imagine a service team receiving a message: “The heating is out at our office. Can someone come today?” Someone needs to work out the location, what is broken, whether the request is urgent, and what the team can actually offer. Then a person may need to confirm the appointment.
It is tempting to draw four agents straight away. An intake agent, a scheduling agent, a policy agent, and a customer reply agent. That diagram looks impressive. It also gives you four places to lose context.
- 01 / MESSAGEDescribe the problem
- 02 / AGENTStructure the request
- 03 / RULESCheck real availability
- 04 / HUMANApprove the booking
Start with the job, not the agent count
Write down the decisions first. Which details can be extracted from the message? Which facts must come from a system of record? Which rules are fixed? Which decision needs a person?
For this example, one AI agent could turn the message into a proposed request: address, issue, urgency, and any missing information. A normal service can check the service area and available slots. A person approves the booking before a promise goes to the customer. That may be the whole first version.
A rule does not become more useful just because it is wrapped in an agent. If the answer is a fixed calculation or policy check, keep it deterministic and testable.
When a second agent earns its place
Now suppose scheduling is owned by another team. It has its own service, release cycle, and permissions. The intake side should not need to know how that team finds a slot. It should send a clear task and get a clear answer. That is a useful boundary for agent-to-agent communication.
Google's cross-language example makes this concrete: a Python agent extracts contract information, while a Go service checks rules. The services collaborate through A2A without sharing an implementation language. The lesson is broader than either language: give each part a responsibility it can explain and test.
A2A provides a common way for independent agents to advertise capabilities, exchange tasks, and report progress. It is useful when agents really are independent. If two steps live in the same small application, a function call or queue may be simpler.
Make the handoff boring
For the heating request, the handoff should carry a request ID, the extracted facts, where those facts came from, what is still unknown, and the specific action requested. The response should say what happened, which slots are possible, and whether a person needs to step in. Avoid making the next agent reconstruct the story from a long chat transcript.
Also decide what happens when the other service is slow or unavailable. A timeout should leave the request pending for review. It should not quietly turn into a confirmed appointment. Record the task state so a retry does not create a duplicate booking.
This is the unglamorous part of multi-agent work: inputs, outputs, timeouts, retries, and ownership. It is also the part that makes the system usable on a busy Tuesday.
A sensible first pass
- Map one real request from arrival to final decision.
- Use AI where the input is messy; use ordinary code where the rule is clear.
- Write down the data passed between steps and the status returned.
- Add another agent only when it has a distinct job or ownership boundary.
- Test a failed handoff before celebrating the happy path.
More agents are not the goal. A workflow that leaves people informed and gets the job done is.