This page is generated from SCORING.md in the repository, the single source of truth.

Team Agent Harness Index: scoring checklist and disclosure

This is the public rubric. Anyone can recompute every score from data/tools.json. The score is deliberately boring: it counts what a team can verify from public documentation, nothing else.

Disclosure (read this first)

The person who runs this index, Antony Evans, builds a product in this category.

• He runs Mensara* (https://www.mensara.ai). Mensara is both a shared-memory, company-agent platform for teams and their AI agents and his multiplayer agent harness. It is one product with one listing; there is no separate harness listing.
• On the index pages Mensara is marked with an asterisk (*) next to its name, and every page carries this footnote: "* Built by the index owner. Scored by the same public checklist as every other tool." The same marking is used in the newsletter and RSS.
• Mensara is scored with the same checklist, the same weights and the same evidence rule as everyone else. The weights and rules are public in this file and are not tuned per tool; any change re-scores every tool at once.
• Mensara can never buy a featured slot, a "pick of the week" or a newsletter mention that is not labelled as his. Sponsors and featured listings can never change a score (see "Money" below).
• If you think the Mensara score is too generous, open an issue or email the corrections address (to be published) and we will re-check against the cited page and publish the change.

What a score means

A score out of 100 is a checklist of team-readiness that is documented in public. It is not a quality ranking and not a recommendation. A single-user terminal tool can be excellent and still score low, because the index is about teams. Tools that are not documented get no credit, and are flagged unknown rather than no.

Checklist item	Points	What earns it
Shared context	20	Several people (and their agents) work against the same sessions, projects, memory or workspace.
Per-user permissions and credentials	20	Each person has their own identity, role or scope, and credentials/secrets are scoped to people or projects rather than one shared key.
Approvals	15	A human (or a defined policy) can gate agent actions or agent-proposed changes before they take effect.
Audit log	15	A queryable record of who/what did what, beyond ephemeral console output.
Self-hosting	15	The software, including the team/server parts, can run on infrastructure you control.
Project health	15	Based on last default-branch commit and release signals (rules below).

For the first five items each tool gets one value:

• yes = full points. Documented, and covers the item for teams.
• partial = half points. Documented but conditional or incomplete (e.g. owner-only roles, escalation instead of approvals, vendor-hosted control plane, a roadmap item).
• no = 0. Used only when the docs say it is absent or the architecture rules it out.
• unknown = 0, shown as unknown. Nothing found in the pages checked. This is not a claim that the feature is missing, and every unknown is open to correction.

Each value carries a short note, the exact source URLs, and a gated tag: free, paid, enterprise or blank. A gated feature still earns points (it exists and is documented) but the tag is shown so nobody mistakes an Enterprise feature for a free one.

Evidence rules

1. Only verified facts are recorded. A value needs at least one URL we actually fetched on the verification date. Third-party comparison pages (for example tomrochette.com's matrix, loopengineering.app's guide) are used only to find candidates. Their claims are re-checked against the project's own site or repo, and where they disagree with the source, the source wins (example: a matrix said Vibe Kanban had no commits since 2026-04-24; the GitHub API shows commits through 2026-09-19).
2. Documentation, not hands-on testing. We score what the vendor documents. We do not claim to have tested behaviour. Vendor marketing claims are scored the same way as docs but are labelled "vendor claim" in the note when that is all there is.
3. Product tiers. Where a feature exists only in a paid or enterprise tier, it is recorded with the tier tag. Open-source core and commercial platform are scored as one entry only when the project itself presents them together (e.g. OpenHands, CrewAI AMP, LangSmith); the note says which part provides the feature.
4. Dates. Commit dates are UTC calendar dates from the GitHub API on the default branch. Branch pushes (pushed_at) are not used, because a tool can have branch noise while the default branch is idle.
5. Closed source tools have no commit date. Their health uses the latest dated public changelog entry; if none exists, health is unknown and earns 0.

Project health rules (status and points)

Computed mechanically from days since the last default-branch commit (or the latest public changelog entry for closed tools), measured at the snapshot date in tools.json.

Status	Rule	Health points
active	45 days or fewer, no sunset notice	15
slow	46 to 180 days, or an official sunset / maintenance-mode / transition notice caps an otherwise active project	8
orphaned	more than 180 days with no default-branch commit	0
shut down	official shutdown or deprecation notice for the product/extension, or archived repository	0
unknown	no public repo, changelog or release feed	0

Every tool lists the rule outcome in status_basis and any lifecycle event in lifecycle_note with sources (for example Roo Code's shutdown, Crystal's deprecation, Vibe Kanban's sunset, Gemini CLI's transition to Antigravity CLI).

Money (featured listings and sponsors)

• Featured listings and sponsorships buy placement and a labelled blurb, never a score, a status, a value or a removal of a negative lifecycle note.
• Sponsored and featured items are labelled as such wherever they appear.
• A sponsor can supply corrections with sources. Corrections are made the same way for everyone, and are logged.
• No tool pays to be listed. Listing is by relevance to the category and verifiability.

Corrections and changes

• Every change to a value is a commit in the public repository, with the source URL in the message.
• Maintainers of listed tools can send a correction with a URL; we re-verify and publish the result, including when it lowers a score.
• The weights above are versioned. A change to the weights or rules is announced in the newsletter and re-scores every tool at once, never one tool at a time.

Known limitations

• The score favours tools that document team features. Good tools with thin docs are under-scored, which is why coverage (how many of the five items were verifiable) is shown next to the score.
• "Yes" means documented, not that it is good, secure or complete. Treat it as a shortlist filter.
• Scores today are from one snapshot (see as_of in tools.json).