09 — Evolution & Deprecated Patterns

This section catalogs what Algolia's Agent Studio team built, then deprecated. Knowing what NOT to rebuild prevents us from reinventing patterns the platform's owners explicitly moved away from.

The big shift: multi-agent → single-agent

What multi-agent looked like (alpha-fashion, milo)

The alpha-fashion app ran 5 agents per brand:

Plus [alpha-fashion] category description for category pages.

External code (presumably) ran the orchestrator first to get a label, then routed to the appropriate worker agent based on the label. Each routing decision = full LLM call. Each agent had its own context window with no shared state.

The same shape exists in the Milo app (orchestrator + fast + product-discovery + pdp-suggestions + default-suggestions), Accor (default-suggestions + fast + product-discovery), and Vuori (nav-suggestions + product-discovery).

What replaced it

fashion-shopping-assistant (one of the production single-agent shopping assistants): - 1 agent - 13 tools (10-tool core + analyze_image + outfit_components + show_multi_query_results) - Prompt-level intent routing - Single context window across all interactions - 1 LLM call per user turn (multiple tools called in parallel within that call)

Same vertical, fundamentally different architecture. The team moved AWAY from multi-agent.

Why they moved

Inferred from the architectural change and platform evolution:

1. Routing latency. Each LLM-based router decision = 2-5 second LLM call. With orchestrator + worker, every turn was 2 LLM round-trips minimum. Heavy questions could span 4-5 round-trips.
2. Loss of conversational context. Each worker agent has its own context. The orchestrator doesn't see what the worker said previously. Multi-turn coherence required external state-sharing logic.
3. Tuning sprawl. 5 prompts × 3 brands = 15 prompts to maintain. A change to behavior (e.g., "always suggest follow-up questions") needed to be propagated across all of them.
4. Debugging surface. "The agent gave a bad answer" required figuring out which of 5 agents failed, in which step.
5. Tool calls 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, prompt processing.

The platform evolution: instead of "split work across agents," the team realized that "tools are the unit of decomposition, not agents." A single agent with focused tools accomplishes the same separation of concerns at much lower cost.

What did NOT get deprecated

Classifiers (the orchestrator pattern, narrowly applied)

The demo-classifier agent (in the modern demo app) is a SAFETY classifier — it labels inputs as POLITICAL, MINOR, VIOLENT, SEXUAL, MEDICAL, LEGAL, NOT_IN_REGION, OUT_OF_SCOPE, NO_VIOLATION. It's not a worker router — it's a guardrail.

Classifiers are NOT deprecated. The legitimate use: - Safety / scope filtering — quick check before invoking the main agent - Region or compliance routing — different agents for different jurisdictions - High-volume binary decisions — when you need a one-word answer fast

What IS deprecated: classifiers as router for functional decomposition (PRODUCT_DISCOVERY → product-discovery worker, PRODUCT_QUESTION → fast worker, etc.). That role is now done inside one agent's prompt with intent-recognition rules.

PDP-specific agents (separate from the main shopping assistant)

PDP product experts still exist as separate agents (pdp-fashion-product-expert, pdp-ecom-product-expert, etc.) in the modern demo app. They're not deprecated — they have a genuinely different shape (productID input, narrow scope, 2-3 tools instead of 13). When the agent's job is fundamentally narrower, separate agent makes sense.

Distinction: PDPs aren't "workers called by an orchestrator" — they're standalone agents invoked when the user is on a PDP. The frontend page knows it's on a PDP, so it routes to the PDP agent directly. No orchestrator in the loop.

Filter Suggestions, Category Page Pitch, Welcome Prompts

These specialized stateless agents persist because they're fundamentally different shapes from a chat agent. They're invoked by backend pipelines or frontend widgets, not by users via chat. A category page rendering 50 categories doesn't want a 13-tool shopping agent processing each one — it wants a tight ~120-word agent that produces text.

Implications for our Maverick + Elena + Bruno topology

Should we have a classifier upstream of Maverick?

Today Maverick handles all incoming user messages. Per the deprecated-pattern lessons: - Pure functional routing (PRODUCT_QUESTION vs PRODUCT_DISCOVERY) — NO. That's exactly the deprecated pattern. Move it inside Maverick's prompt as intent recognition. - Safety classifier (HARMFUL / OUT_OF_SCOPE / NO_VIOLATION) — MAYBE. If we genuinely need pre-Maverick safety filtering (e.g., to prevent Maverick from being invoked on adversarial inputs), a demo-classifier-style agent is fine. Otherwise: add the safety rules to Maverick's information guard and skip the upstream classifier.

For v1 of the rebuild: skip the upstream classifier. Add information guard + scope rules to Maverick directly. Reconsider only if production data shows safety incidents.

Should Elena and Bruno be one agent or two?

This is the open question (Q-AS1 in RC3-BRIEF).

The deprecated multi-agent pattern argues against splitting if the only reason is "different specializations" — production agents handle multiple specializations via tool selection within one prompt.

But Elena and Bruno are NOT just different specializations of one role. They have meaningfully different output shapes: - Elena: SEE framework, business impact + ROI, customer evidence, implementation steps. Sales-flavored prose. - Bruno: GO/NO-GO verdict, mandatory Mermaid diagram, 3-phase technical roadmap, scale benchmarks. Architecture-flavored.

Three options:

1. Keep them separate — two agents, each AskAI-pattern, each with its own tools. User-visible role distinction stays.
2. Merge into one specialist — single agent, prompt branches on user intent. Tools include both Elena-tools and Bruno-tools. User sees one specialist that adapts.
3. Single specialist with mode parameter — one agent, completion request includes mode: "implementation" | "architecture", prompt switches accordingly. Tools shared.

Best path TBD by UX research. For the wiki: don't split agents based on the deprecated functional-routing logic. DO split if the user-visible role distinction is genuinely valuable to the user. That's a UX decision, not a platform-pattern decision.

Should we orchestrator + SME-per-content-type?

See 06-multi-index-routing §"Why Option C is wrong for us." Short answer: no. Multi-index inside one tool achieves the same content-type-specific intelligence at a fraction of the latency and complexity cost.

Other deprecated micropatterns

Imperative UI manipulation tools (Hugo agents)

Earlier-generation tools like retrieveSearchUiHits, retrieveSearchUiParams, updateSearchUiParams let the agent READ and WRITE the frontend's search UI state directly.

Modern tools (suggest_searches, ui_refinement, show_products) are DECLARATIVE — the agent describes intent ("filter by blue, under $100"), the frontend figures out how to apply it.

Why deprecated: - Imperative tools couple agent logic to specific UI implementation - Hard to test (each tool call requires UI state setup) - Brittle to UI changes - The agent ends up doing UI work, which is not its job

Don't build imperative UI tools. Always declarative.

Tools that wrap simple text outputs

Some early agents had tools like display_message or format_response that just wrapped text. These are gone. Text is text — let the agent emit text. Tools should produce STRUCTURED output that the frontend renders specially. Anything renderable as plain markdown should not be a tool.

Per-vertical custom tools that duplicate the 10-tool core

The 10-tool core (suggest_searches, view_product, etc.) emerged from many verticals having the same tools with slightly different schemas. The deprecated approach was to define fashion_view_product and grocery_view_product separately. The modern approach is one shared view_product schema across all verticals.

Build shared tool schemas. Vary the data, not the schema.

What this section does NOT cover

• The right architecture for our agents — see 04-agent-archetypes, 10-our-agents-vs-best-practice
• Decision rubrics for "should I split this agent" — see 11-decision-rubrics
• Multi-index alternative to multi-agent — see 06-multi-index-routing