Apache Camel routes one request across parallel A2A agents

Apache Camel has published a reference implementation for turning one multi-intent request into parallel work across several A2A agents, then validating and recombining their replies.

The example matters less as a travel-planning demo than as an integration design. Camel keeps the orchestration in routes that application teams can inspect: semantic decisions select specialists, a Split enterprise integration pattern runs calls in parallel, a Switch maps labels to fixed destinations, and bounded Loops control regeneration.

Five applications, one coordinator

The implementation consists of a coordinator plus reservation, weather, cost and general-help specialists. Each specialist is a separate Camel application exposing an Agent2Agent endpoint. The coordinator accepts plain text at /trip, evaluates which specialties are required, calls the selected agents concurrently and checks each contribution before returning or merging it.

Selection is multi-label rather than a single classification. Independent Boolean decisions determine whether reservation, weather or cost expertise is required. A fallback decision chooses one specialist only when none of those questions clears its threshold; low-confidence fallback results ask the user for clarification.

The example batches four semantic questions into one request. It uses Camel's preview camel-semantic language with a TypeSafe AI adapter, while the A2A component handles agent discovery and protocol calls. The article says the code targets Camel 4.23.0-SNAPSHOT and uses the new Switch EIP.

Validation is part of the route

Each specialist reply is evaluated only against the portion of the request assigned to that specialist. The route accepts a clear pass, retries a clear failure within a three-attempt default budget, and withholds uncertain or exhausted drafts for review.

If several contributions pass, a language model merges them and Camel evaluates the combined answer against the original request. A failed merge can be regenerated without calling every specialist again. Transport failures take a separate HTTP error path rather than consuming semantic retry attempts.

The design also leaves provider boundaries visible. Generation uses Camel's OpenAI-compatible component, while semantic decisions can be supplied by hosted Jev or compatible Laya and Julia-1 services through configuration. Compatibility covers the request and response contract, not identical decisions.

What teams should test

Camel includes route tests with local fixtures for concurrency, selection, retry budgets, uncertainty, merging and HTTP failures. The project separates those deterministic route tests from an opt-in evaluation against a real decision service.

That distinction exposes an important limitation: a specialist reply can pass its own relevance check even if routing failed to select another required specialist. An accepted answer therefore does not prove that every user intent was found. Teams adopting the pattern still need labeled routing evaluations for every model, threshold and prompt change.