Concepts

# Triage

How the inbox is worked, by an agent with a human.

Reports are only useful when somebody works through them. AgentFeedback ships that as a skill rather than a dashboard: `agentfeedback-triage`, invoked by you (`/agentfeedback-triage` in your harness), never by the agent on its own.

## What a triage session does

1. Reads the open reports ( `agentfeedback list --open`) and groups the ones that share a cause.
2. For each group, proposes what to do: fix the document, the tool or the configuration; record that it is invalid, a duplicate or deferred; or hand it upstream.
3. Does the fix with you, in the repository, using the tools your harness already has.
4. Marks the reports processed with a verdict, a resolution and a reference (a commit, an issue), so the next session starts from a clean inbox.

On an empty inbox, the session can start from past harness sessions instead (`agentfeedback sessions`), turning what already went wrong into reports and then into fixes.

## Processed is not resolved

A verdict of `invalid`, `duplicate` or `deferred` closes the report without claiming anything was fixed. Reports are never deleted by triage; the processed mark is the record. A report can be reopened (`agentfeedback undo`) if the fix did not hold.

## Several machines

A self-hosted server puts the reports of a team's machines in one inbox, and the same triage session works it. The cloud public beta is the hosted way to do that; see [Cloud setup](https://agentfeedback.dev/docs/quickstart/cloud).

[Reports What an agent files, and what it never files.](https://agentfeedback.dev/docs/concepts/reports) [Model and harness independence Any model can report through any harness; session capture has narrower support.](https://agentfeedback.dev/docs/concepts/model-and-harness-independence)

[Canonical HTML](https://agentfeedback.dev/docs/concepts/triage)