Most writing about multi-agent AI is either a framework demo or a diagram of a system that has never met a real user. ApexGenius is neither — it's GAT's own product, a copilot that answers questions about Salesforce orgs and helps admins and developers work in them. Because we own it, we can show you the architecture honestly: what we built first, what broke, what we rebuilt, and the numbers behind it. As of July 2026, it has produced 16,550 AI answers across 47 connected Salesforce orgs, retrieving from a corpus of 92,000+ metadata chunks.
The uncomfortable summary: we built a 12-agent system, learned why more agents is not more intelligence, and consolidated. The best multi-agent architecture we've shipped has fewer agents than the one before it.
Origin: the prototype was an n8n canvas
ApexGenius did not start as a Python service. It started as an n8n workflow — an orchestrator that grew node by node as we bolted on retrieval, routing, and Salesforce API calls. That was the right first move, and we'd make it again. A visual workflow tool let us test the core bet — can an LLM grounded in org metadata give answers a Salesforce admin actually trusts? — in days instead of months, against real orgs, without committing to a service architecture we didn't understand yet.
It also showed us exactly where the prototype ceiling is. Branching logic that would be ten lines of code becomes a thicket of nodes. Versioning a sprawling canvas is miserable. Testing individual steps in isolation is nearly impossible. When the workflow itself became the hardest part of the system to change, we graduated the copilot to a Python/FastAPI service — deliberately, with the prototype as the spec. n8n never left, though: it still runs the automation layer around the product, where we've built 59 workflows with 21 live today. We've written more about where that layer fits in n8n + Salesforce: 10 automation patterns.
v1: 12+ specialized agents, and what routing taught us
The first production architecture was the one every multi-agent tutorial recommends: decompose the domain into specialists. We shipped 12+ specialized agents — an Apex agent, a Flow agent, an object-model agent, a dependency agent, a debug agent, and so on — behind a router that classified each user question and dispatched it.
It worked. It also taught us three expensive lessons:
- The router becomes your weakest link. Real questions span specialties — "why did this Flow fail after the trigger ran?" is a Flow question, an Apex question, and a dependency question at once. Every misclassification sent the user to a specialist missing half the context.
- N agents means N prompts drifting apart. Every improvement — a better citation format, a new guardrail — had to be propagated across a dozen system prompts. They diverged anyway.
- Handoffs shred context. When one agent passed work to another, the conversation state that made the answer good was exactly what got summarized away at the boundary.
None of this means specialization is wrong. It means specialization by spawning more agents has a real architectural tax, and you should pay it only where the specialty genuinely needs its own tools and its own failure handling.
v2: one main agent, an orchestrator, and skills over agents
The current architecture inverts the org chart. One strong main agent owns the conversation end to end. When a task is genuinely complex — multi-step analysis, staged changes, cross-component work — it escalates to a code-mode orchestrator that coordinates a small bench of sub-agents. And most of what used to be a separate agent is now a skill: a packaged bundle of metadata-type expertise — how Flows are structured, what matters when reading a permission set, the sharp edges of a given metadata family — loaded into the working agent's context only when the task calls for it.
The distinction sounds subtle and changes everything. An agent is a separate process: its own context window, its own prompt to maintain, a handoff to survive. A skill is knowledge without a process boundary. The main agent stays in the conversation, keeps full context, and simply becomes temporarily expert in the thing at hand. Routing errors mostly disappeared because there is far less routing; prompt drift mostly disappeared because there are far fewer prompts. The sub-agents that remain earn their existence by needing genuinely different machinery — long-running analysis, isolated execution — not just different knowledge.
The RAG substrate: 92,000+ chunks of a weird corpus
Underneath every agent sits the same retrieval layer: Supabase Postgres with pgvector, holding 92,000+ chunks of Salesforce metadata alongside a component index that preserves what the chunks alone would lose — which Flow touches which field, which class calls which class.
Org metadata is a genuinely strange corpus, and treating it like a pile of documents fails quietly. It's machine-generated XML, so embedding it raw wastes the vector space on angle brackets. A single Flow can dwarf any sane chunk size, so components have to be split along semantic boundaries — elements, decisions, subflow calls — not character counts. And almost nothing in an org is meaningful in isolation: a validation rule matters because of the object it guards and the automation that collides with it. Retrieval has to return neighborhoods, not fragments.
The corpus also refuses to sit still. Orgs change daily, so incremental sync jobs keep the index tracking each connected org rather than re-ingesting from scratch — and between syncs, the honest answer is that retrieval can be briefly stale. We surface sync recency rather than pretending otherwise.
The plumbing nobody blogs about
The architecture diagrams above are maybe a third of the codebase. The rest is the part that makes it a product instead of a demo:
- Caching in Redis, because re-embedding and re-retrieving what hasn't changed is the fastest way to turn a margin into a bill.
- Tracing on every agent hop via Phoenix. When a multi-agent answer is wrong, "which step went wrong?" must be a query, not an archaeology project.
- Tenant isolation with Postgres row-level security. Forty-seven connected orgs (as of July 2026) means forty-seven customers whose metadata must never cross-contaminate a retrieval.
- Audit logging on every action the system takes, so there is always an answer to "what did the AI do and who asked it to?"
- PHI redaction in the pipeline ahead of the model, because our customers include healthcare orgs. ApexGenius is working toward HIPAA compliance — we don't claim it today, and the redaction layer, isolation, and audit trail are the engineering groundwork for that claim, not a substitute for it.
If you're taking any Salesforce AI workflow to production, this layer is where readiness is decided — we've published a fuller checklist in Salesforce AI production readiness.
The MCP tier: letting Claude do the work, with gates
The newest tier exposes ApexGenius as an MCP server, so Claude (or any MCP client) can operate the same machinery directly: pull components into a staging workbench, edit, run SOQL, and deploy — with per-org access control deciding which tools a given connection may use, and deployment as an explicit, human-approved step rather than a side effect of conversation. Every tool call is metered; as of July 2026 the tier has recorded 2,645 metered MCP calls. If you're comparing connection paths, we maintain an honest, disclosure-first comparison in Salesforce MCP options compared and a setup walkthrough in how to connect Claude to Salesforce.
What the numbers say — and don't
As of July 2026: 16,550 AI answers delivered, 47 Salesforce orgs connected, 92,000+ metadata chunks under retrieval, 2,645 metered MCP tool calls. Those are usage numbers from our own database, and we state them plainly because the AI market is drowning in numbers that aren't. What they don't say is that every answer is right — it isn't, which is why answers cite the metadata they were grounded in, why deploys require a human, and why the audit trail exists.
Lessons for anyone building agentic systems on enterprise data
- Prototype visually, graduate deliberately. The n8n canvas earned its keep by proving the bet cheaply. The mistake is not starting there; it's staying past the point where the workflow is harder to change than code would be.
- More agents is not more intelligence. Every agent you add buys specialization and costs routing accuracy, context continuity, and prompt maintenance. Default to skills; promote to an agent only when the job needs different machinery.
- Retrieval quality dominates model choice. Our biggest answer-quality gains came from metadata-aware chunking and the component index, not from swapping models.
- The plumbing is the product. Tracing, isolation, audit, redaction, and metering are what let you sell the system to a business that has something to lose.
- Meter and audit from day one. Retrofitting usage-based pricing or an audit trail onto a live agent system is far harder than building on them.
The same decisions — interface, connection, retrieval, action, governance — apply whether you build or buy; we've mapped that decision space in Agentforce vs MCP vs RAG and in our Claude + Salesforce solution overview.
Frequently asked questions
When does a multi-agent architecture actually beat a single agent?
When the domain splits into genuinely different jobs with different tools and different failure modes — writing Apex versus auditing dependencies versus running deploys. If one capable agent with good retrieval can do the work, one agent is better: every additional agent adds a routing decision that can go wrong, another prompt to maintain, and another hop of latency. We started with 12+ agents and deliberately consolidated.
What is the difference between adding an agent and adding a skill?
An agent is a separate process with its own context, prompt, and tools — you pay a routing and handoff tax every time work crosses into it. A skill is packaged domain knowledge loaded into an already-capable agent exactly when the task calls for it. In our experience, most of what teams model as new agents is really missing knowledge, and a skill delivers it at a fraction of the architectural cost.
How is RAG over Salesforce metadata different from RAG over documents?
Org metadata is a hostile corpus: machine-generated XML, Flows that can run to thousands of lines, and components that are meaningless without their cross-references. Naive chunking retrieves fragments that look relevant and answer nothing. You need metadata-aware chunking, a component index that preserves relationships, and incremental sync so the corpus tracks the org as it changes — retrieval quality, not model choice, is where these systems are won or lost.
Is ApexGenius HIPAA compliant?
No, and we won't claim it until it's true. ApexGenius is working toward HIPAA compliance. What exists today is HIPAA-conscious engineering: a PHI-redaction pipeline in front of the model, row-level security isolating every tenant, and audit logging on every action the system takes. Healthcare teams evaluating it should treat those as design facts, not a compliance certification.
Can GAT build a multi-agent system like this on our data?
Yes — this architecture is the reference implementation for our AI consulting work. The pattern (one strong main agent, an orchestrator for complex work, skills over new agents, a domain-aware RAG substrate, and metering plus audit from day one) transfers to any enterprise corpus, not just Salesforce metadata.
Build with the team that runs one in production
GAT Solutions builds revenue-generating systems for healthcare, accounting, and SaaS companies — fast, flawlessly, and powered by AI. ApexGenius is what that looks like when we're the client: a multi-agent system that survived contact with real orgs, real tenants, and real usage bills.
If you're architecting an AI copilot on your own enterprise data — or deciding whether your Salesforce team should adopt one — bring the problem to a working session and we'll walk you through the architecture tradeoffs before you commit to any of them. Start with Salesforce AI consulting or explore ApexGenius directly.