How Does Multi-Agent Delegation Work in Macha? Sub-Agents Up to 3 Levels Deep

Macha lets a lead AI agent delegate work to specialist sub-agents up to three levels deep (A calls B calls C), and blocks any circular reference so the chain can never loop back on itself. Each sub-agent is a normal agent with its own instructions, model, connectors and knowledge sources, gets up to 15 iterations to finish its task, and runs read-only in chat but can write when the lead runs autonomously on a trigger (Sub-Agents docs).

It's the fix human support orgs figured out years ago: specialize, then delegate. One mega-agent with forty tools and a 3,000-word prompt gets worse at each job the more jobs it has. A front-line generalist that triages and hands the hard parts to specialists (billing, returns, technical escalations) does better. Macha is an AI agent layer that sits on top of the help desk you already run (Zendesk or any of the others: Zendesk, Freshdesk, Gorgias, Front, HubSpot or Intercom), so everything below happens against your real tickets and your real connected tools.

Why does multi-agent beat one big agent?

The pattern Macha uses is not novel — it's the one the rest of the industry converged on, because the alternatives are worse. Anthropic calls it orchestrator-workers: "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results." In their own multi-agent research system, "a lead agent coordinates the process while delegating to specialized subagents that operate in parallel." Salesforce ships the same shape under Agentforce multi-agent orchestration. Different vendors, same conclusion.

The reasons it wins are concrete:

• Focus. A billing specialist that only sees Stripe tools and the refund policy makes better billing decisions than a generalist juggling thirty unrelated tools. Smaller surface area, fewer wrong turns.
• Right-sized models. Triage is cheap and high-volume; a deep refund judgment call is rare and worth a stronger model. With sub-agents, each agent picks its own model — you spend the expensive reasoning only where it earns its keep, instead of running your whole queue on one tier.
• Isolated knowledge. Each sub-agent carries its own knowledge sources. The orders agent isn't searching your finance docs; the billing agent isn't wading through your shipping SOPs. Cleaner retrieval, fewer cross-contaminated answers.
• Graceful change. You can rework the escalation specialist without touching the agent that handles "where's my order?" — exactly the failure-isolation that makes multi-agent systems easier to maintain than one monolith.

Macha shipped sub-agents in March 2026 — "agents can now call other agents as tools, enabling hierarchical task delegation" — and made it generally available with the three-level depth limit and circular-reference prevention in April.

How does delegation work in Macha?

A sub-agent is just an agent you've wired up as a delegate of another agent. The parent (the "lead") sees its sub-agents as callable tools. When the model decides a message is better handled by a specialist, it calls that sub-agent like any other tool, passes it the context, and gets back a result it can use in its own reply.

A worked shape that maps to a real ecommerce queue:

• Support Lead (the front door) — reads every incoming ticket, answers the easy FAQs itself, and routes the rest. Runs a fast, cheap model because most of its job is classification and hand-off.
• Billing specialist — has the Stripe tools and the refund/subscription policy as knowledge. Handles invoices, failed charges, refund eligibility, plan changes.
• Orders specialist — has the Shopify tools and the shipping/returns SOPs. Handles "where's my order," address changes, return labels.
• Escalation specialist — has the Slack tools and the playbook for what counts as a P1. Bundles full context and pings the right human channel when something needs a person.

The lead doesn't need to be an expert in any of those domains. It needs to know which specialist to call — which is exactly the kind of natural-language routing decision a model is good at. You describe the delegation rules in the lead's instructions; you don't write brittle if/else routing logic. (In the demo workspace the screenshots here come from, that same shape is built as a Ticket Triage lead with Billing Escalations, Ticket + Docs Context, and Runbook Writer specialists wired as its delegates.)

How deep can the delegation chain go?

Delegation is hierarchical. The lead can delegate to a specialist; that specialist can delegate to its own sub-agent. Macha allows the chain to go three levels deep, then stops: the docs say a call beyond that "is blocked." Each sub-agent gets up to 15 iterations to finish its task before it returns a result to its parent.

A realistic three-level chain: Support Lead → Billing specialist → Dunning specialist. The lead routes a payment problem to billing; billing recognizes it's specifically a failed-renewal / dunning situation and delegates to an even narrower agent that knows the retry-and-recover playbook. Each level adds focus.

The depth cap is deliberate. Every level of delegation adds latency (another model round-trip) and cost (another agent doing billable work), and beyond three levels you're almost always better off rethinking the design than adding a fourth tier. Macha also enforces circular-reference prevention: if you try to wire agent A to delegate to B, and B already delegates back to A, the loop is blocked. The AI Agent Builder runs the same automatic circular-dependency check when it assigns sub-agents for you, so you can't accidentally build an infinite hand-off.

What stops sub-agents from doing something unsafe?

Letting agents call agents that call tools is powerful, which means the guardrails matter as much as the capability. Macha's are built around a simple principle: be conservative when a human is in the loop, capable when one isn't.

Read-only in chat, write-enabled when autonomous. This is the most important one. When you're testing or chatting with an agent interactively, its sub-agents run read-only — they can look things up, but they won't fire off a refund or post a public reply behind your back. When the same lead agent is running autonomously via a trigger (a webhook from a new ticket, a scheduled run), sub-agents are permitted to execute write operations — replies, updates, the actions you actually deployed them to take. You get safe exploration during setup and full capability in production, without a config flag to remember.

Full visibility into every hand-off. Delegation is only trustworthy if you can see what the delegate did. As of June 2026, every sub-agent invocation produces its own conversation record linked back to the parent. In chat, a card appears under each delegated message showing the sub-agent's avatar, handle, model, connector logos, and tool count, with a green "Handed off" badge. Click to expand and you get the sub-agent's full nested conversation — its system prompt, every tool call with arguments, every tool result, and its final reply, rendered like the main chat. This works for both interactive chat and autonomous trigger runs, so an agent firing at 3 a.m. leaves the same auditable trail. During a run, sub-agent tool calls also stream live with indentation in the status log, and the tools a sub-agent used show up in the "Tools Used" popup on the saved message.

Roster-level overview. On the Agents page, a Sub-agents column shows how many sub-agents each agent has wired up — hover to see their names. It's the quick sanity check that your delegation graph is what you think it is before anything goes live.

Durable wiring. A delete is reversible — a removed agent sits in Trash for 30 days and restoring it brings back its triggers, sub-agent links, and tool config intact. And sub-agent assignments persist correctly across edits (an earlier bug that silently cleared them on save has been fixed), so re-saving a lead agent to tweak its description won't quietly unwire its specialists.

When should you not use sub-agents?

Multi-agent delegation is a real architecture decision with real costs, and it is the wrong call more often than the hype suggests. Be honest with yourself before you build a hierarchy:

• Simple, narrow queues don't need it. If your agent handles one job well — WISMO, or password resets, or a single product's FAQ — a single well-equipped agent is faster, cheaper, and easier to debug. Don't decompose for the sake of it.
• Every level costs latency. Macha bills per ticket: each agent's reasoning turn and each tool call it runs happens inside the same conversation, charged once. So a deep chain does not cost more than one focused agent answering directly — what it costs is time, because each hop adds a model round-trip the customer waits on. Specialization should be paying for itself in resolution quality, not just adding tiers.

Here is what that actually adds up to. Take a failed-renewal ticket that runs a three-hop chain:

That same Ticket Triage lead answering a simple "where's my order?" directly is 1 reasoning turn + 1 tool call = 2 steps and one model round-trip. Both are one ticket, and a ticket is charged once however many steps it takes — so the three-hop chain costs the same as the direct answer, and what it actually adds is three sequential round-trips of latency. Running a heavier model on the billing hop does not change the price either; the ticket is charged once whichever model each agent runs on. Use the depth where the resolution-quality lift clearly justifies the wait; for everything else, a single agent is faster. See pricing for the per-ticket tiers.

• Over-decomposition is its own failure mode. Five sub-agents where two would do means more hand-off points, more places for context to get lost in translation, and more surface area to maintain. Anthropic's guidance is blunt about this: "we recommend finding the simplest solution possible, and only increasing complexity when needed," and only add agents when the task genuinely can't be predicted up front.
• It's not a replacement for a human escalation path. Sub-agents make routing smarter; they don't make every ticket solvable by AI. The escalation specialist exists precisely so the system knows when to stop delegating and hand a real person the full context.

A good rule of thumb: start with one agent. Split out a specialist only when you can point to a specific class of tickets where the generalist measurably underperforms — and let the Studies and evaluation tooling tell you where that is, rather than guessing.

How do you build a sub-agent team without writing routing logic?

You don't have to wire a delegation graph by hand. Macha's AI Agent Builder can do it conversationally — describe the team you want ("a support lead that routes billing to a Stripe specialist and orders to a Shopify specialist") and it creates the agents, assigns the sub-agents, and runs the automatic circular-dependency check as it goes. You can also add sub-agents inline from an agent's configuration with a quick-add button, the same way you add tools, triggers, and data sources.

Each agent in the hierarchy keeps the full set of knobs: its own connected tools, its own model, its own knowledge sources, its own instructions. That's the whole point — a sub-agent isn't a watered-down helper, it's a fully capable agent that another agent happens to call.

FAQ

What is a multi-agent AI customer support system? It's an architecture where a lead (or "orchestrator") agent receives each conversation and delegates parts of it to specialist agents — billing, orders, escalation — each with its own tools and knowledge, instead of one agent trying to do everything. The lead routes; the specialists execute; the customer never has to repeat themselves.

How many levels deep can Macha's sub-agents go? Up to three. A lead can delegate to a specialist, and that specialist can delegate once more. Macha caps the chain at three levels and blocks any circular reference so delegation can't loop back on itself.

Can sub-agents take actions, or just look things up? Both, depending on context. During interactive chat they run read-only for safety. When the lead agent runs autonomously via a trigger, its sub-agents can perform write operations — replies, updates, refunds — that you've configured them to handle.

Can I see what a sub-agent actually did? Yes. Every delegation produces its own linked conversation record. A "Handed off" card appears under the delegated message showing the sub-agent's model, connectors, and tool count; expand it to see the full nested run — system prompt, every tool call and result, and the final reply. It works for both chat and autonomous trigger runs.

Does delegation cost more? No. Macha bills per ticket — one conversation, charged once however many sub-agent calls and tool calls it takes — so a delegated run and a single-agent run cost the same. What delegation does add is latency, since each hop is another model round-trip; use it where the focus pays off in resolution quality, not as a default. See the pricing page for the current tiers.

Which plans include sub-agents? Every plan. Multi-agent delegation is part of Macha's agent platform, and every tier includes unlimited agents and every feature — tiers differ only in how many tickets a month they cover. See pricing for the current tiers.

How do you start building your agent team?

If your single agent is straining under too many jobs, splitting it into a lead plus a couple of specialists is usually the highest-leverage change you can make. Start a free trial ($50 of usage, no credit card required), connect your helpdesk, and wire up your first sub-agent from the Agents page — or read the Sub-Agents documentation for the full walkthrough and the rest of the Macha docs for triggers, tools and connectors.

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