Multi-Agent Customer Support: The Case for Sub-Agents

A multi-agent system takes the opposite bet. Instead of one generalist, you build a small team of specialist sub-agents — a triage agent that reads the ticket and decides where it goes, a billing agent that actually knows Stripe, an orders agent wired to Shopify, a docs agent that searches your knowledge base — and you let them delegate to each other. This post is the practical case for that architecture: when it earns its keep, when it's overkill, and how it works concretely when your agents sit on top of the helpdesk you already use (Zendesk, Freshdesk, Gorgias, Front) rather than replacing it.

What a multi-agent support system actually is

Strip away the jargon and a multi-agent system is one idea: an agent can call another agent the same way it calls a tool. A "parent" agent receives the ticket, decides part of the work belongs to a specialist, and hands that sub-task off. The sub-agent runs with its own model, its own tools, and its own knowledge, returns a result, and the parent carries on.

The canonical support shape — and the one every serious platform from Salesforce to Talkdesk now describes — is triage-and-delegate. A router agent classifies each incoming ticket by intent, urgency, and customer tier, then hands off to the right specialist: billing, technical, returns, account management. Each specialist pulls context from the system it owns and either resolves the issue or escalates with everything already gathered. (Salesforce's primer frames it the same way.)

That's the difference between a multi-agent system and a single bot with a long prompt: boundaries. Each agent has a narrow job, a short instruction set, and a small toolbox — which is exactly what makes each one reliable.

Why one big agent eventually breaks

The strongest argument for sub-agents isn't a benchmark, it's the failure mode you hit without them. As a single agent's responsibilities grow, three things degrade together:

• Prompt overload. One instruction block trying to cover billing tone, refund eligibility, shipping SLAs, and escalation rules becomes self-contradicting. The model spends attention deciding which job it's doing instead of doing it.
• Tool sprawl. Give one agent twenty tools across four connectors and its tool-selection accuracy drops. It calls the Shopify lookup on a billing ticket, or updates the wrong field.
• Blurred responsibility. When something goes wrong, you can't tell which part of the mega-prompt is at fault, so every fix risks regressing another behaviour.

The practitioner guidance is blunt about this: a widely-cited Towards Data Science breakdown names "overloaded prompting, poor tool routing, and unclear agent responsibilities" as the exact signals that it's time to split. Specialisation fixes all three at once — a billing agent with five tools and a 200-word prompt is simply more reliable than a generalist with twenty tools and a 2,000-word one.

There's a scaling argument too. Specialists run in parallel and stay independently testable, which is why enterprise deployments lean multi-agent as volume climbs — but for most support teams the reliability win arrives long before the scale one does.

How sub-agents work in Macha

Macha builds this directly into the agent model. Every agent you create is a potential sub-agent for another — there's no separate "orchestrator" object to learn. You design specialists the same way you design any agent, then wire delegation between them.

On the agent configuration page, a Sub-Agents block — "Delegate tasks to other agents" — sits alongside the agent's tools and data sources. Linking another agent there turns it into a callable specialist: the parent now has a "hand this off" capability the same way it has a "look up an order" tool.

A few design choices matter, and Macha's are deliberately conservative:

• Each sub-agent keeps its own model, tools, and knowledge base. Your triage agent can run a fast, cheap model to classify, while a billing specialist runs a stronger one for the tricky reasoning. You pay for the heavy model only on the tickets that reach it.
• Delegation goes up to three levels deep, with circular-reference prevention. A parent can call a specialist that calls a sub-specialist — but the system blocks loops (A → B → A) so a misconfiguration can't run away. The AI Agent Builder runs the same circular-dependency check when it wires agents up for you.
• Sub-agents are read-only in interactive chat, and can write in autonomous mode. During live chat a delegated agent can look things up but not change them — a safety default. When the parent is fired by a trigger (a new ticket, a webhook), sub-agents are allowed to take write actions like posting a reply or updating a ticket. You get caution where a human is watching and capability where the workflow is doing the work end to end.

Seeing what each sub-agent did

The thing that usually makes multi-agent systems scary is opacity — you can't tell what the second agent actually did. Macha closes that gap. Every sub-agent invocation produces its own conversation record linked back to the parent. In chat, an expandable card appears under the delegated message showing the sub-agent's avatar, handle, model, connector logos, and tool count, with a green "Handed off" badge. Expand it and you get the full nested run — system prompt, every tool call with its arguments, every tool result, and the final reply — rendered like any other conversation. Those sub-runs are kept for 45 days but stay out of your user-facing conversation count, so audits are easy and your metrics stay clean.

The Agents list also gained a Sub-agents column showing how many specialists each agent has wired up; hover and you see their names. It's a small thing that makes a wide multi-agent setup legible at a glance.

A worked pattern: triage → specialists

Here's the shape most support teams should start with, mapped to Macha agents:

The triage agent never tries to be the billing expert — it just recognises a billing ticket and delegates. Each specialist stays small and sharp. And when a ticket genuinely needs a human, the specialist that gathered the context is best placed to escalate cleanly — the same logic behind escalating with a full context bundle rather than dumping a raw ticket on an agent.

This composes nicely with everything else Macha sits on. Because the whole system runs as a layer on top of Zendesk and the rest, the specialists read and write through the helpdesk your human agents already live in — no migration, no parallel inbox.

When NOT to reach for multi-agent (the honest part)

Multi-agent is a tool, not a trophy. Reaching for it too early is a classic over-engineering mistake, and the best guidance on agents is unusually candid about this. Anthropic's Building Effective AI Agents argues for finding the simplest solution that works and only adding complexity when it delivers measurable value — because agentic systems trade latency and cost for performance. The trade is real: practitioner write-ups estimate multi-agent setups can consume roughly 10–15× more tokens than a single agent, since every delegation is another model call with its own context. (Towards Data Science lists the same costs: more latency, more spend, more moving parts to maintain.)

So skip the orchestra when:

• One agent with a tight prompt and a handful of tools is already resolving the tickets. If it isn't broken, splitting it just adds calls and credits.
• Your volume is low. The reliability gains from specialisation are worth the most at scale; at ten tickets a day the extra coordination rarely pays for itself.
• The work is genuinely one task. "Answer FAQs from the help center" is a single agent. You don't need a router to point at one specialist.
• You haven't measured a single-agent baseline yet. Build the simple version, watch where it actually fails, then split along those failure lines. Splitting on a guess produces agents that are specialists in the wrong things.

The honest rule: add a sub-agent when a specific, repeating failure points at a specific missing specialist — not because multi-agent sounds more sophisticated.

What it costs

Macha is priced in credits, and credits are spent per AI action — so a multi-agent run costs the sum of its parts. A triage hand-off that fires one specialist is two agent messages, not one; a chain that touches three agents bills three. The lever you control is the model per agent: credits run from roughly 0.5 to 9 by model, with the default GPT-5.4 Mini at 1. Putting a cheap model on the high-volume triage agent and reserving a stronger one for the specialist that only sees the hard tickets is the single biggest cost optimisation in a multi-agent design. See the pricing page for current plans and per-model rates — sub-agents are part of Macha's core agent model, so the cost lever you tune is the model assigned to each agent rather than a premium add-on.

FAQ

What's the difference between a multi-agent system and a single agent with lots of tools? Boundaries. A single agent holds every responsibility, tool, and instruction in one context. A multi-agent system splits those across specialists that each do one job well, with a router delegating between them — which improves tool-selection accuracy and makes each agent independently testable.

How deep can delegation go in Macha? Up to three levels — a parent can call a specialist that calls a sub-specialist — with automatic circular-reference prevention so agents can't loop back on each other.

Can a sub-agent take actions, or only look things up? Both, depending on context. In interactive chat, sub-agents are read-only for safety. When the parent runs autonomously via a trigger, sub-agents can perform write actions like posting replies or updating tickets.

Will I be able to see what a sub-agent did? Yes. Every delegation produces a linked, expandable "Handed off" card in chat showing the sub-agent's model, tools, every tool call and result, and its final reply. Sub-runs are retained for 45 days and kept out of your user-facing conversation count.

Is multi-agent always better than a single agent? No. It trades latency and cost (often much higher token usage) for reliability on complex, multi-step work. For low volume or genuinely single-task workflows, one well-scoped agent is the right call. Build the simple version first, then split where it measurably fails.

Start with one, grow into a team

The case for sub-agents isn't "more agents are better." It's that boundaries make agents reliable — and when your support work has real, distinct specialties, modelling them as separate agents beats cramming everything into one prompt. Start with a single agent, watch where it breaks, and split along those seams. Macha lets you do exactly that without leaving your helpdesk: design specialists, wire delegation, and see every hand-off in full.

Want to try it? Start a 7-day free trial, no credit card required, build a triage agent, link your first specialist, and read the sub-agents docs for the full walkthrough. More on agent design over on the Macha blog.

Written by Abbas (Customer Support & AI, Macha) · Reviewed by Ankeet Guha (Co-founder & CTO) · Published 2026-06-24 · Last updated 2026-06-24.