Your agent already fixes bugs. It cannot fix the ones nobody found.

The loop, in five beats

You are in the first one. Nothing after it needs you.

1. 1

   You ship

   That is the only step with a person in it. Comparison is anchored to releases rather than to the clock, so nothing is judged until there is a before and an after.

2. 2

   The shape moves, and a finding writes itself

   One query per render became fourteen. Statistics find the candidates, the model decides which deserve interrupting somebody for, and fourteen drifts that are really one missing index arrive as one finding rather than fourteen.

3. 3

   Your agent asks what happened

   Over MCP, from the editor already open on the repository. No dashboard to visit, no copy-and-paste from a screenshot, no one to remember that the feed exists.

4. 4

   It gets more than the screen shows

   Deliberately. The feed compacts for a person who can fill in the rest from the code in the next window; an agent cannot, so it receives every captured frame rather than the likeliest one, the normalized SQL, and which child calls account for the change, per parent call.

5. 5

   It writes the fix, and says what it changed

   A closure without a description is refused. Which change, in which files, and why it addresses this measurement rather than merely coinciding with it — that is the one thing only the party closing it knows, and it is unrecoverable a month later.

Then you ship the fix, and the fifth beat becomes the first one again. That is the whole shape of it.

What it can actually do

Five tools. Everything in both plans — gating the agent would be gating the product.

list_findings

What is open, ranked, with ids.

get_finding

One finding in full: frames, SQL, the child breakdown, and the other findings sharing its root cause.

close_finding

Resolve, dismiss or reopen — a reason is required.

check_service

Is anything arriving, and if not, why not.

install_sixty

The install instructions for this kind of project.

claude mcp add sixty \
  -e SIXTY_API_KEY=sixty_sk_… \
  -e SIXTY_ENDPOINT=https://ingest.sixty.sh \
  -- npx -y @sixty-sh/mcp

Cursor, VS Code, Codex and anything else that speaks MCP take the same two values as a config block.

We assume it will say it is finished

An agent that closes its own tickets is the part of this a careful reader stops at. They are right to. Here is what the code does about it.

• Closing is a claim, not a verification. The strongest incentive any agent has is to finish, and a finding closed against a fix that was never deployed has been removed from the list a person reads. So resolved means a release carrying the fix has reported and the numbers moved — and until one has, it stays open.
• A pattern that still reproduces is reopened. Whatever anybody claimed, the detector runs again on the next pass and puts it back.
• Every closure records who made it — user:[email protected] or agent:sixty_sk_abcd. You can always tell which of you decided it was done.
• The key it reads with cannot write telemetry, and the key in your production environment cannot read anything. A leaked reporting key means somebody can send fake latency numbers; a leaked reading key means somebody has your findings. They are not the same risk and they are not the same credential.
• Findings contain text nobody here wrote. An operation name comes from your app, and an agent with a shell is a different kind of reader than a browser. So the collector flattens everything that is structurally one line — names, files, releases, SQL — and the MCP server marks borrowed text, so a finding cannot impersonate the structure around it. It does not make prose harmless; it removes the half that is forgery rather than persuasion.