Conversations let agents build on each other.
A conversation keeps what every agent in it did, said and was told. A follow-up is searched like a new request, and the agent that matches continues from that record. No agent calls another; the conversation carries the work from one to the next.
A conversation is an object that the agent server saves after every successful agent run, automatically. A request that carries the conversation’s id restores it, automatically, before the next agent runs. A request without an id starts a new, empty conversation.
The object holds two things. Variables: whatever an agent explicitly set in the conversation scope, under conv.. Prompts: every prompt an agent used at the conversation scope, with its history of user turns and model answers.
That is what lets agents build on each other. The next agent in the conversation, whichever one search matches, reads the variables it needs, if they are set. When it uses a prompt with the same name as an earlier agent, the restored history already holds that agent’s exchange, and the model continues from it. No agent calls another, and nothing wires two agents together in advance.
What a conversation keeps
When an agent ends or pauses, the agent server saves the conversation’s state. The agent does nothing for this. The next run in the conversation, by the same agent or another, starts from it. Another conversation cannot see it, and a conversation belongs to one user, so another user cannot see it either.
The runs so far. Which agent ran, with which inputs, what it answered, and where it stopped when it paused with a question.
The prompts. For every prompt used in the conversation, its history: the user turns, the model’s answers and the tool results. This history is what lets a model in a follow-up remember the earlier exchange.
The variables. Conversation variables, which every agent in the conversation reads and writes, and each agent’s own variables. An agent saves what later agents will need as a conversation variable, like the trip.
Prompts carry the exchange
A prompt is what an llm command sends to a model: a system text, a user text and the history of the exchange so far. Each prompt has a scope, which says how long its history lives and which agents share it.
conversation, the default. One history for the whole conversation, shared by every agent that has a prompt of the same name. A second agent sees what was said to the first.
agent. The agent’s own history for the whole conversation. Another agent in the same conversation does not see it.
local. A history for one run, empty at the start of every run. For one-off tasks inside a run, such as classifying or summarizing, where earlier runs should not influence the answer.
Each prompt has a name, and the name is what connects agents. A second agent continues the first agent’s exchange only when its prompt has the same name and the conversation scope. A prompt with another name starts a history of its own. How a prompt is written and evaluated is in Prompts.
Agree on names
Agents build on each other through names: the prompt name that continues the exchange, and the conversation variables that carry what one agent found to the next. Nothing enforces the names, so an organization agrees on them before its agents can work together.
A naming scheme is short. One standard prompt name, such as chat, for every agent’s exchange with the user. A name for each thing agents hand to each other, such as conv.trip, conv.customer or conv.order, with what it holds. 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. Agreeing on names in the docs.
A follow-up can go to a different agent
A follow-up in a conversation is searched like a new request. When it belongs to another agent, that agent runs next, with the conversation’s state in place. When nothing new matches, the agent that answered last answers again.
What an interface does with the matches is its own search behavior: the bundled UI runs the best match at once; your own interface can offer the two best as a choice.
Which agent runs next is always the client’s decision. An agent cannot run another agent. A request with several parts is driven from outside: an agent harness with the Search2o skill splits it, sends each part through search and execAgent on the same conversation, and composes one answer. How agents build on each other.
Ask for something, then follow up
This demo runs in a live Search2o account with 200 agents, from human resources and finance to engineering and sales. The matched agent runs and answers with mock data. Ask a follow-up and watch the conversation move to another agent that knows what the first one found.
Kept safe, kept yours
State is encrypted before it leaves the agent server, and the cloud never decrypts it. An account can keep the state in its own organization instead of the cloud. On the free service, a conversation unused for 7 days is deleted unless the user pins it, and a user can delete a conversation at any time.
Where to read more
Conversation state covers what is saved and when. Agents building on each other covers who decides what runs next, and Prompts covers scope and the prompt name. In the REST API, running agents covers the call above and conversations covers listing, renaming, pinning and deleting.