Multi-Agent Systems Engineering

Two coordination styles work in practice: graph-based orchestration (a directed flow of tasks across agents, with clear handoffs) and A2A coordination (agents discovering and calling each other through the Agent-to-Agent protocol). Google ADK supports both. We pick the topology based on whether the workflow is fixed (graph) or emergent (A2A).

Specialisation is what makes multi-agent worth the complexity. A retrieval agent that does nothing but find and rank citations. A planning agent that decomposes intent into sub-tasks. A verification agent that checks the work of the others. Each one is small enough to evaluate independently, prompt-tune independently, and replace independently. The architecture becomes legible to the engineering team, not just to the original designer.

A real-world example from our Smarequ recruitment platform: fresh resume uploads run a direct three-tool pipeline (transcribe, profile, decide) for the happy path with zero LLM orchestration overhead. Partial or failed states route to a recovery agent that uses full LLM orchestration to repair state. Two pathways, one system, the right cost profile for each.

Conflict resolution between agents is the design problem that surfaces in week three of any multi-agent build. Two agents reach different conclusions. Which one wins. The right answer depends on the workload: deterministic priority for compliance-style flows, a verification agent for ambiguous reasoning flows, escalation to a human-in-the-loop for high-consequence decisions. We design the resolution policy explicitly, because the implicit policy is always "last write wins" and that is rarely what the business wants.

Multi-agent design surfaces failure modes that single-agent systems can hide: cyclical handoffs, context bloat as agents pass state, ambiguity about which agent owns the user-facing reply. We design these out from the start because we have spent enough hours debugging them.