Task-specific agents
A task-specific agent specializes in a single task with clear boundaries: the systems it can reach, and its time and LLM cost budgets. It has every feature of an agent, but its workflow is built for that one task. In Search2o, a task-specific agent also carries a plain-language description of the task and its boundaries.
Examples
Task-specific 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.
Not task-specific, and 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. It is a sequence of tasks; each step can be a task-specific 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 between the two is the same in every case: a task-specific 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 task-specific agent runs
A user's request that matches the agent's description triggers the agent. The agent runs for a short time, may ask the user for inputs or an approval on the way, and produces a response. Search reads the descriptions, so the agent that runs is the one whose description fits the request; see How matching behaves.
What the restriction buys
Validation. A task-specific 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, and 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 controlled 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 task-specific agents work together
Task-specific agents do not talk to each other. They build on each other's work through the shared context of a conversation: the prompts and the conversation variables.
The prompts in the shared context are model-neutral, so a second agent in the same conversation, using a different LLM, continues with the same prompt history as its short-term memory. Conversation variables carry the context that is not in a prompt, such as the user's authorization.