Core Concepts

Agent Networks

Agent Networks let you build multi-agent systems where a single Orchestration agent coordinates a team of specialized sub-agents to tackle complex, multi-step tasks that a single agent could not efficiently handle alone.

What are Agent Networks?

An Agent Network is a hierarchy of AI agents working together. At the top sits an Orchestration agent that receives the user's request, decides which sub-agents to delegate work to, and synthesizes their responses into a final answer. Each sub-agent is a specialist focused on a narrow domain — it has its own tools, instructions, and context.

Network anatomy

OrchestratorReceives the request, reasons about which sub-agents to call, aggregates results, and returns the final response to the user. It does not call tools directly.

Sub-AgentExecutes a specific task using its own tools and instructions. It returns a result back to the orchestrator. Sub-agents are invisible to the end user.

How It Works

When a message arrives at an Orchestration agent, the following sequence occurs:

1Receive request — The user sends a message to the orchestrator via the standard Chat API.
2Plan & delegate — The orchestrator analyses the request and routes sub-tasks to the appropriate sub-agents.
3Execute — Each sub-agent runs independently, calling its own tools as needed.
4Synthesize — Results are returned to the orchestrator, which combines them into a coherent final response.

Sub-agent calls happen server-side and are transparent to the end user. The caller only ever interacts with the orchestration agent via the Chat API — the network topology is hidden.

Orchestration Agent

Create an Orchestration agent in the dashboard by setting its Role to Orchestration. Once selected:

• The agent type is locked to Conversational.
• The tools and MCP tools fields are hidden — orchestrators delegate, they don't act.
• A Sub-Agents section appears where you assign which agents this orchestrator can delegate to.

Example system instructions for an orchestrator

<instructions> You are a customer support orchestrator for an e-commerce platform. <responsibilities> - Understand the user's request and determine which specialist to involve. - Delegate order-related tasks to the Orders Agent. - Delegate product or inventory questions to the Catalog Agent. - Delegate billing and refund issues to the Billing Agent. - Synthesize responses from sub-agents into a single, clear reply. - If a request spans multiple domains, call all relevant sub-agents. </responsibilities> <guidelines> - Never attempt to look up orders or inventory yourself — always delegate. - If no sub-agent covers a topic, say so and offer to escalate to a human. - Keep replies concise and customer-friendly. </guidelines> </instructions>

Sub-Agents

Sub-agents are ordinary Assistant role agents. They are configured exactly like standalone agents — with their own system instructions, tools, MCP servers, and output schemas — but they are assigned to an orchestrator in the Sub-Agents tab of the orchestrator's configuration.

Keep sub-agents focused. A sub-agent with a narrow purpose (e.g. "handles order lookups only") is easier to maintain and more reliable than a generalist sub-agent. The orchestrator is responsible for knowing which specialist to call.

When to Use Agent Networks

Good fit

• Tasks that naturally split into independent domains (orders, billing, catalog)
• Workflows where different steps require different tools or permissions
• High-volume scenarios where you want smaller, faster specialists
• When a single system prompt would become unmanageably large

Not a good fit

• Simple single-domain tasks — the overhead isn't worth it
• Strictly sequential pipelines — consider Workflows instead
• When latency is critical and sub-agent calls would add too much round-trip time

Example Network

A customer support platform for an e-commerce store might look like this:

Support Orchestrator

├── Orders Agent — getOrder, updateOrder, cancelOrder

├── Catalog Agent — searchProducts, getInventory

├── Billing Agent — getInvoice, issueRefund

└── Shipping Agent — trackPackage, getCarrierStatus

When a user asks "Where is my order and can I get a refund?", the orchestrator calls both the Orders Agent and the Billing Agent in parallel, then merges their responses into a single reply.

API Usage

From the caller's perspective, interacting with an Agent Network is identical to calling any other conversational agent. Simply use the orchestrator's agent ID:

javascript

const response = await fetch('https://api.meebly.ai/v1/chat', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': 'YOUR_API_KEY',
  },
  body: JSON.stringify({
    agentId: 'agent_orchestrator_id',  // The orchestration agent's ID
    environmentId: 'env_xyz789',
    messages: [{ content: "Where is my order and can I get a refund?" }],
    threadId: 'thread_abc123',  // optional — continue conversation
  }),
});

Sub-agent IDs are never exposed to the API caller. All routing, delegation, and aggregation happen internally. You only need the orchestrator's agent ID.

Best Practices

✓Give the orchestrator a clear routing strategy. Its system instructions should explicitly say which sub-agent handles which domain so it doesn't guess.
✓Keep sub-agent instructions narrow. Sub-agents should know their scope — and be told to return structured, factual results rather than user-facing prose.
✓Test sub-agents independently first. Verify each specialist works correctly before wiring it into the network. Use the dashboard sandbox to test sub-agents directly.
✓Deploy through environments. Use the Deployments page to promote your network from development to production — sub-agent assignments are included in the deployment review.

PreviousAgents NextEnvironments

Last updated: March 2026Report an issue