Skip to main content

​
The review queue

As agents work they accumulate two kinds of loose end that a machine shouldn’t close on its own. The first is a proposal: an agent learned something durable — “this column is the revenue metric”, “this API caps page size at 100” — and wants it written into Knowledge so the next thread doesn’t relearn it. The second is a failure it couldn’t fix in the moment: an eval regressed, a run died on a runtime error, an automation broke. Neither should silently become truth or silently disappear, so both queue into Review — one place where a human accepts what’s right, declines what isn’t, and decides what to chase. The queue used to be reachable only from the web app. It is now the same surface over MCP, the REST API, and the CLI, so a headless caller — a scheduled agent, a CI job, your own automation — can read what’s waiting and decide it without opening a browser. Every item is org-scoped and RBAC’d: you only ever see and decide your own organization’s queue, exactly as the app enforces it.

​
What lands in the queue

Items fall into two families, and the queue keeps the decision items above the failure signals so a proposal waiting on you is never buried under noise, whatever their relative priority. Decision items are the ones an agent is explicitly asking a human to rule on:
  • A knowledge patch — a new or edited Knowledge object the agent proposes. Because approving one changes what every agent and person in your workspace treats as true, it carries the whole proposed body: the target object, the new title and markdown, the problem it fixes, the evidence behind it, and the impact it expects. You read that before you apply it, and applying it is the same human-in-the-loop step as an approval on an action — the difference is that here the thing being approved is a fact, not a side effect.
  • An investigation — a request for an engineer to dig into a root cause and come back with a code fix or a concrete finding, carrying links to the run, thread, and eval that motivated it.
Failure signals are raised automatically when work breaks — a failed eval case, a failed top-level run, a failed automation, or answer feedback. These deduplicate: repeated failures of the same class count up on one item (its occurrence_count) rather than spawning a fresh row every time, so a persistently broken path reads as one loud item instead of a hundred quiet ones. A signal resolves when the underlying condition clears — an eval-failure item closes once the same case passes again — or ages out of the queue if it goes stale.

​
Deciding an item

A decision is one of four actions:
  • Apply — for a knowledge patch only: create or update the proposed Knowledge object, then close the item as resolved. The apply is atomic — two callers racing to apply the same patch can’t produce a duplicate object, and if the Knowledge write fails the item reopens so you can retry.
  • Resolve — close the item as handled without applying a patch (the right action for a failure signal you’ve dealt with elsewhere, or an investigation you’ve completed).
  • Reject — close the item as declined. A rejected patch is not written to Knowledge.
  • Snooze — hide the item until later. It takes an optional number of minutes and defaults to seven days, after which it returns to the open queue.
You can attach a note to any decision, which is recorded on the item as the resolution note.

​
Programmatic access

The queue is readable and answerable over MCP, REST, and the CLI. A review item has no slug, so it’s referenced by its id — you list the queue, read the one you care about, and decide it by that id, all within the one surface.

​
MCP tools

​
REST

Base URL https://api.erdo.ai. Authorization: Bearer <token> + X-Organization-ID. GET /v1/review-items takes optional status (default open; pass status= for all), type, limit, and offset query parameters. POST /v1/review-items/:id/decide takes action (apply, resolve, reject, or snooze), an optional minutes (for snooze), and an optional note.