Controlled execution
The agent runtime is the environment the agent server builds from the account's configuration and runs every agent in. It bounds every agent in time and cost, and it decides what an agent can reach and where its data may go. This page is the summary; each control has its own page.
The agent is fixed
An agent is a definition: written by a developer, validated by a real run before it is published, versioned, and unchanged while it runs. A person, a chat bot or an assistant chooses which agent runs. The definition decides what runs.
Two bounds on every agent: time and cost
Every agent carries two bounds of its own, and is published and run with both.
- Time. The number of seconds a run of the agent may take. A run past the bound ends with the result code
timedOut, and the message names the limit. - Cost. The LLM spend, in US dollars, that a run of the agent may reach. The agent server adds up the cost after each LLM call, from the prices in the LLM profile, and stops the run once the total passes the bound. The run ends with the result code
errorInAgent, and the person is told that the request reached the agent's cost limit. The stop cannot be caught: it ends the run even insideonError, a tool call or aparallelbranch. Every attempt that is paid for counts, retries included.
The bounds belong to the agent, not to the account. An agent that looks up one record can be held to a few seconds and a few cents, while an agent that researches a question is given more of both.
What a bound covers
A bound covers one run: from the request to the answer, or to the point where the agent pauses on an ask. The run that continues after the answer starts with the full bounds again.
Setting the bounds
A new draft starts with default bounds, and a draft made from a published agent starts with that agent's bounds. The bounds are saved with the draft, the validation run is held to them, and publishing carries them to the agent. A developer can also change the bounds of a published agent directly. That change applies from the next run, does not make a new version, and is recorded in the audit log.
The cost bound relies on the prices in the LLM profiles: a profile without prices adds nothing to the total. The reports show the duration and the LLM cost of each agent's runs, which is the evidence for choosing both bounds.
What an expression can reach
The Python expressions in a definition run with the account's allowlist in place of Python's builtins. A function, class or module is available only when the allowlist names it, and a module comes without the modules it imports. Besides the allowlist, an expression sees the variables of its own function, the agent's variables and constants, the conversation's variables, and the sys, command, result and exc names. See Python expressions.
Search2o Cloud checks every expression when the agent is validated and refuses the constructs that lead out of the agent's data: import, names and attributes that start with an underscore, lambda, the walrus operator, calling the result of an expression, and the others listed under Compile rules. Each Python operator is allowed, denied or rewritten to a function of the account's own.
What an agent cannot see
Credentials stay out of the definition. A secret is read as sys.secret['NAME'], with the name written out, and the agent server resolves it at run time. The definition shows which secrets an agent uses, never their values. See Secret vault.
An agent's variables belong to that agent. The one channel between agents is the conversation: a conv variable set by one agent can be read by the next agent in the same conversation, by design. See Variables.
Where an agent's calls can go
APIs, databases, MCP servers and LLMs are reached through profiles, which administrators define and share across the account. An api command calls an API profile, so the hosts an agent can reach are the ones set in the profiles. Every HTTP call goes through a connection pool that administrators size.
The limits every agent shares
Besides its own two bounds, an agent runs under the account's runtime limits, the same for every agent: how many times a loop may iterate, how many rows a database call may return, and how long a definition may be. A loop past its limit fails the run.
The runtime bounds what an expression may do, not how much work one line of Python does. An expression runs on the agent server alongside every other run, so a very long computation delays the other runs. Two controls cover this:
- Operator rewriting. The account can map an operator to a function of its own, so that
a ** bruns asbounded_pow(a, b)and a very large power is refused before it is computed. See Compile rules. - Isolating the agent server. The agent server is a stateless process, so it can run inside whatever isolation your organization uses: a container with processor and memory limits, a separate host, a restricted operating-system user. See Agent servers.
The same runtime on every agent server
Every agent server builds its runtime from the same configuration, so an agent behaves the same wherever it runs. A change to the configuration, the profiles or the allowlist reaches every agent server and is live on the next run. An agent that is already running keeps the runtime it started with until it finishes. See Agent runtime.
What leaves the agent server
Search2o Cloud receives the search request and the conversation state, and the state is encrypted before it leaves the agent server. An account that sets the conversation state hooks keeps the state in your organization instead. API, database, MCP and LLM traffic goes where the profiles point. Everything else an agent handles, such as API responses, database rows, credentials and variables, stays on the agent server for the life of the run. See Data privacy.
When something fails
An expression that raises an error stops its command, and the message names the command's path and the Python error. An onError block on the command or the function can handle the error instead. Every run, with its result, its duration and its LLM cost, is recorded in the reports.

