Tares agents

A Tares agent is a prompt attached to a trigger. When the trigger fires, the agent is handed the correlated timeline for the affected entity, reads it (and can read a wider window or another entity), and writes its conclusion back into Tares as a finding on that entity’s timeline.

It’s a real agent (it reasons with an LLM), configured inside Tares. That distinguishes it from a connected agent, an external agent you wire up over MCP or a webhook, which lives in your own infrastructure. Both kinds are woken by the same trigger; what a Tares agent may do is deliberately narrower (the boundary).

Because a finding is also stored as an event on the entity’s timeline, the next agent to read that entity (including your own connected agent) receives prior Tares conclusions as part of the evidence. Tares doesn’t replace your agent; it gives it a head start.

Create one

In the console, open a project’s Advanced setup and click + next to Agents, or open a trigger there and choose Add a Tares agent. A guided setup plans agents too. You supply the prompt, optionally seeded from a preset, and may pin a provider and a model (see Model providers); everything else is fixed (see runtime and guardrails).

An agent belongs to the instance, and any number of projects can use it. Each project wires it its own way: which trigger wakes it there, whether it is on there, and whom it hands off to. A run belongs to the project whose wiring started it, so an agent’s page inside a project shows that project’s wiring and that project’s runs. The agent may use any MCP server and hand off to any agent on the instance.

A Tares agent is on in a project when a trigger of that project wakes it. New agents start off; enable it to run on the next firing. It is listed under Agents on each project that uses it, on its trigger’s page, under All resources with the projects that use it, and under Firings wherever it was woken.

No trigger of its own

The trigger field has a first choice, No trigger: only a handoff starts it. Such an agent never wakes on its own; it runs only when another agent hands off to it. Its page says “Only a handoff from triage starts it” with an on handoff badge, and has no Enable button (enabling one is refused with 409). You can pick a trigger, change it, or clear it again at any time under Edit. Deleting a trigger leaves the agents it woke in place, without a trigger of their own.

In the catalog

An agent is a catalog object, so it exports/imports with everything else and can be shipped in a seed catalog:

Optional fields: trigger (leave it out for an agent only a handoff starts), provider (a provider id from Settings; omit for the instance default) and model (a model id that provider serves; omit for its default), slack_channel (a channel ID the workspace bot posts to), webhook_url / webhook_token (the write-back webhook; the token, like slack_webhook, exports only with secrets included), mcp_servers (names from the MCP servers registry this agent may use), and handoffs (the agents that take over after a finding, see Hand off to another agent), and concludes and verdicts (see How a run ends). The registry itself is a catalog object too: a top-level mcp_servers: list of {name, url, auth_header, auth_value}, with auth_value secret-gated on export.


agents:
  - name: incident-first-look
    project: Default             # optional; the project that made it
    trigger: incident            # the trigger that wakes it
    enabled: true                # on in its project
    prompt: |
      You are an SRE taking the first look when an alert fires on this service. You are handed the
      correlated timeline: the firing alert plus the signals behind it and the request logs.
      Produce a tight incident note: what is failing and since when, the most likely cause tied to
      specific evidence lines, and a suggested next action. Do not speculate beyond the evidence.

The bundled demo ships exactly this agent, so tares up closes the loop with nothing to deploy.

Watch it run

Fire the agent’s trigger (in the demo: inject a fault) and follow it:

The conclusion shows on the project’s Overview under What the agents found, with its headline, summary and next step. For debugging, the firing is on the trigger’s page, under Firings, and in Advanced setup’s Activity, with the run it woke nested under it.
The run (status, rounds, duration, errors) is under the agent’s page → Runs. A run that concludes “inconclusive” or fails is recorded here and never pollutes a timeline. For an agent that concludes, an outcome column shows how each run ended: its verdict, no verdict, or no finding, with the headline beside it; an open run shows the same above its finding. The list can be filtered to successful or failed runs only, and Show more pages past the first fifty (GET /api/agents/builtin/{name}/runs?status=ok&offset=50).
The finding appears in Explore on the entity’s timeline, alongside the evidence it was drawn from.

A Tares agent's page: the prompt, the run, and the incident note it wrote back

The Build an AI SRE guide walks this exact loop end to end.

Findings

An agent’s conclusion is written to the built-in findings source (auto-provisioned on the first finding), keyed to the entity the trigger fired on. Because it’s treated as an event, it lands on that entity’s timeline and is returned by read like everything else. Each finding carries the agent, the trigger, the firing, and a hash of the prompt that produced it.

The model provider

A Tares agent runs on a model provider the instance holds: Anthropic, OpenAI, or an OpenAI-compatible endpoint. Provide one two ways:

ANTHROPIC_API_KEY (or OPENAI_API_KEY) in the daemon’s environment, or
the console → Settings → Model providers.

A provider saved in the console wins over the environment. Without one an agent can be created but not enabled; if it’s already enabled, each firing is logged as “no model provider” and no finding is written. The same providers power the in-app Ask assistant, which runs on the default.

Runtime and guardrails

Only the prompt is yours to configure per agent; the runtime is fixed so a data-plane feature doesn’t become an agent builder. The numbers:

Provider and model: pick a provider and a model it lists, or leave both on the default to follow the instance (TARES_AGENT_MODEL, claude-sonnet-4-6 unless set, on the default provider). Catalog YAML accepts any model id, so a model newer than the picker works without an upgrade.
Budget per run: max_rounds model rounds (1 to 24; set under Advanced on the agent form or as max_rounds in catalog YAML), 2,048 tokens per call. Unset, the default is 6, or 12 once the agent uses external MCP servers, since a run that reads a diff or a file and writes back needs more than the read-and-conclude budget. Every run records the cap it was held to and shows rounds/max. When the budget runs out mid-investigation the model gets one final call with tools disabled to conclude from what it has; if it still cannot, the run ends exhausted, keeps the last text as a partial note, and says to raise max rounds.
Cooldown: the agent runs at most once per the trigger’s cooldown per entity.
Daily cap: at most 50 runs per agent per day (TARES_AGENT_DAILY_CAP), so a trigger in a hot loop can’t run up an unbounded API bill.
Handoff chains: at most three handoffs in a row; see Hand off to another agent.
No self-feeding: an agent can’t be woken by a trigger that watches the findings source it writes to, unless the trigger is filtered to another agent’s findings (agent eq <name>); Tares rejects that wiring at definition time (it would fire itself forever).