Skip to main content
Agents don’t have to work alone. Abundly supports two distinct approaches for agents to collaborate: delegation to temporary sub-agents, and agent-to-agent communication between persistent agents.
Agent-to-agent communication settings

Delegation vs agent-to-agent

DelegationAgent-to-Agent
What it isAgent creates a temporary sub-agent on the flyTwo persistent agents exchange messages
ConfigurationJust enable the capabilitySelect which agents can talk to each other
From user’s viewOne agent to manageMultiple agents to configure
Best forContext management, parallel processingReusing specialized agents

Delegation

Delegation lets an agent create a temporary sub-agent to carry out a specific task. The sub-agent does its job and vanishes—no configuration required, no extra agents to manage. The parent agent provides:
  • A task description with all necessary context
  • Which capabilities the sub-agent should have
  • Optionally, document references for the sub-agent to read or write
  • Optionally, a different LLM (e.g., a cheaper model for simple tasks)

Why delegate?

The primary reason is context management. When an agent processes large documents sequentially, its context window fills up quickly—degrading performance, increasing costs, and raising the risk of hallucination.

Example: Contract compliance review

Suppose an agent reviews contracts against three compliance standards. Each standard is a substantial document. Without delegation: The agent reads the contract and Standard A, then assesses compliance. Now it has the contract, the full standard, and the assessment in its context. Then Standard B—two full standards plus assessments. By Standard C, the agent is drowning in content.
Main agent with bloated context containing the contract and all three standards
If issues arise and the user starts a discussion, every subsequent message carries all that accumulated context. The agent becomes slow, expensive, and unreliable. With delegation: The agent creates three sub-agents, each checking a single standard. Each sub-agent reads only the contract and its assigned standard, then returns a concise assessment. The main agent combines the results.
Main agent delegating to three sub-agents, each with focused context
The main agent’s context stays clean. Each sub-agent is focused and efficient. The user can continue the conversation without the agent getting bogged down. You still pay the token cost of reading each standard—but only once per standard, in the sub-agent. That cost isn’t repeated for every message.
This mirrors how humans delegate. When you ask a colleague to check if a contract complies with a standard, you just need the result—does it comply, and if not, what are the issues?

When to use delegation

  • Large documents — Offload document processing to keep the main context clean
  • Parallel analysis — Multiple sub-agents can work on independent tasks simultaneously
  • Focused tasks — Sub-agents get exactly the context and tools they need, nothing more
  • Cost optimization — Use cheaper models for simpler sub-tasks

Enabling delegation

Enable the Delegate Task capability on your agent. No other configuration is needed—the agent handles the rest through a simple tool call.

Agent-to-agent communication

Agent-to-agent communication connects persistent agents that you’ve already created and configured. Each agent has its own instructions, capabilities, LLM settings, and documents. When one agent calls another, it’s asking a fully-configured colleague for help.
Coordinator agent communicating with specialized agents

How it works

  1. Configure access in Settings → Agent-to-Agent Communication. Select which other agents this agent can talk to.
  2. The agent knows the name and description of each available agent—nothing more. It can ask the other agent what it can do, or you can explain it in the calling agent’s instructions.
  3. When calling, the agent can optionally share documents—granting temporary read or read-write access so the other agent can work with them.

Example: Social media expert

You have a Twitter agent that’s an expert at posting on X/Twitter. It has the Twitter capability, specialized instructions, templates for different post types, and examples of good tweets. When your main agent needs to tweet something, it calls the Twitter agent. Maybe it shares a document with campaign details, or asks the Twitter agent to search for trending topics and update a shared document with findings. The main agent doesn’t need to know how Twitter works or have the Twitter capability enabled—it just calls the expert.

Example: Reusable ICP checker

You have an Ideal Customer Profile (ICP) agent that researches whether a potential customer is a good fit. It knows your criteria, has access to research tools, and has refined instructions based on experience. Multiple agents can now use this ICP checker: your sales agent asks it to evaluate new leads, your marketing agent uses it to qualify inbound inquiries, your partnership agent checks potential partners. The logic lives in one place.

When to use agent-to-agent

  • Reusable expertise — Share a specialized agent across multiple contexts
  • Separation of concerns — Keep complex logic isolated in a dedicated agent
  • Team structure — Mirror your organization with agents for legal, finance, research, etc.
  • Existing agents — Leverage agents you’ve already built and refined

Risks of agent-to-agent communication

Cost: Agent-to-agent communication increases credit consumption. Agents spend tokens talking to each other, and each agent has its own system prompt as overhead. Use this feature when the benefits outweigh the added complexity and cost. Indirect access to sensitive data: If Agent A has access to sensitive data (e.g., a customer database or financial records), any agent that can talk to Agent A may be able to obtain that information indirectly. Users chatting with Agent B could ask it to query Agent A, effectively gaining access they weren’t meant to have. Be deliberate about which agents can communicate with each other, especially when sensitive capabilities are involved.

Alternative: Task documents

Before adding more agents, consider whether a single agent can handle multiple tasks. You can write different sections in its instructions, or create separate documents describing different tasks or workflows—the agent reads them on demand.
Agent documents containing task-specific instructions: How to post on Twitter, How to format an email, How to conduct a security review
For example, instead of a separate Twitter agent, you might have one agent with a document describing how to use Twitter/X. The agent reads that document when needed, keeping its main instructions focused.

Which approach should I use?

Start simple. Begin with a single agent. Add delegation when you need to manage context or parallelize work. Consider agent-to-agent when:
  • You want to reuse an agent from multiple different contexts
  • You already have a specialized agent that’s good at a specific task
  • You want different agents to have different capability sets and maintain their own documents
For complex workflows, experiment to find the right approach—single agent, single agent with task documents, delegation, or agent-to-agent. The best solution balances value, complexity, and cost, and finding it takes iteration.
Not sure which approach fits your use case? Reach out to us—we’re happy to help you design the right architecture.
Yes. An agent can use delegation for context-heavy tasks while also calling other persistent agents for specialized expertise. Choose the right tool for each situation.
No. Sub-agents cannot delegate further—this prevents runaway resource usage and keeps things simple.
In agent-to-agent communication, the receiving agent knows the name of the calling agent. For delegation, the sub-agent only knows it’s executing a delegated task—it has no information about the parent.
No. Agents can only communicate with other agents in the same group (or both ungrouped). This isolation is intentional for security and organization.

Communicating with external agents

Abundly is designed to play nicely with other platforms—no lock-in. Calling external agents: Your agent can talk to agents outside Abundly via MCP (if the external agent exposes itself as an MCP server) or via HTTP requests (works with any API). Give your agent the capabilities it needs, then update its instructions to explain how to communicate with the external agent. Being called by external agents: Enable API access to expose your agent as a service. There you can create API keys that allow external applications to send HTTP requests directly to your agent.

Learn more