APEX: 20 Specialist Agents, One Supervisor, 150+ Tools

The default mental model of an enterprise AI copilot is one big model with a long system prompt and a list of tools. That works for a few prototype demos and breaks under real load. The reason is that the software market is not one domain — it's 20 of them, and the questions a CI analyst asks have almost nothing in common with the questions a Product Ops lead asks, even when they're asking about the same vendor.

One generalist copilot loses to 20 routed specialists on questions about the software market. The domain is too deep for a single system prompt to carry. The interesting architectural question is how to route, not how to scale.

APEX is the multi-agent answer. Anthropic described the orchestrator-worker pattern behind its own Research feature in mid-2025 (a lead agent that plans and delegates to specialist subagents);[1] Microsoft Research's AutoGen framework (2023) had already shown multiple LLM agents coordinating through structured conversation.[2] APEX implements that pattern for the specific shape of intelligence about the software market — 20 specialists, 150+ tools across them, one supervisor on top, and the tools that read the graph use typed nodes instead of raw text.

Section 1: Why 20 specialists, not one mega-prompt

A specialist agent is a model + a focused system prompt + a small toolkit (a median of 8 tools, measured in our code on 8 Oct 2026) + a step budget. The 20 specialists inside APEX align with the most common intent categories that teams at software companies have:

• Battlecard Specialist · Competitive Intel · Win/Loss Analyst · Market Research · Financial Analyst (the CI cohort)
• Requirement Expert (the proposal cohort)
• Feature Analyst · Taxonomy Expert · Review Analyst · Project Analyst · Portfolio Catalog (the product cohort)
• ICP Analyst · Segment Architect · CRM Analyst · Conversation Intel · Intent Analyst · Engagement Analyst (the GTM cohort)
• Dashboard Analyst · Model Expert · Onboarding Architect (the platform cohort)

Each specialist's instructions run from about 800 to 1,800 tokens (the versions in our code, measured on 8 Oct 2026). Folding all 20 into one generalist prompt would come to about 24,500 tokens, and long prompts suffer the "lost in the middle" degradation that affects long-context language models.[10] Worse, the retrieval-augmented context budget gets squeezed by the prompt budget — less room for actual graph evidence. The specialist split solves both problems: every specialist gets the focused prompt it needs and the full retrieval budget.

Section 2: The supervisor

Every APEX conversation enters through a supervisor agent — the orchestrator that owns the session memory, the citation set, and the user-facing voice. The supervisor doesn't answer questions directly. It does three things:

• Intent classification. Parse the incoming message and decide which specialist(s) to invoke. A query like "refresh the Salesforce battlecard with this week's releases" routes to two specialists in sequence: Competitive Intel (to pull the week's releases) and Battlecards (to compose the updated card).
• Plan composition. For multi-specialist queries, the supervisor produces a plan · ordered specialist calls with shared context. It records the plan and its progress as it works (set_plan, update_plan_progress, complete_plan).
• Synthesis & citation. When specialists return, the supervisor merges their outputs into a single response. The sources the agents cite collect in one Sources panel, grouped by type — not five overlapping ones.

Section 3: Why 150+ tools and not 12

OpenAI's function-calling guide[5] asks for clear, detailed function names and descriptions, and suggests keeping fewer than about 20 functions in front of a model at once. That is the reason for the specialist split: each specialist sees its own toolset, not all 150+. In our experience, a specialist agent that has one getCompetitorIntelligence(competitorId, asOfDate, depth) tool makes worse decisions than one that has eight smaller tools (findCompetitor, listReleases, getPricingDiff, getReviewSentiment, etc.). The smaller tools compose; the big one obscures.

APEX's tools follow a verb_noun naming pattern (search_win_loss_interviews, get_survey_results, explore_node_graph). Of the 207 tool definitions in our code on 8 Oct 2026 (the 150+ tools APEX binds are among them), 206 carry a written description, 205 a schema for their input, and 190 a schema for their output.

The graph-grounded tool layer

APEX's graph-reading tools read typed graph nodes. The retrieval pattern borrows from Microsoft's GraphRAG, which builds a graph of the nodes in a corpus and answers from summaries of related node groups.[7] APEX's own version combines vector similarity with graph structure: find the starting node, walk its typed edges, and pull the connected subgraph (explore_node_graph, find_path_between_nodes, graph_rag_search). The structural commitment is that a graph tool resolves the node a question is about before it reads any text. A tool that wants to answer "how is Salesforce's positioning shifting?" starts by finding the Salesforce vendor node and walking outward — not by full-text-searching a press-release archive.

Section 4: ReAct loops inside each specialist

Each specialist runs an internal ReAct loop[4] · reason, act (call a tool), observe (read the result), reason again. The loop ends when the specialist answers without calling another tool, or when it hits its step budget: 8 steps for a specialist the supervisor delegates to, and 20 for the supervisor itself by default (checked in our code on 8 Oct 2026). A specialist that runs out of steps returns what it has; if a delegation fails, the error goes back to the supervisor so it can retry or explain the failure.

APEX also checks a sample of its own answers after the fact: on one turn in five, a scorer flags product and company names in the answer that never appeared in the tool results behind it. Today that check is a quality signal we use to improve prompts, not a gate that stops an answer from reaching you.

Section 5: MCP access · part of it today

Today APEX runs inside PYRAMYD, and part of the graph is already reachable over the Model Context Protocol.[3] In Settings › Workspace › API a user creates a personal access token; Claude Desktop, Cursor, or Zed (and ChatGPT Actions or Microsoft 365 Copilot) can then search signals, competitors, and battlecards, and read a battlecard, without leaving that client. APEX itself and the rest of the graph are not reachable over MCP yet; that access is on the way.

This is the direction Gartner forecasts: by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024.[6] APEX is the variant of that pattern that's specifically tuned for questions about the software market — the substrate, the specialists, and the tool surface are co-designed.

Section 6: What this means for the user

The user-facing surface of APEX is one chat box and one citation panel. The 20 specialists, 150+ tools, supervisor planning, and verification loop are invisible. What the user notices is:

• Harder questions get more specialists, not a longer prompt. A casual "summarize Salesforce's last quarter" and a complex "which of our competitors shipped a feature this quarter that overlaps with our roadmap and is selling into the same accounts we're competing for" both go through the same supervisor · the second one fans out to several specialists internally.
• Sources stay visible. The sources the agents cite collect in the Sources panel, with a link back to the original where one exists, so you can check a claim yourself.
• Cost follows the question. A simple question can be answered by the supervisor or one specialist; only multi-domain questions fan out to several.
• New capabilities ship as new specialists, not as model upgrades. When PYRAMYD ships a new intelligence vertical, it's a new specialist with a new toolkit — not a re-prompted generalist.

The interesting question for the next 24 months isn't whether enterprise software takes on agentic AI · Gartner already forecasts that a third of it will by 2028.[6] It's whether the agents are grounded in typed substrates (the GraphRAG pattern, the APEX pattern) or in document collections. The first wins on multi-hop reasoning, on audit, and on the questions operators actually have. The second wins on demo simplicity. We think the market will prefer the first.