OTLP in, MCP out: LoopOps turns production telemetry into bounded windows and cited records your agent can diagnose, fix, and verify. The agent proposes; you approve every external write.
Paste it into your coding agent — it provisions keys, wires telemetry, and hands you your console link. About five minutes; no email to send telemetry.
OTLP in from anything you run. MCP out to the coding agent you already use. LoopOps holds the loop state in between.
A coding agent turns a diagnosis into a patch in minutes. But it sees only what you paste in, remembers nothing between sessions, and never checks whether the fix held.
Your agent fixes what you remembered to paste in, not what production actually does.
LoopOps — serves bounded telemetry windows: real evidence, cited records, never the whole lake.
Every session starts from zero — it will confidently re-diagnose last week's problem.
LoopOps — holds loop history across sessions and agents: claims, cluster status, verification.
Nothing checks the patch against reality, so a merged PR quietly counts as a win.
LoopOps — verifies against the next telemetry window — and refuses a verdict on no data.
Any MCP-capable agent — Claude Code, Codex, Cursor — drives the loop end to end and stops at your approval gate. Step through one cycle:
Your agent asks for recent evidence — a window, never the whole lake. The window is claimed, so the next session starts from what's new instead of re-reading handled pain.
> loopops_observe { window: "60m" } window win_0142 claimed records 142 · failures 14 top shape tool_call_failed · timeout
Claims are loop state: two sessions — or two different agents — never re-diagnose the same window.
Failures group by shape and rank against loop history. Every candidate carries its evidence ids — records your agent can pull and read, not a summary it has to trust.
> loopops_diagnose candidate tool timeout 9 / 14 failures status new · needs_decision evidence tr_9f31, tr_a204, tr_b77c (+6 more) hypothesis 10s tool timeout sits below p95
Cluster status is computed against loop history: new, in_progress, verified, regression.
The agent admits cited Issues and recommends a next move. The developer — not the agent — decides; the attributed receipt is separate and never grants external-write approval.
> loopops_decide { recommended_next: "patch" } issue iss_7f3a… needs you > loopops_issue_decide { decision: "patch" } selected tool timeout → ready for handoff
Opaque Issue identity stays stable; only the decision receipt moves its disposition.
Your agent uses its normal repo and testing tools to write the patch and prove it. LoopOps only records progress; issues, PRs, and deployment stay in your existing workflow, behind human approval.
> agent workflow { run: "rn_0311" } patch raise tool timeout 10s → 20s tests 9 captured failures pass > loopops_improve { stage: "diagnosed" } progress recorded ⏸ approval_required: true — before external writes
the only button in the loop an agent can't press
After the fix ships, verify re-reads the same lens on fresh telemetry and compares. Missing data returns no_data — never a pass. A merged PR is not a closed loop; a moved metric is.
> loopops_verify { run: "rn_0311" } before 9 / 14 failures after 1 / 12 (next window) verdict improved · cluster verified
A tracked cluster can't quietly regress — cluster history flags it on the next observe, across sessions and agents.
The coding agents building this product emit into a LoopOps project, and the loop closes on its own telemetry. Its real aggregate numbers publish at /proof — counts only, read live.
When the self-loop isn't publishing, this section stays empty — no numbers beats fake numbers.
See the proof →Production emits over OTLP on one side; your coding harness operates over MCP on the other. In between, LoopOps holds the state neither end can: claimed windows, cluster history, verification — and the approval gate before any external write.
The agent reads, diagnoses, and verifies — it can never post, merge, or deploy. Every external write waits at a human approval gate you control.
Ingest is telemetry your services already emit. The agent reads claimed, scoped windows of it; verification is a read-only window comparison.
Verify returns no_data before it returns a lie. A merged PR is never a closed loop — a metric that actually moved is, and every improvement is auditable.
No project key is ever pasted into an agent — connecting is a one-time email sign-in, and every fix lands in your own repo, under your own review. Details on /security.
Every onboarding starts by installing LoopOps into the coding harness. Claude Code and Codex get the native marketplace plugin; every other supported agent gets the shared skill plus mcp.loopops.dev. First connect opens a one-time email sign-in; no project key is pasted into the agent.
$ codex plugin marketplace add codeyogi911/loopkit-plugin --ref main $ codex plugin add loopkit@loopkit
The plugin bundles the loop skill and hosted MCP. Complete codex mcp login loopops, then start a new thread.
claude plugin marketplace add codeyogi911/loopkit-plugin claude plugin install loopkit@loopkit --scope user
One plugin bundles the hosted MCP server and loop skill. Reload plugins or restart Claude Code after a new install.
$ npx -y skills add codeyogi911/loopkit-plugin --skill loopkit --yes --globalThe shared skill and https://mcp.loopops.dev are both required. Register the hosted server in the client's native MCP config, complete OAuth, then restart when its loader requires it. The one-line onboarding prompt supplies the exact config shape for each supported client.
The order matters: install LoopOps into the coding harness first, then let that equipped agent provision the project, wire POST /v1/traces, prove the first signal, and read it back over MCP. Paste the one-line prompt from the top of this page and the agent runs that sequence itself. Already emitting OpenTelemetry? Point your existing traces at /v1/traces: no new SDK, no lock-in. Vercel AI SDK agents wire it in one line; full flow in the quickstart. Already running an agent headless with a signup key? Sign in once and claim that project to read it here.
Claude Code can fix anything you show it — but it sees only what you paste in, and it starts every session with no memory of what was fixed last time or whether it held. LoopOps is that missing state: bounded production evidence on the way in, and loop history — claims, cluster status, verification — that persists across sessions and across agents.
Sentry captures errors and renders them for a human to read; the triage, the ticket, and the verification are still your job. LoopOps assumes the fixer is an agent: it serves bounded evidence as tool calls, tracks each cluster through the loop from new to verified to regression, and gates the resulting issue or PR on your approval.
MCP is the port, not the product — the product is the state machine behind the tools: claim-based telemetry windows, cluster status against loop history, verification that refuses no-data, a human gate before external writes. Strip the MCP layer and all of that still exists; strip the state machine and then you'd have a wrapper.
Reading isn't looping. A raw MCP read has no claim semantics — next session the agent re-reads the same issues, can't tell handled pain from new pain, and nothing checks the fix against the next window. Read access without memory produces an agent that confidently re-diagnoses last week's problem.
It doesn't — constitutionally, not configurably. Ingest is telemetry your services already emit; the agent reads bounded telemetry windows, not your database; verification is a read-only window comparison; every external write stops at a human approval gate.
LoopOps is in alpha. First accepted signal in under a minute — no email to send telemetry.