The Tares platform

Software Factory and AI SRE are built on this platform. You need these pages when you build always-on agents of your own on Tares, or want to see what sits under an edition. To use an edition, start from Software Factory or AI SRE.

Tares sits between the systems you already run and the agents you want working on them.

• Connect anything that emits events. Logs, metrics, alerts, deploys, commits, database rows, webhooks. A connector turns each one into events; nothing to change on the source side.
• One timeline per thing. Every event that concerns a service, a repo, a customer or a job is merged into one time-ordered timeline for it. An agent asks “what happened to checkout?” once and gets the whole picture, across all sources.
• Agents that run on what happens. Triggers watch the timelines. When a condition fires, Tares wakes an agent with the correlated timeline already in hand, over MCP or a webhook, or runs a Tares agent in-process.
• Findings that stay. What the agent concludes is written back onto the timeline as an event. The next reader, human or agent, starts from the last conclusion instead of from scratch.

Tares is MIT licensed, runs on your machine or your server, and stores everything in one local DuckDB file. No external database, no broker, no telemetry.

How it works

Four steps.

1. Sources bring events in. Poll connectors (Prometheus, GitHub, Postgres, Docker logs) fetch on an interval; push connectors (OTLP, Alertmanager, Vercel, webhooks) receive over HTTP. Each event keeps its original payload. Connectors
2. Labels join sources on a shared key. Events labeled service=api-server from logs, metrics, alerts and deploys read as one timeline for api-server. Concepts
3. Triggers watch a set of sources and fire on a condition: an alert lands, an error rate crosses a line, a commit touches a path. A cooldown keeps one incident from firing a hundred times. Triggers
4. Agents get woken. An external agent receives the timeline over a webhook or reads it over MCP; a Tares agent runs inside Tares on your prompt and writes its finding back. Tares agents, Connecting agents

A project holds the triggers and agents that do one job, the sources they read, and the skills its agents follow, and shows everything that happened on one page. Projects

Underneath, one daemon (taresd) serves the HTTP API and the console, and tares-mcp exposes the read and watch tools to any MCP client.

Two ways to build

The two combine: a Tares agent writes the first look, your coding agent picks it up from the timeline when you sit down.

Key capabilities

• Correlated reads. read(selector, window) returns any entity’s timeline across all sources, or only a project’s; create_trigger lets an agent set up its own watch.
• Triggers and delivery. Conditions over live data, cooldowns, delivery to webhooks, Slack channels and Tares agents, with every attempt logged and retried.
• Tares agents. Prompt plus trigger; runs on your model provider, read-only by default, with external MCP servers opt-in per agent. Each run is metered.
• Findings and memory. Conclusions become events on the timeline; remember writes observations back for the next read.
• Projects and skills. One page per job with its activity as threads; skills give a project’s agents shared instructions they load when a task matches.
• Console and Ask. Projects, Sources, Triggers, Tares agents, Firings, Explore, and Ask, an assistant over your own data (⌘K).
• Slack. Subscribe a channel to any trigger; ask back with /tares ask.

Choose your path