Agents ▸ Recommendations

A recommendation is one proposal from one agent run: a corrected sentence, a better meta description, a suggested internal link. This inbox is where they queue for review, and it is the screen your team will spend the most time on.

Filtering the queue

  • Status: All, Pending, Accepted, Applied, Auto-applied, Rejected, Expired, Superseded.
  • Target entity: narrow to one record.
  • Agent install: narrow to one agent.

Filter applies your selection and Reset clears it.

What the statuses mean

StatusMeaning
PendingWaiting for a decision.
AcceptedA person approved it.
AppliedThe change has been written to the record.
Auto-appliedApplied automatically after its veto window elapsed.
RejectedA person declined it, or vetoed it before auto-apply.
ExpiredIt was never actioned and is no longer offered.
SupersededA newer recommendation replaced it.

Reviewing one recommendation

Expanding a row shows what the agent actually proposes:

  • Field: the field it would change.
  • Current: the value now.
  • Proposed: the value the agent suggests.
  • Previous: shown after an apply, recording what was overwritten.

A confidence figure sits on each row. It is the agent's own assessment of how sure it is, and it is what the auto-apply confidence threshold tests against. It is a useful sorting signal, not a guarantee.

Two rows will look different from the rest:

"Advisory only — this recommendation proposes no field change to apply." The agent has something to tell you but nothing to write: a judgement, an observation, a flag for a human to act on elsewhere. Accepting it records your agreement; it does not change any content.

"This record was edited after the agent proposed the change. Accepting would overwrite that edit, so the recommendation can no longer be applied." Somebody changed the record after the agent read it. Rather than silently overwriting that person's work, the recommendation is blocked. Re-run the agent against the current version if you still want its opinion.

Acting in bulk

Tick rows to select them, then use Accept selected or Reject selected. The bar shows how many are selected.

Bulk-accepting is efficient on agents you have come to trust and risky on ones you have not. Read a sample before clearing a large queue in one action.

Undoing an apply

Undo last apply reverts the most recently applied recommendation, restoring the target field to its previous value.

It undoes one recommendation, the latest, not a batch and not an arbitrary older one. If a bulk accept applied twenty changes you did not want, undo handles the last of them and the rest have to be corrected on the records themselves. This is the strongest argument for keeping veto windows generous and reviewing before bulk-accepting.

Auto-apply and the veto window

Installs in Auto-apply with veto window mode put their proposals in the inbox as Pending like any other. The difference is the deadline: a scheduled task runs every 15 minutes, finds proposals whose veto window has elapsed, and applies them. They then show as Auto-applied.

Two things stop a proposal from auto-applying:

  • Somebody rejects it inside the window.
  • Its confidence is below the install's threshold; those keep waiting for a person indefinitely.

If auto-applied changes are appearing faster than anyone is reading them, lengthen the veto window or move the install back to Accept to action.