Agents¶
Agents are goal-oriented, long-running harness workflows. Unlike a free-form chat, an agent is launched with a defined class and parameters, owns one or more conversations and sandboxes, and moves through an explicit state machine toward a deliverable (artifacts, reports, parsers, and so on).
Agents are the main path for full autonomy: they can run with little or no interactive chatting, while the harness still records an audit trail and can apply vetting to sensitive tools.
How agents relate to conversations¶
| Conversation | Agent | |
|---|---|---|
| Started by | User (or schedule / delegate) | User from New Agent, or automation |
| Drive | Open-ended chat turns | State machine with named stages |
| Success | User decides the thread is done | Agent reaches a final state and may publish artifacts |
| Sandbox | On demand when tools need it | Often created as part of agent setup |
An agent may open conversations internally when it needs LLM reasoning or tools. The agent record in the UI shows console output, linked conversations, sandboxes, and artifacts.
Agent classes¶
The product ships several agent classes (availability depends on version and configuration):
| Agent | Intent |
|---|---|
| Parser Builder | Autonomously generate and validate log parsers from sample logs |
| Detection Agent | Detection-oriented autonomous work |
| Triage Agent | Enrich and prioritize alerts with broader context |
| Hunting Agent | Structured threat-hunting runs |
| Response Agent | Response-oriented playbooks |
Each class has a parameter schema (and UI schema) so the operator fills in the required inputs before launch.
Lifecycle¶
- Operator chooses an agent class and fills parameters (model, inputs, …)
- Harness creates the agent record and starts it in the background
- The agent creates sandboxes / conversations as needed, runs tools and skills, and logs progress
- On success it stores artifacts (files produced in the sandbox or written by the agent)
- Sandboxes can be marked for termination; the agent record remains for review
Failures are stored on the agent (error + finished time) so operators can inspect what stopped the run.
When to use an agent vs a chat¶
- Use a conversation when you want to steer, explore, or answer ad-hoc questions
- Use an agent when the job is a known, bounded workflow that should finish to artifacts without babysitting every turn
- Combine both: start from chat, then hand bulk work to an agent; or launch an agent and only intervene when vetting pauses a tool call
In the UI¶
- New Agent — pick a class and configure parameters
- Agents — list running and finished agents, open detail (console, conversations, artifacts)