Work With Other Agents
No single agent is good at everything. Instead of packing every skill into one agent, you can let agents work as a team: your agent asks a specialist agent for help, or other agents ask yours. This step shows you both directions and when each one is worth setting up.
In this step, Atlas, Kirana Group's operations assistant, gets a teammate: Ledger, Kirana Group's finance assistant for vendor payments. Atlas knows Kirana's approval policy and project status. Ledger knows when and how Finance pays vendor invoices. Instead of copying Ledger's payment rules into Atlas, you let Atlas ask Ledger.
Before you start
- Your agent already answers well on its own. See Teach Your Agent.
- You are familiar with tools, because a connected agent works like a tool your agent can call. See Connect Your API or Connect an MCP Server.
- You know how to publish changes. See Preview and Publish Changes.
Two directions, two places in the CMS
| Direction | What it means | Where you set it up |
|---|---|---|
| Outbound | Your agent calls other agents. When a question is outside its expertise, it hands that part to a connected agent and uses the reply in its answer. | Tools → Other Agents |
| Inbound | Other agents call your agent. You make your agent reachable, describe what it is good at, choose which of its tools callers may use, and hand out keys. | Channels → Agent-to-Agent, plus Channels → Agent Keys for the keys |
The two directions are independent and saved separately. You can use one, the other, or both.
Both directions use the open A2A (Agent2Agent) standard, so the other side does not have to be a qlar agent. Before A2A, agents were linked with an older classic connection: the caller entered the other agent's code and one of its agent keys. Classic connections still work and you can still add them on Tools → Other Agents, but the classic method is pending sunset, so use A2A for anything new. Agent keys themselves stay: A2A callers need one too.
When a multi-agent setup helps
Connect agents when:
- Expertise is split across teams. Each team maintains its own agent with its own knowledge, and a front-line agent routes questions to them.
- An agent has tools you do not want to copy. A finance agent already connects to the payment system. Other agents ask it instead of each holding the same credentials.
- Different audiences need different agents. An agent for all employees can ask a team's internal agent for facts, while the internal agent's other tools stay off limits.
Example: Kirana Group runs Atlas for operations and Ledger for vendor payments. A project manager asks Atlas: "A vendor sent a USD 72,000 invoice for the Surabaya warehouse steel. When will Finance pay it, and what does the invoice need?" Atlas's SOPs cover approvals, not payment terms, so it calls Ledger (outbound), gets Kirana's payment rules, and answers the project manager. On the Ledger side, Finance turned on Agent-to-Agent (inbound), wrote example questions such as "When will Finance pay a vendor invoice?", and gave Atlas's owner a key.
Keep it simple when one agent with good knowledge and a few tools is enough. Every extra hop between agents adds response time.
The pages in this step
| Page | What you will do |
|---|---|
| Call Other Agents | On Atlas: connect Ledger with its share link and key, and test the hand-off in Preview. |
| Let Other Agents Call Yours | On Ledger: make it reachable, fill in its agent card, check which tools callers may use, and create a key for Atlas. |
Where to start: if you want your agent to get help from a specialist, start with Call Other Agents. If you own the specialist, start with Let Other Agents Call Yours. When you own both agents, as in the Kirana example, set up the inbound side on Ledger first, because the outbound side on Atlas needs Ledger's share link and key.
Next steps
- Next in the journey: Teach Your Agent Skills, to give your agent written procedures for specific situations.
- Field-by-field reference: Other Agents, Agent-to-Agent and Agent Keys.