Evidence — Multi-Agent Worker Pattern (DEPRECATED)

Reference for what NOT to rebuild. The early Algolia Agent Studio multi-agent pattern, deprecated in favor of single-agent + many-tools.

The deprecated alpha-fashion topology (5 agents per brand)

External code: 1. Calls orchestrator → gets a label (PRODUCT_DISCOVERY / PRODUCT_QUESTION / etc.) 2. Routes to the matching worker agent based on the label 3. Worker agent processes within its own context

What replaced it

fashion-shopping-assistant — ONE agent, 13 tools, prompt-level intent recognition. Same vertical, single-agent topology, much lower latency.

Reasons the deprecation happened

Inferred from: - Migration timestamps (alpha-fashion-* dated 2026-02; fashion-shopping-assistant dated 2026-01 onward) - The 50-agent inventory showing both patterns coexist (early pattern still in app for legacy support; new pattern is the production reference) - Lack of documentation for the multi-agent pattern in current Algolia docs

Reason 1: Routing latency multiplies

Each LLM-based router decision = 2-5 second LLM call. With orchestrator + worker: - Turn 1: orchestrator classifies (2-5s) + worker responds (2-5s) = 4-10s - Heavy turns: orchestrator + multiple worker calls + synthesis = 10-30s

Single-agent pattern: 1 LLM call with parallel tool execution = 2-5s total.

Reason 2: Loss of conversational context

Each worker agent has its own context window with no shared state. The PDP suggestions worker doesn't know what the discovery worker said. Multi-turn coherence required external state-sharing logic that was brittle.

Single-agent pattern: one context window, full continuity.

Reason 3: Tuning sprawl

5 prompts × 3 brands (alpha-fashion, milo, accor, vuori) = 12-20 prompts to maintain. A behavioral change ("always suggest follow-ups") had to be propagated across all of them.

Single-agent pattern: 1 prompt per vertical. Each tool's schema lives in one place.

Reason 4: Debugging surface

"The agent gave a bad answer" required figuring out: - Did the orchestrator misclassify? - Did the worker fail? - Did the router code route wrong? - Did inter-agent state-sharing break?

Single-agent pattern: one prompt + tool selection trace. Much simpler.

Reason 5: Tools are cheaper than agent calls

A client_side tool call is a structured JSON payload returned in the same LLM call that decided to call it. An agent call is a full LLM completion with its own context, tools, and prompt processing. Tools are the unit of decomposition, not agents.

What this means for RC3 Phoenix

Don't rebuild this pattern. Specifically:

• Don't add a pre-Maverick agent that classifies user intent into PRODUCT_QUESTION / PRODUCT_DISCOVERY / etc. and routes to specialized workers. That's the deprecated pattern.
• Don't split Elena and Bruno into 4-5 sub-agents (one per content type, one per output format, etc.). Multi-index inside one tool achieves the same content separation at lower cost.
• Don't add an orchestrator agent that calls SME-per-content-type agents as tools. Per 06-multi-index-routing, this is option C and it's wrong for us.

What's still valid:

• Safety classifier upstream of main agent — different from functional routing. A safety classifier is one focused decision (allow / deny) with its own prompt-injection defense. See evidence/classifier-pattern.md.
• Standalone agents per page context — PDP agents, Category Page agents, FilterSuggestions agents. Each is invoked directly by frontend (because the frontend knows it's on a PDP, no orchestrator routing needed). Each is single-agent with focused scope. Not "workers called by an orchestrator."
• Multi-agent for genuinely different domains — if Algolia Central had healthcare + financial + legal content with separate compliance boundaries, splitting agents would be valid. We don't have this case.

Comparison: deprecated vs. modern

What this evidence card does NOT cover

• Why classifiers are still valid for safety routing — see evidence/classifier-pattern.md
• Multi-index routing as alternative to multi-agent — see 06-multi-index-routing
• Decision rubric for "should I split this agent" — see 11-decision-rubrics