Conflicting Inventory Answers Across Three Specialists
A retail operations team is building an assistant that answers questions about stock levels. The architect proposes three specialists: an Inventory agent querying a warehouse API, a Pricing agent querying a catalog service, and a Fulfillment agent calling a shipping-rate API. Each is registered separately and a router agent forwards every user message to exactly one specialist based on a classification step. In testing, the question 'Can we ship 40 units of SKU-118 to Denver by Friday, and what will it cost?' is routed to Fulfillment only. The reply quotes a shipping rate but asserts stock is available based on a cached value that is 3 days stale; the Inventory API would have returned 12 units. Separately, the router misclassifies 'why is the price on SKU-118 different from last week' as Inventory. Stakeholders want a fix that keeps the three specialists as independently deployable services.
1. What is the root architectural defect, and what pattern should replace the single-specialist router while keeping the specialists independently deployable?
Read the worked answer
The defect is single-agent dispatch for a multi-part question. The router assumes one message maps to one specialist, so a request spanning inventory, pricing, and fulfillment can only ever be answered from one source of truth, and the other facts are filled in from stale local state.
The fix is orchestration, not routing. Introduce a coordinator agent that:
- Decomposes the request into sub-tasks (stock check, rate quote, price history).
- Dispatches in parallel to the relevant specialists, each of which remains a separately deployed service with its own API contracts.
- Reconciles the results, and critically, treats the warehouse API as authoritative for quantity rather than any cached value.
- Synthesizes a single answer that cites which specialist supplied each fact.
Keep the specialists independent by giving them a shared, versioned tool/response contract rather than shared state. The misclassified price-history question is a symptom of the same problem: classification is brittle. In an orchestrator, a low-confidence classification can fan out to two specialists (Inventory and Pricing) and let reconciliation decide, instead of forcing a single guess. Note the design tradeoff: fan-out costs more tokens and latency, so gate it on a confidence threshold rather than doing it for every message.
2. The team wants to eliminate the stale-cache problem by having the Fulfillment agent keep its own copy of stock levels, refreshed hourly. Evaluate this proposal.
Read the worked answer
Reject it as stated. It converts a correctness bug into an architectural commitment to inconsistency. An hourly refresh guarantees a window of up to 60 minutes in which Fulfillment reports stock that does not exist - exactly the failure observed (12 vs. 40 units).
The right principle is single ownership of each fact. Stock quantity is owned by the Inventory agent and its warehouse API; Fulfillment should never hold a copy. If Fulfillment needs a stock signal to compute shippability, it should call Inventory at answer time (or the orchestrator should pass the fresh value into Fulfillment's context).
If latency genuinely forces caching, then:
- Cache must carry a freshness timestamp that is surfaced in the answer, and
- Any quantity-dependent commitment (reserving, promising a ship date) must revalidate against the source before being stated.
Acceptable compromise: cache for read-only display, never for commitments. The hourly-refresh proposal fails because it caches for a commitment without revalidation.