Search2oSearch2o
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;a notification says when it is doneevery 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 the definition; 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. The developer writes a plain-English description of what the 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 — or a few candidates when the request is ambiguous, or none when nothing fits.
  2. The agent server runs the chosen agent in its controlled runtime. The agent calls LLMs and your systems, may ask the user for more input, and streams its output back to the user as it goes.
  3. When the agent finishes, the conversation context is encrypted and stored in the cloud.
  4. A follow-up request continues the conversation. The context is restored, and the same agent or a different agent runs with that context, so agents build on each other's work.

Keeping servers consistent

GUIadministrator 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 — LLM profiles, allowlists, limits, prompts — is edited in the GUI and stored in the cloud. Each time an agent starts, the agent server asks the cloud what has changed since the server last looked. The server fetches only those parts and applies them before running the agent. A change is therefore live on the very next run on every server, and two servers starting the same agent at the same moment run with the same configuration. See How configuration works.