Agents building on each other

Search2o has no orchestrator. An agent runs, answers and ends; it cannot run another agent. What lets agents build on each other is the conversation: every agent in it starts from what the earlier agents left there, and the client decides which agent runs next.

What a later agent inherits

When an agent ends or pauses, its conversation state is saved. The next agent in the conversation, whichever it is, starts with two things from the agents before it.

The conversation variables, conv., which any agent in the conversation sets and reads. An agent puts what later agents will need there: the trip it booked, the order it looked up, the customer it identified.
The prompt history: the user turns and the model's answers so far, when the agents' prompts share a name and the conversation scope. The account's developers agree on a standard prompt name, and an agent that uses it continues the exchange where the last agent left it. See Sharing a history between agents.

An agent's own variables, agent., are also kept, but only for that agent. Nothing else is handed over: not the earlier agent's definition, not its tools, not its credentials. All of it is per conversation: another conversation cannot see it, and a conversation belongs to one user, so another user cannot see it either.

Who decides what runs next

The client that sends the requests. It holds the conversation id, sends each request through search and runs the agent that comes back with execAgent on the same conversation. Search2o supplies the agents; the client supplies the sequence.

The bundled UI and the chat bots take one request at a time. A follow-up is searched like a new request, the best match runs with the conversation's state in place, and when nothing new matches the agent that answered last answers again. See Search settings.
An agent harness with the Search2o skill, such as a coding assistant or a desktop assistant, handles a request with several parts: it splits the request, sends each part through search and execAgent in turn on one conversation, and composes one answer from the results. Each agent sees what the earlier ones produced. See Finding and running an agent.
Your own client on the REST API makes the same two calls and applies whatever plan it likes: a fixed sequence of agents, a loop until a condition holds, or a choice between the two best matches offered to the user.

Agree on names

Agents build on each other through names, and nothing enforces them. A second agent continues the exchange only when its prompt has the same name as the first agent's; it finds what the first agent saved only under the variable name the first agent used. Two developers who choose different names produce two agents that run in the same conversation and share nothing.

So an organization agrees on a naming scheme before its agents can work together, and keeps it where every developer finds it:

One prompt name for the exchange with the user, such as chat, with the conversation scope. Every agent that should see what was said before uses it. Other names are for histories an agent keeps to itself.
A name for each thing agents hand to each other, such as conv.trip, conv.customer or conv.order, with a note of what it holds and which agents set it. An agent reads a conv. variable only after checking it is set, because a follow-up can reach it in any order.

An agent that follows the scheme fits into any conversation in the account. One that invents its own names starts from nothing and leaves nothing the next agent can find.

Writing agents that build on each other

Give the agent one job, and describe that job for the person who will ask for it. Search sends each part of a request to the agent built for it.
Use the account's prompt name, with the conversation scope, for the exchange with the user. Use another name with the local scope for one-off work inside a run, such as classifying or extracting, that no later agent should see.
Save what a later agent will need in a conv. variable, and read what earlier agents saved there instead of asking the user again. Variables are kept only when the run ends with end or pauses on ask; a run that fails leaves the conversation as it was.
Do not assume which agent ran before. A follow-up can reach an agent in any order, so read a conv. variable only after checking it is set.