Skip to main content

Multi-Agent Patterns

CRAFT’s multi-agent coordination happens at the protocol layer through A2A. Agents discover each other via the registry, delegate work via JSON-RPC, and stream results via SSE — without sharing process memory or tight framework coupling. This page covers the three main coordination patterns used in production CRAFT deployments.

The CRAFT Multi-Agent Architecture

CRAFT’s analytics solution is a good reference for multi-agent patterns. A typical layout chains three specialized agents:
  1. Orchestrator — receives user requests, plans the workflow, delegates to sub-agents
  2. Text2SQL — converts natural language to SQL, executes against the target database, returns query results as Parquet artifacts
  3. Insights — analyses query results, generates charts, produces natural-language insights and visualizations
Each agent is an independently deployed microservice. They communicate exclusively through the A2A protocol.

Pattern 1: Sequential Delegation

The orchestrator delegates tasks to sub-agents one at a time, using the output of one as the input to the next. This is the most common pattern on CRAFT.

Google ADK — RemoteA2aAgent Sub-Agents

ADK makes sequential delegation transparent: RemoteA2aAgent instances look like local sub-agents. The orchestrator LLM routes to them via the transfer_to_agent tool. Resolve sub-agent URLs from the CRAFT Assets API rather than hardcoding hostnames.

Claude Agent SDK — Sequential Delegation

LangGraph — Sequential Delegation

How ADK Delegation Works

When the orchestrator LLM decides to delegate:
  1. LLM emits a transfer_to_agent tool call with the target agent name and message
  2. ADK resolves the remote agent’s card (lazy, cached after first fetch)
  3. ADK constructs an A2A message/stream JSON-RPC request from the session context
  4. Sends via httpx.AsyncClient to the sub-agent’s URL
  5. Processes the SSE response stream back into ADK internal events
  6. Returns the final artifact to the orchestrator as if it were a local sub-agent result

Passing Context Between Agents

The Text2SQL agent requires a DataPart with the datasource context. The orchestrator must forward this from the original user message:
The resource_uri must be in the full four-segment format: data:{org_id}:{project_id}:{name}. The simplified format (data:my-db) will fail — the Assets API requires all four segments for connection resolution.

Pattern 2: Parallel Fan-Out

Multiple sub-agents are invoked concurrently and their results are merged. Use this when sub-tasks are independent and latency matters.

Manual Fan-Out with asyncio

For frameworks other than ADK (or for orchestrators that need explicit concurrency control):

ADK Fan-Out via Parallel Sub-Agents

Google ADK supports parallel sub-agent invocation when the orchestrator instruction explicitly requests concurrent delegation:
ADK’s RemoteA2aAgent A2A support is currently experimental. Parallel invocation of multiple RemoteA2aAgent instances in the same turn may produce duplicate events (tracked in ADK issue #3207). Test thoroughly before using in production.

Pattern 3: Supervision and Retry

An orchestrator supervises sub-agent results and retries failed tasks with corrected inputs.

Detecting Sub-Agent Failures

A sub-agent that fails emits a TaskStatusUpdateEvent with state=failed and an error message. ADK surfaces this as an error event in the orchestrator’s event stream. The orchestrator LLM sees the failure message in its context and can decide to retry or escalate.

Registering Sub-Agents with the Orchestrator

When adding a new agent to the platform, you must:
  1. Register it with the Assets API — gives it a resource_uri and makes it discoverable
  2. Add it as a RemoteA2aAgent to the orchestrator (if using Google ADK) — and redeploy
  3. Update the orchestrator instruction — explain what the new agent does and when to use it
The description field on RemoteA2aAgent is what the orchestrator LLM reads to decide routing. Write it as a capability statement: “Use this agent when the user needs X, Y, or Z.”

Carrying Artifacts Across Agent Boundaries

Artifacts (Parquet files, charts, SQL queries) produced by sub-agents are stored in the Assets API and referenced by resource_uri. When the orchestrator passes results from one agent to another, it passes the resource_uri — not the raw data.

Context Propagation

Every A2A message must include a context_id — the conversation session identifier. Sub-agents use this to look up conversation history from the task store. In a multi-agent architecture, the orchestrator’s context_id flows through to each sub-agent call. This ensures that sub-agents can retrieve prior turns when needed for multi-step workflows.

Next Steps

Streaming Idioms

SSE streaming, partial results, and cooperative cancellation.

A2A Protocol Primer

Review the A2A wire format and task lifecycle.