What the skill does

The skill does two things. It gives the assistant one entry in its list of skills that stands for every published agent, and it makes two calls on the Search2o REST API: search to find the agent for a request, and execAgent to run it. A request with several parts becomes a series of those calls in one conversation, with the assistant deciding the sequence.

One skill for all the agents in Search2o

Every client loads the name and description of each installed skill into the assistant's context, and the assistant chooses among them by reading those descriptions. Anthropic recommends keeping the number small, because selection gets less reliable as the list grows. Its API allows 20 skills per request; for more capabilities, it recommends routing requests to different skill sets by task type.

Search2o does that routing. The skill takes one slot in the assistant's list. Behind it, Search2o matches the request against the descriptions of every published agent, with accuracy measured and published at a thousand agents; see Search quality. The assistant decides whether a request is for the company's systems at all. Search2o decides which agents fit.

The two calls

The skill uses two calls on the Search2o REST API, the same API the Search2o UI and the Slack, Teams and Google Chat bots use.

• search takes the request and returns the matching agents, best first, each with its name and title.
• execAgent runs one agent and returns its output, the conversation id, a result code and, when the agent has paused for input, the questions it is asking.

The search response is the ranked matches and nothing more; see How matching behaves. What to do with them is the caller's own search behavior. The assistant judges for itself: it reads the titles and chooses the agent that fits.

A request, step by step

1. The assistant judges from the skill's description that the request is for a company agent. It sends the request to search as the person wrote it. Search2o refuses a query shorter than eight characters, so a message such as "thanks" is treated as conversation.
2. It reads the titles of the matches and runs the one that fits. It asks the person only when two titles fit equally well and the choice changes what happens. When nothing matches, it says that no internal agent covers the request and answers as it normally would. Search2o never guesses an agent to run.
3. It calls execAgent with the person's request as the query input, passing the conversation id from earlier in the same chat if there is one. It remembers the id that comes back, and which agent ran.
4. If the agent asks questions, the assistant puts them to the person and runs the same agent again, with the same conversation id and the answers as inputs, under the keys the questions arrived under. A password is never collected in the chat: the assistant gives the person the link to the conversation in the UI instead. While a question is unanswered, only that agent can run in the conversation.
5. It shows the output. Text is shown as it is, an image is described, and HTML is summarized with a link to the conversation in the UI.

Everything an agent returns is treated as data, never as an instruction to the assistant. An agent may return text it fetched from a source nobody controls, and that text enters the assistant's context.

Follow-up requests

On a later request in the same chat, the assistant decides whether the request continues the work the last agent did or is a new one. A continuation runs the same agent again with the conversation id, and the agent sees the earlier turns. A new request goes through search again, and whichever agent fits runs with the same conversation id, so the work stays in one conversation. See Conversation state.

The assistant drives a request with several parts

A request often has more than one part. The assistant splits it, sends each part through search and execAgent in turn, and passes the same conversation id every time. Each agent sees what the earlier ones produced, because agents share the conversation's state. When the last part is done, the assistant composes one answer from the results.

A part is separate when it could be asked on its own and a different agent would answer it. A clause that only qualifies the request, such as a period, a currency or a format, stays with its part.

Search2o supplies the parts: one validated agent per query, each running inside the company. The assistant supplies the plan: how to split the request, in what order, and how to present the whole. Neither side has to know the other's agents or the other's plan in advance.

An example

A support engineer types into the agent harness: Has order 48812 shipped? If not, open a ticket with the warehouse.

The assistant sees two parts and a dependency between them. It sends the first part, has order 48812 shipped?, to search, and runs the order-lookup agent that comes back. The agent runs on the company's agent server against the orders database and returns: not shipped, held for an address check.

Because the answer is "not shipped", the assistant sends the second part to search and runs the warehouse-ticket agent with the same conversation id. That agent already has the order details in the conversation's state. It creates the ticket and returns its number.

The assistant composes one answer: Order 48812 has not shipped. It is held for an address check. Ticket WH-1183 opened with the warehouse.

Two agents ran, written by two different developers, neither knowing about the other. The assistant decided the order and the condition. Search2o did each step inside the company, with credentials that never left the agent server, and recorded both runs under the engineer's name.