Search2oSearch2oAgent server for the enterprise
Docs / Introduction

How it fits together

From a developer writing an agent to a user getting an answer.

Building an agent

Draftprivate, JSONCValidatecheck + runPublishnew versionDescribeplain EnglishIndexedfound by searchthe cloud checks the definition and its expressions;the agent server runs the validation query with tracing oncloud indexes the description;15 to 30 secondsevery edit creates a new draft; changes to a published agent go through a draft too
From a draft to a searchable agent
  1. A developer creates a draft and writes the agent in JSON, in the editor or with Draft with AI.
  2. The developer validates the draft. Search2o Cloud checks the definition and every Python expression in it. The agent server then runs the draft against a validation query the developer supplies and shows the full execution trace.
  3. A validated draft is published. Other developers can now see the agent, and users can run it.
  4. In a separate step, the developer writes a plain-English description of what the published agent does. The cloud indexes the description, and from then on search can find the agent.

Answering a query

1. Queryuser types a request2. Matchcloud picks the agent3. Runagent server executes4. Streamoutput as it happens5. Savestate stored, encryptedfollow-up: the state is restored and the conversation continues
From a query to an answer
  1. A user types a request in the search box or in a connected chat application. The agent server sends the request to the cloud, which returns the matching agent: one agent, several candidates when the request is ambiguous, or none when nothing fits.
  2. The agent server runs the chosen agent in the agent runtime. The agent calls LLMs and your systems, may ask the user for more input, and streams its output back as it runs.
  3. When the agent finishes, the conversation context is encrypted and stored in the cloud, or stored by your own code if the account keeps conversations in its own enterprise.
  4. A follow-up request continues the conversation. The context is restored, and the same agent or a different one runs with it, so agents build on each other's work.

Keeping servers consistent

UIadministrator edits a partSearch2o Cloudstores it, stamps the timesaveAgent server AAgent server BAgent server Con every agent start:1. tell the cloud a run starts2. learn the latest change time3. fetch only the changed parts4. rebuild the runtime, then runEvery change is live on the next run, on every server; a running agent keeps the runtime it started with.
How a configuration change reaches every agent server

Configuration, such as LLM profiles, allowlists and limits, is edited in the UI and stored in the cloud. Each time an agent starts, the agent server asks the cloud what has changed since the server last checked, fetches only those parts, and applies them before the run. A change is live on the next run on every server, and two servers starting the same agent at the same moment run with the same configuration. See Runtime sync.