Custom search

The bundled GUI uses the agent server's REST API and nothing else, so an interface of your own can use the same API: search to find the agents for a request, and execAgent to run one. The page, the wording and what happens between the two calls are yours. Some common shapes:

A search page without sign-in

A public page, on an intranet for example, can call the API with a service account's key. The calls run as that service account, with its role, and nobody has to sign in. Every visitor then shares the service account's conversations, so such a page shows no conversation history: each visitor gets a fresh conversation, and a follow-up stays within it.

Letting users pick a catalogue

The search call takes a tag, so an interface can offer tags to its users, as a drop-down of catalogues for example, or search every tag with an empty string. Without a tag, the tag in the Search settings applies.

Deciding what to run

Search returns one, two or three agents, best first, or none when nothing matches; see How matching behaves. An interface can run the first match, show the choice, or run only when there is exactly one. The response carries the account's searchBehavior and followupBehavior settings, which an interface may follow or not.

Orchestrator

One can create an orchestrating agent that every user request goes to. The orchestrator splits the request with an LLM, matches each part to an agent with the search command, and invokes each agent in sequence. This is close to how agent orchestration is done in the industry today.