6. Composing Agents

By now you can tune an Agent well, and you can trigger it from a variety of channels. This chapter covers a new dimension—letting Agents call each other.

Why do this? Because many tasks are inherently multi-role: after writing code, have another Agent review it; after finishing a translation, have another Agent run QA; after triaging a request, hand it off to the real expert. Splitting these roles into separate Agents, each tuned well, and then composing them to work together is often more stable and more maintainable than training one “knows everything” Agent.

How it works

Neutree Agent Platform (NAP) lets one Agent call another Agent like a tool within a conversation. To make a Workspace callable by others, you need to do two things:

1. Give it a recognizable Slug
2. Set its Visibility

Open Workspace Settings and find the Slug and Visibility fields.

Slug

The Slug is the Workspace’s unique identifier, by which other Agents reference it. For example qa-checker, code-reviewer, translator.

• Only lowercase letters, digits, and hyphens are allowed
• Leave it empty to make the Workspace non-callable by other Agents

Visibility

Visibility	Who can call it	Call syntax
Private	Not callable	—
User	Your own other Agents	@agent/slug
Public	Any user’s Agents on the platform	@agent/username/slug

Calling another Agent in a conversation

After setting the Slug and Visibility, write this in the calling Agent’s conversation:

After writing this plan, have @agent/reviewer review it for me

The calling Agent automatically handles the cross-Workspace communication: it passes the context over, waits for the callee to return a result, then integrates it back into the current conversation and continues working.

You can also use background mode—send it off without waiting, letting the callee work at its own pace in its own Workspace, and report back via a notification or by writing a file when done. This suits longer-running tasks.

When you need to pass large amounts of material or generated artifacts between Agents, don’t stuff them into the prompt—use AFS (cross-Agent file sharing): write the file to a shared directory, grant access to the collaborator, and they can read it directly at the same path inside their own container.

A few typical collaboration patterns

Different business scenarios call for different collaboration structures. Here are the three most common ones:

1. Triage → Expert

The entry point is a triage Agent with a very short Prompt whose sole job is to judge “which category is this problem” and then hand it off to the corresponding expert Agent.

You are a triage assistant. User requests fall into one of three categories:
- Translation-related → hand off to @agent/translator
- Code issues → hand off to @agent/code-helper
- Other → hand off to @agent/general

After deciding, state your judgment in one sentence, then call the corresponding agent.

The benefit: each expert Agent can be tuned, swapped to a different model, and maintained independently. Adding a new category just means adding a new expert, without changing the others.

2. Pipeline

A task has fixed multiple steps: A finishes and hands off to B, B finishes and hands off to C. Each step is an Agent.

Example: a translation pipeline —

• translator —does the translation
• qa-checker —checks translation quality
• formatter —outputs in the target format

After translator finishes, it calls qa-checker; once QA passes, it calls formatter. Any step that goes wrong can be pinpointed to a specific Agent.

3. Planner + Worker

A planner Agent breaks down the task and plans the steps, then hands each step to a corresponding worker Agent, and finally aggregates the results.

This suits scenarios where the task structure isn’t known in advance—the planner only knows how many steps to break it into and whom to call after reading the requirements.

Teamwork: task-level multi-Agent collaboration

The above describes long-lived, fixed collaboration relationships—A has a stable Slug, B is visible long-term and callable at any time, and the directory stays mounted. But a lot of collaboration is actually one-off:

“This time I want to pull in two Agents to help me do a piece of research, then disband once it’s done.”

“I want to bring my private Agent in for a single use, without permanently promoting it to user/public visibility.”

For this scenario, NAP provides Teamwork (in preview). Find the Teamwork entry under “Apps” and create a team task:

1. Designate a coordinator Agent—it’s the main Agent, and all sub-agent calls are initiated by it
2. Add members—the candidate list includes all public / user visible Agents, plus your own private Agents (if one doesn’t have a slug yet, you can set it up right here). A private Agent added to a task is only visible within that task and doesn’t affect other scenarios
3. Start the conversation—the platform automatically creates a shared directory for this task and mounts it for all members; mounting/unmounting happens automatically as members join/leave; the directory is reclaimed automatically when the task ends

The task detail page has a collaboration timeline: one line per member’s session, each call_agent lands a point on the line, showing the main→sub sub-message, the sub→main result, and whether the call is synchronous or asynchronous. Very intuitive when debugging multi-Agent collaboration.

When to use Teamwork vs. when to keep using plain @agent:

• Long-lived, fixed collaboration → configure Slug + Visibility, the approach in the first half of this chapter
• One-off tasks, needing to temporarily pull in a private Agent, needing shared files—use Teamwork

For the full design motivation and how it works, see the Teamwork concepts page.

Some practical experience

Keep each Agent’s responsibility narrow. A “knows everything” Agent is hard to tune. One Agent doing one thing well beats five Agents each doing half a thing.

Keep Slug names stable. Once other Agents reference your Slug, renaming it breaks those references. Think it through before settling on a name.

Try Private/User first, then go Public. Public exposes the Agent to the whole platform—any user’s Agent can call yours. Unless you really intend to build a public capability, it’s better to be conservative.

Don’t nest call relationships too deep. A calling B calling C calling D is allowed, but each extra layer doubles the latency and makes troubleshooting harder. Three layers or fewer is a manageable range.

Next

By now you’ve covered both the Agent’s “capability surface” and its “collaboration surface.” The final chapter covers how to reuse, share, and scale these capabilities → Guide 7: Operating at Scale.