Skip to Content
Tares

How can an AI SRE see which recent commits touch the service behind high latency?

Tares keeps a context repository current from your commits, so an agent investigating high latency starts from the current code of the service. A trigger on every commit to the chosen branch wakes an agent, which updates the context pages that cover the change. The first look run covers the last seven days of commits per source repository.

How it works

The Shared code context template in Tares creates one commits source per source repository, one timeline per repository, a trigger and an agent. The full walkthrough is in Keep shared code context current.

  • Sources. Each source follows one branch, the default branch unless you change it. Each polls every 60 seconds with the same GitHub token. Commits arrive as GitHub events, described on the GitHub connector page.
  • Trigger. It fires on every commit to the chosen branch, batched per repository, once per five minutes. A busy day becomes one run per repository per five minutes.
  • Agent. It reads each commit’s diff with github__get_commit, and specific files with github__get_file_contents when a diff is truncated. It decides whether the change alters an interface, configuration, a data schema, runtime behaviour or a dependency between repositories. Refactors, tests, formatting and version bumps that change no behaviour are skipped.
  • Context pages. For a change that matters, the agent reads the page that covers it, corrects statements the change made false, then adds what is new, with the commit’s short sha next to each claim. It opens a pull request in the context repository, or commits straight to the branch if you chose that.
  • Finding. Each run ends with a finding on the repository’s timeline: what changed and the pull request link, or “no update needed” and why.

When an agent investigates high latency, the context repository describes what each service does, its interfaces, its configuration and how the pieces depend on each other. It also carries the commit shas behind each claim, so the agent starts from the current code and can see which recent commits touched the service.

Set it up

  1. Run Tares and create an Anthropic API key under Settings > Model providers, or set it as ANTHROPIC_API_KEY. The agent is a real agent and needs a model.

    uv tool install tares      # or: brew install glassflow/tap/tares
tares up

  2. Create a GitHub fine-grained personal access token. Give it access to the source repositories and the context repository. Set Contents to read and write, Pull requests to read and write, and Metadata to read-only. With Pull requests at read-only the agent can push its branch but the pull request fails.

  3. Open Projects, pick Shared code context and click Set up. In step 1, pick or add the credential. Test shows the GitHub login it belongs to.

  4. In step 2, tick the repositories whose commits should feed the context, up to 50, or paste owner/name lines. Include the repository of the service behind high latency. Change the branch for a row if you do not follow the default branch.

  5. In step 3, pick the context repository, the branch pull requests target and the path where the pages live. A context repository cannot also be a source. Choose between keeping existing pages and updating them in place, or one page per source repository plus an index. Choose whether the agent opens a pull request or commits to the branch.

  6. In step 4, name the project, pick the model and the round budget, which is 12 by default. Leave First look on start on. It runs the agent once per source repository over the last seven days of commits.

  7. Click Start. Push a commit to a source repository. Within a minute the source ingests it, the trigger fires for that repository and the agent runs.

What you get

  • A context repository that the commits themselves keep current, instead of pages that go stale the week after they are written.
  • A starting point for the first investigation. The first look covers the last seven days of commits per source repository, so the pages are current before the next commit lands.
  • Pull requests for review by default, so a person decides what lands in the context pages.
  • Visibility into what the agent did. The project Overview shows each change under What the agents found, with the pull request or “no update needed”. Activity in Advanced setup lists every run with its status and result, and runs from Start are marked first look.
  • Controls you can use later. Edit adds or removes repositories, Pause turns off the trigger and agent while the sources keep ingesting, and you can edit the agent’s prompt on its own page.

This is the code side of the picture. For the wider setup, see AI SRE.

When something else fits

  • If you only need commits and pull requests as events for your own triggers, add a single GitHub source from the GitHub connector page. The GitHub App delivers pushes as they happen and covers every repository it is installed on.
  • If your context pages are already current and you want to save model spend, turn off First look on start. The agent then wakes only on new commits.

Still stuck? Get help

Last updated on
Quickstart