Search2o agents
A Search2o agent is an independent unit built for a single task. Agents do not call other agents. An agent is expected to run thousands of times, for different users, quickly and at low cost. It is to AI what a microservice is to an application.
A Search2o agent has clear boundaries: the systems it can reach, and its time and LLM cost budgets. It has every capability the agent runtime offers, but its workflow is built for that one task.
It also carries a plain-language description of the task and its boundaries. Search reads that description to find the agent for a request.
A Search2o agent keeps its state in the conversation, not on the agent server. It has state of its own, the agent scope, which only it reads, and it shares state with every agent in the conversation through the conversation scope. The agent server saves both when a run ends or pauses, so what one agent produces is there for the next one that runs in the same conversation. The state is per conversation: another conversation cannot see it, and a conversation belongs to one user, so another user cannot see it either. See Conversation state.
Examples
Search2o agents:
- Vacation request: takes the dates, checks the balance, files the request, reports the result.
- Invoice status: an invoice number in, where it stands in accounts payable out.
- Expense filing for a trip: pulls the trip's amounts, files the claim, asks before submitting.
- Meeting-room booking: a time and a head count in, a booked room out.
- Expense policy questions: answers from the policy documents and points to the form; it approves nothing.
- Contract renewal: drafts the renewal at agreed terms and sends it for signature after an approval.
Each is one verb, one or two systems, and a run measured in seconds.
These are not Search2o agents, though useful for other reasons:
- A general assistant, the chat box that takes any question about the company. Broad by intent, so there is no single boundary to validate against.
- An HR assistant that covers vacation, payroll, onboarding and benefits in one agent: a department's worth of tasks behind one description. In Search2o that is several agents, one per task, sharing a conversation.
- Month-end close, a process that runs for days with approvals from several people. Each step can be a Search2o agent; the whole is not one.
- An analysis workbench that writes and runs queries against the warehouse on request. The path is decided at run time, so neither the cost nor the reach is known in advance.
The line is the same in every case. A Search2o agent has a boundary you can write down, on systems, time and cost, and a small set of paths that can be validated. That boundary is also what makes a description precise enough for search to match.
How a Search2o agent runs
A request that matches the agent's description starts it; see How matching behaves. The agent runs for a short time, may ask the user for inputs or an approval on the way, and produces a response.
What the boundary buys
Validation. A Search2o agent has a few specific paths, like a workflow, rather than an open-ended set. That is what makes it possible to validate the agent before it is published: a real run against a validation query, with every step in the trace. See Trace and validation.
Dependability. The same request takes the same path through the same commands, so the agent behaves the same way on every run. A failure has a place: the command it failed at, in the run's record.
Safety. The agent reaches only the systems its profiles name, runs inside the agent runtime, and stops at its time and cost budgets.
Observability. Every run is recorded: who requested it, what ran, how long it took, what failed, and what the LLM calls cost. The reports show these per agent and per user.
How Search2o agents work together
Search2o agents do not call each other. They build on each other's work through the shared context of a conversation: the prompts and the conversation variables. Two agents share a prompt's history when both have a prompt of the same name with the conversation scope; see Prompts.
A shared prompt history does not depend on the model, so a second agent in the same conversation can use a different LLM and still continue the exchange. Conversation variables carry the context that is not in a prompt, such as the user's authorization.