Users do not choose agents. They say what they need.
Search reads a request in plain language and returns the agent built to handle it. Here is the exchange, as the bundled UI, a chat bot or your own interface makes it.
// the request
{ "query": "Book a trip to New York" }
1The user’s words, as typed. No agent name, no keyword, no menu.
// the response
{
"success": true,
"searchResults": [
2Zero, one or two agents, best first. One when the request clearly belongs to it, two when the request is ambiguous or two descriptions overlap, none when nothing fits. Then nothing runs. {
"agentName": "travel_desk",
3Search only matches. The interface calls execAgent with the agent name and the same request, at once or after offering the user the choice. "agentTitle": "Travel desk"
}
]
}- 1The user’s words, as typed. No agent name, no keyword, no menu.
- 2Zero, one or two agents, best first. One when the request clearly belongs to it, two when the request is ambiguous or two descriptions overlap, none when nothing fits. Then nothing runs.
- 3Search only matches. The interface calls
execAgentwith the agent name and the same request, at once or after offering the user the choice.
Search works from meaning, not words. A request and a description need not share a word, or a language. A search takes about 200 milliseconds, on our side, and a thousand agents are searched as quickly as a hundred.
The description is what search matches against
When an agent is published, its developer describes it in plain language. Search indexes the description within half a minute. This is the description the request above matched.
Arranges air travel and hotel stays for business travel. Books flights and hotel nights for the dates and the city the traveler names, holds a booking when the traveler is not ready to confirm, and answers questions about an existing booking. It does not file expenses and does not approve travel.
A description is written for the person who will type the request. It says what the agent does for the user: the questions it answers, the actions it takes, what it leaves to others. Two to five sentences is typical. A description that names only the mechanism, such as “calls the travel API and summarizes the JSON”, matches poorly, because nobody asks for a mechanism; search returns it to the developer with an explanation of what to change. When two agents overlap by accident, a request in the shared territory returns both, and sharper descriptions separate them. See describing an agent.
Tags split an account’s agents into pools, one for the help desk and one for finance, and a search names a pool or searches them all.
Ask for something, in your own words
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.
Measured on 15,000 questions, against the live service
Six catalogs of agents, from a university to a thousand agents across fifty business areas. 15,000 questions, each with a known right agent. Every question went through the search we ship.
The right agent comes first 84% to 91% of the time, depending on the catalog, and is one of the first two 92% to 97% of the time. A request about something else entirely is always refused; a request about the customer’s own world that no agent covers is refused 82% to 86% of the time. A search takes about 200 milliseconds, on our side. A thousand agents score within a point of a hundred. What separates the easy catalogs from the hard ones is how far apart their agents sit, and the descriptions decide that. The search quality page has every table and the conditions behind each number.
Where to read more
The search section of the documentation covers how matching behaves, describing an agent, tags, search behavior and search quality. The REST API’s search call is the search box as an API call.