Overview

An agent server holds no state of its own, but it does hold a runtime: an in-memory copy of everything an agent needs to run. The runtime is built from the account's configuration at startup and kept current before every agent run. This page describes what the runtime is and how a change reaches the runtime.

What the runtime holds

The runtime is implemented in the agent server's source under search2o/execution/, with runtime.py at the centre. One RuntimeState object holds:

• the allowlist, resolved into the functions and objects an expression may reach;
• the system variables an agent may read;
• the runtime limits and the compile rules;
• the search settings;
• the connection pools, as open HTTP clients;
• every profile, with the open connections of the LLM profiles and the database engines of the database profiles; profiles are described in the Profiles section;
• the secrets source and the encryption settings; both are described under Security and privacy.

Alongside the runtime the server caches the agents it has run. A cached agent is dropped as soon as the cloud reports a newer version, so a republished agent runs in its new form on its next request.

How a change reaches every server

1. A developer or an administrator changes a part or a profile in the GUI. Search2o Cloud stores the change, stamped with the time.
2. Every time an agent run starts, the agent server tells the cloud. The reply carries the time of the latest change.
3. If that time is newer than the server's runtime, the server asks the cloud for what changed since the server last asked, and receives only those parts.
4. The server builds a new runtime from the changed parts and the unchanged pieces of the old runtime, then swaps the new runtime in. The agent runs against it.

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 runtime. Only the changed pieces are rebuilt. A new allowlist is resolved when the allowlist changes. Connection pools are reopened when the pools change, database engines when a database profile changes, and LLM connections when an LLM profile or the allowlist changes.

Running agents are not disturbed

An agent keeps the runtime it started with, for its whole run. When a runtime is replaced, the connection pools and database engines of the old runtime stay open until the last agent using them finishes, and are closed then. A configuration change can therefore never break an agent in the middle of a call.

Where the parts are configured

Versions and concurrency

Every part carries a version. If someone else changed a part after you opened the part, your save is refused, so two people cannot silently overwrite each other. Saving a part with no changes is refused too. Every create, update and delete produces a notification that names the part and lists the fields that changed.