APEX: 21 Specialist Agents, One Supervisor, 165 Graph-Grounded 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 enterprise software is not one domain · it's 21 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 21 routed specialists on enterprise software tasks. 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 published the supervisor/worker pattern as their canonical multi-agent architecture in mid-2025;[1] Microsoft Research had validated it earlier with AutoGen.[2] APEX implements that pattern for the specific shape of enterprise software intelligence · 21 specialists, ~165 tools across them, one supervisor on top, and every tool reading from typed graph nodes instead of raw text.

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

A specialist agent is a model + a focused system prompt + a small toolkit (typically 5-10 tools) + a verification loop. The 21 specialists inside APEX align with the 21 most common intent categories enterprise software operators have:

• Battlecards · Win/Loss · Competitive Diffs · Talent Signals · Pricing Tracking · Releases · Personas (the CI cohort)
• RFX Draft · Approved-Answer Library · Proposal Compose · Question Decomposition (the proposal cohort)
• Roadmap · Feature Gap Analysis · Capability Mapping · Persona Discovery (the product cohort)
• Account Plan · ICP Builder · Segment Discovery · Reviews Analytics · Deal Tip · Customer Discovery (the GTM cohort)
• Schema Admin (the platform cohort)

Each specialist's system prompt is roughly 1,200-2,000 tokens. A generalist trying to cover all 21 domains would need a 30,000+ token prompt and would suffer the "lost in the middle" degradation that affects long-context language models. 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: Releases (to pull the week's diff) and Battlecards (to compose the updated card).
• Plan composition. For multi-specialist queries, the supervisor produces a plan · ordered specialist calls with shared context. The plan is logged so it's auditable end-to-end.
• Synthesis & citation. When specialists return, the supervisor merges their outputs into a single response and de-duplicates the citation set. The user sees one answer with one citation panel · not five overlapping ones.

Section 3: Why ~165 tools and not 12

OpenAI's function-calling guidance[6] · and the consensus from every team that has shipped a production agent system · is that small, composable, well-named tools beat few, complex tools. A specialist agent that has one getCompetitorIntelligence(competitorId, asOfDate, depth) tool is going to make worse decisions than one that has eight smaller tools (findCompetitor, listReleases, getPricingDiff, getReviewSentiment, etc.). The smaller tools compose; the big one obscures.

APEX's ~165 tools follow a strict naming convention: verb-noun-qualifier. Every tool is documented with a description, a JSON schema for the input, a JSON schema for the output, and a citation policy (what gets stamped into the response's citation set). Tools that don't return citations are flagged in the audit log so the supervisor knows not to surface their output verbatim.

The graph-grounded tool layer

Every APEX tool reads from typed graph nodes. The retrieval pattern follows the Microsoft GraphRAG architecture[8] · entry via vector similarity, expansion via typed graph walks, response via community summaries plus per-node detail. The structural commitment is that no tool reads raw text without first resolving the entity it's about. 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 terminates when the specialist's confidence threshold is met or it hits the max-iteration budget. Specialists that hit their budget return a partial answer plus a structured "needs more time" signal · the supervisor decides whether to retry, escalate, or surface the partial.

Self-reflection (Reflexion-style)[5] is applied at the supervisor layer · before the final response leaves APEX, a verification pass checks that every claim has a citation and every citation supports its claim. Failed verifications are routed back to the relevant specialist for revision. This is the "evidence-grounded" bar from the earlier post in this series · operationalized at the agent layer.

Section 5: MCP delivery · APEX is portable

APEX exposes its tool surface via the Model Context Protocol.[3] Practically that means: plug APEX into Claude Desktop, ChatGPT Enterprise, Cursor, Windsurf, or any other MCP-compliant client and the graph + the 21 specialists become available without leaving that client. The supervisor still runs on PYRAMYD's infrastructure · but the user experience is "your existing AI assistant just got 165 typed enterprise-software tools."

This is the deployment model the Gartner agentic-workflow forecast[7] predicts will dominate by 2028 · 33% of enterprise AI applications running on agent-based architectures, up from less than 1% in 2024. APEX is the variant of that pattern that's specifically tuned for enterprise software tasks · 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 21 specialists, 165 tools, supervisor planning, and verification loop are invisible. What the user notices is:

• Answers stay accurate as questions get harder. 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 work · the second one fans out to 4-5 specialists internally.
• Citations are always real. The supervisor's verification pass means a hallucinated claim doesn't escape to the user · it gets rejected at the gate.
• The cost scales sub-linearly with question complexity. Most queries route to one or two specialists; only the most complex multi-domain queries fan out to five.
• 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 AI moves to agent-based architectures · Gartner has already called that.[7] 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. The market is starting to prefer the first.