Use cases

A use case is a ready-made setup: you pick what you want Tares to do, answer a few questions, and click Start. Tares creates the sources, view, trigger, agent and, where needed, MCP server behind it. Every object it creates is an ordinary Tares object on its normal page (Sources, Triggers, Tares agents, MCP servers); the use case page is the combined view of them.

The Use cases entry sits at the top of the console sidebar because it is the quickest way from an empty instance to something running. The primitives stay below it for when you want to wire things by hand.

Available use cases

A use case marked demo needs the demo stack rather than your own systems; its setup page shows what to run first, with copy buttons, and detects what is already running.

Setting one up

Open Use cases, pick a card, click Set up. The setup page asks only for what it cannot work out itself: the AI SRE demo looks at Docker and fills in the Prometheus and api-server URLs from the running containers; the shared code context wizard lists the repositories your GitHub token can see. The last step shows exactly what Start creates, with the names of the objects. Some setup steps check themselves (an Anthropic key that is already set shows as done, and can be pasted right there when it is not).

The use case page

Each running use case has a page with:

• Cards for the counts that matter (sources or repos, runs, trigger last fired, created).
• How it works: the chain in four lines.
• Actions, when the use case has them (the AI SRE demo’s Cause an incident and Clear the fault).
• Runs: every run of the use case’s agent, newest first, with status, rounds and the result; each row opens that run on the agent’s page. Runs marked first look ran once when the use case started.
• Configuration: the settings you chose, the sources it created, what it created (each object linked to its own page with its state), and the change history (created, updated, paused, resumed, repaired).

Pause turns the trigger and agent off; sources keep ingesting so the timeline stays complete. Resume turns them back on. Edit reopens the setup with your values; on save the use case re-plans and applies only what changed. Delete removes the objects it created; events already stored stay unless you tick “also purge the events its sources ingested”.

Ownership

Objects a use case created carry a part of use case badge on their own pages and are fully ordinary there:

• Edit one by hand and it is marked customized; the use case keeps your version on its next re-plan instead of overwriting it.
• Delete one by hand and the use case page lists it as missing, with a Repair button that re-creates it from the plan (Repair also resets a customized object back to the plan).
• An object that already existed with the same name and belonged to no use case is adopted by the use case, not duplicated (this is how the AI SRE demo picks up a demo catalog you imported earlier).

In the catalog

A use case can be declared in catalog YAML, so a seed catalog can ship one and tares up creates it on first boot:

usecases:
  - recipe: ai_sre_demo
    name: AI SRE demo
    params:
      prometheus_url: http://localhost:9090
      api_server_url: http://localhost:8080
      container: tares-demo-api-server

Import creates the instance by name or updates an existing one; export includes the section with the parameters (never credential values).

The API

Everything the console does is on the management API:

Objects returned by /api/sources, /api/views, /api/triggers, /api/agents/builtin and /api/mcp-servers carry owned_by (the use case id) and customized.