Tares
An open-source platform that gives always-on AI agents a timeline to read and a record to write back to.
- Source repo
- glassflow/tares
- Stars
- ★ 44
- Last updated
- today
- License
- MIT
- Primary language
- Python
- FA score
- 43/100 · Major gaps
At a glance
- Works with
- Universal · cross-platformCodex · Claude Code · OpenAI API · Claude API
- You'll need
- Typical use
- An SRE team wants the agent to read a service's full history and write the diagnosis before anyone opens a dashboard when an alert fires.
- Main limitation
- The software factory depends on Claude Code (signed-in plan with background sessions) and
ghwith repo write access. - Source review
- 43/100 · Major gaps
What does this agent do, and when should you use it?
Tares is Glassflow's open-source platform for always-on AI agents, shipped as a single daemon plus one DuckDB file that runs on your machine or server with no external database, broker, or telemetry. It merges events from logs, metrics, alerts, deploys, commits, database rows, and webhooks into one time-ordered timeline per service, repo, customer, or job; triggers wake an agent when something matters, and the agent reads that correlated history over MCP or a webhook and writes its findings back. A second mode, the software factory, runs a crew of Claude Code sessions locally: an orchestrator hands out tickets, builders open pull requests, a reviewer holds changes to a fixed bar, and builders merge once CI is green. Claude Code, Cursor, Codex, and custom agents connect over MCP, while Tares's own agents can use any model provider. A managed Tares Cloud option provides a ready-running MCP endpoint.
tares up starts the daemon and console (default http://127.0.0.1:8787); tares mcp --transport streamable-http exposes an MCP endpoint at :8788/mcp. In the console, Sources → Add source connects Prometheus, OTLP, GitHub, Vercel, Postgres, webhooks, Claude Code sessions, and more, and events land on a per-object timeline. A trigger wakes an agent (over MCP, a webhook, or running a Tares agent in-process) the moment something happens; the agent asks once and receives the correlated history, then writes its conclusion back onto the timeline. In factory mode, tares factory crew up starts the crew, tares factory spec "..." plans a project in your repo with a spec, milestones with acceptance checks, and a working doc per ticket, and the orchestrator dispatches tickets so builders open PRs per milestone and repo, a reviewer checks them against a fixed bar, and builders merge once CI passes. tares factory crew attach orchestrator is how you answer the crew's questions.
- An SRE team wants the agent to read a service's full history and write the diagnosis before anyone opens a dashboard when an alert fires.
- A platform team wants an agent to open a pull request updating the shared context repository whenever a change matters.
- Teams tracking failure modes like failed jobs, sandbox runs, or voice calls need a timeline, a trigger, and a finding per object.
- An engineering org running several projects in parallel wants one crew of Claude Code sessions to take specs to merged PRs while keeping every review and decision on record.
- Developers already using Claude Code, Cursor, or Codex want one MCP call to retrieve cross-source history instead of ten tool calls.
How do you install or deploy this agent?
Install with uv or Homebrew:
uv tool install taresor:
brew install glassflow/tap/taresThe software factory additionally needs Claude Code signed in on a plan with background sessions, plus gh with write access to your repos.
How do you use this agent?
Start the daemon and console:
tares upIn a second terminal, start the MCP endpoint:
tares mcp --transport streamable-httpConnect Claude Code to it:
claude mcp add --transport http tares http://localhost:8788/mcpThen ask: *"Use tares: what happened to api-server in the last 15 minutes?"*. For the software factory:
tares factory crew up
tares factory spec "what you want to build"
tares factory crew attach orchestratorAdd event sources under Sources → Add source in the console.
What are this agent's strengths and limitations?
- One read returns correlated history across every source, cutting an agent's ten tool calls to one.
- Event-driven by design: triggers wake an agent over MCP, a webhook, or in-process execution.
- Findings, plans, tickets, reviews, and decisions persist on Tares and outlive the session for the next reader.
- Simple deployment boundary: MIT licensed, one daemon and one DuckDB file, no external database, broker, or telemetry.
- No agent lock-in: Claude Code, Cursor, Codex, and custom loops connect over MCP.
- The software factory depends on Claude Code (signed-in plan with background sessions) and
ghwith repo write access. - You must run the daemon and MCP endpoint yourself; the managed option is the paid Tares Cloud.
- Docs and console are English-first, so non-English teams bear the cost of translation.
- A young project whose connector breadth and long-term stability still lack track record.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Tares This agent | 43 · Major gaps | — | ★ 44 | today | Python | Codex · Claude Code · OpenAI API · Claude API |
| HolmesGPT SRE Agent | 57 · Major gaps | CLIFree + model costs | ★ 3.8k | 1d ago | Python | OpenAI API |
| Preloop | 84 · Good | — | ★ 88 | 1d ago | Python | Codex · Claude Code |
| KAOS — K8s Agent Orchestration System | 69 · Some gaps | CLIFree | ★ 282 | 6d ago | Python | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
SECURITY.md clearly states the daemon binds 127.0.0.1 with no auth by default and requires --auth/TLS plus scoped keys when exposed — a plus. However the repo grants agents repo write access, auto-merge of PRs, and staging DB restarts; least privilege rests only on autoMode rules and soft-deny, which is thin evidence, so least_privilege = 1. User confirmation: crew up asks settings one at a time, L3 requires a relayed yes, production needs a human, so 2; but auto-merge and always-on background agents' confirmation boundaries are not fully documented. Data-flow transparency: README claims no telemetry and a single DuckDB file, yet pyproject pulls in OpenTelemetry export and Rius/Langfuse tracing without in-repo flow detail, so 1. Sensitive data: SECURITY.md gives key/auth guidance but no retention, redaction, or log-hygiene handling is shown, so 1. Dependency security: common libraries plus a gitleaks CI scan, but no lockfile or dependency audit step, so 1. External effects: agents open PRs, merge, and restart services — high external effect gated only by soft-deny and CI, so 1. Rollback: crew halt/resume, retire/revive, restart exist, but no rollback for merged changes or executed external actions, so 1. Source attribution: MIT and author GlassFlow are clear, but the publisher is unverified and SECURITY.md's contact domain (glassflow.dev) differs from the project domain, weakening attribution, so 1.
CI enumerates many backend and factory bash tests covering crew, watch, lock races, and unreadable session lists, giving good self-consistency evidence, so 2. Dependency availability: common PyPI packages with version floors and sensible optional extras, so 2; no lockfile slightly weakens reproducibility. Failure messages: tests assert explicit messages (no Tares answers, could not read, another factory command) and docs give clear guidance, so 2.
Audience and scenarios: README cleanly separates AI SRE and software-factory use cases with quickstarts, so 2. Capability boundaries: docs note Claude Code plan and gh write access, but hard limits on agent autonomy (auto-merge, production actions) are under-described, so 1. Trigger precision: triggers and timelines are described conceptually, but no in-repo evidence of matching rules or dedup/suppression, so 1. Environment fit: local, Docker, server, and Cloud are supported, but dependence on Claude Code and gh narrows fit, so 1.
Information architecture: README is well structured with quickstart, scenarios, and a link table, so 2. Install notes: uv/brew install, tares up, and MCP registration commands are concrete, so 2. Naming stability: SECURITY.md uses navflow up/NAVFLOW_AUTH_TOKEN against the tares/TARES_* product, a naming drift, so 1. Examples and FAQ: example commands and scenarios exist but no FAQ, so 1. Known limitations: only scattered mentions (Claude Code plan, no-auth default), no consolidated section, so 1. License: full MIT text consistent with pyproject, so 2. Versioning/changelog: a version in pyproject but no CHANGELOG in repo, so 1. Maintenance responsibility: SECURITY.md contact and GitHub issues exist, but publisher is unverified and no governance/maintainer statement, so 1.
Output usability: README shows runnable commands and expected results, but actual outputs (PRs, diagnoses) cannot be statically verified, so 1. Marginal value: event timelines and multi-agent orchestration are differentiated, but the space is crowded and the value case leans on external docs, so 1. Cost-benefit: requires a resident daemon, a Claude Code plan, and gh permissions — high cost against largely asserted benefits, so 1.
Claim traceability: README claims link to external docs but lack in-repo implementation detail, so 1. Cross-source corroboration: CI test names broadly match README features (factory, crew, SRE), a partial corroboration, so 1. Fact/inference separation: README is largely marketing assertion without marking what is test-verified, so 1.
- SECURITY.md uses navflow/NAVFLOW_AUTH_TOKEN naming inconsistent with the tares/TARES_* product, risking auth misconfiguration on deploy.
- Default is no-auth bound to 127.0.0.1; exposing it without --auth/TLS leaves API, console, and ingest unprotected.
- Agents hold repo write access, auto-merge PRs, and restart services; least privilege rests on autoMode soft-deny and needs human review of granted scope.
- README claims no telemetry, yet dependencies include OpenTelemetry export and Rius/Langfuse tracing — verify actual data flows.
- No dependency lockfile or audit step, limiting supply-chain reproducibility.
- Publisher identity is unverified and SECURITY.md's contact domain differs from the project domain; treat attribution with caution.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
v1.56.0-rc.4 Pre-release
Release notes excerpt
What's Changed * TR-759 One file for the CI test list by @ashish-bagri in https://github.com/glassflow/tares/pull/312 * TR-724: the cell's edition, settled on first boot by @ashish-bagri in https://github.com/glassflow/tares/pull/316 * TR-727: builder mocks a screen first, reviewer checks the design by @ashish-bagri in https://github.com/glassflow/tares/pull/314 * TR-731: ready_to_close on project cards and the summary by @ashish-bagri in https://github.com/glassflow/tares/pull/317 …View on GitHub ↗ -
Release notes excerpt
What's Changed * CI: shard the tests, cancel superseded runs by @ashish-bagri in https://github.com/glassflow/tares/pull/369 * Tares 1.55.1: ship a long session's backlog in chunks (TR-809) by @ashish-bagri in https://github.com/glassflow/tares/pull/367 Full Changelog: https://github.com/glassflow/tares/compare/v1.55.0...v1.55.1View on GitHub ↗