Reversibility and audit trail

How Riff ensures every agent action can be undone, every edge case reaches a human, and every step is logged.

The question IT and compliance teams ask most often about AI in the ERP: "What happens when it makes a mistake?"

The honest answer is: agents will encounter situations they're not sure about. Riff is built so that when that happens, a human is always in the loop before anything irreversible occurs — and so that anything that did happen can be traced and undone.

Every action has an undo path

Before an agent action can be deployed, it must have a defined reversal. If the agent creates a PO confirmation record, there must be a corresponding delete or update operation. If it updates an invoice status, there must be a way to revert it.

This isn't just a safety feature — it's an architectural requirement. The builder defines both the action and its reversal at build time. Riff stores both in the agent's configuration.

If you need to undo something the agent did — a mis-matched invoice, an incorrect confirmation — you can trigger the reversal from the audit log. No support ticket, no manual ERP edit. The reversal is part of the same audit trail.

Escalation before action

Riff agents are designed to escalate before acting in uncertain situations — not after they've already made a mistake.

Every agent is configured with decision thresholds:

  • Auto-act: the agent takes the action without asking. Used for cases where the outcome is unambiguous — a supplier reply that exactly matches the expected format, an invoice that matches the PO within tolerance.

  • Escalate: the agent routes to a human before acting. Used for anything outside the defined range — ambiguous replies, amounts over a threshold, missing reference numbers.

You set these thresholds when you build the agent. They're explicit and reviewable before deployment.

Escalations are delivered where your team already works — email, Slack, or the Task Board in your Riff workspace. Each escalation includes the full context: what the agent was processing, what it read, and exactly why it stopped. The human picks up from there with everything they need.

Plan Mode: review before running

For agents where you want extra oversight — new agents, high-value transactions, first-run validation — Riff's Plan Mode shows you what the agent intends to do before it does it.

In Plan Mode, the agent builds an execution plan and presents it for approval. You review the proposed actions, approve or adjust, and only then does the agent execute. Once you're confident the agent behaves correctly, you switch it to direct execution and it runs autonomously.

The audit trail

Every action an agent takes is written to an immutable audit log:

Field
What it records

Timestamp

When the action ran

Agent

Which agent, which version

Action

What was done (typed action name)

Input

What data the agent read to make the decision

Output

What the agent changed — before and after values

Outcome

Completed, escalated, or reversed

User

If a human approved or reversed, who and when

The audit log is accessible from the workspace and exportable. For compliance purposes — SOX controls, GDPR audit requirements, internal procurement governance — the log provides a complete chain of custody for every agent-driven transaction.

How this maps to governance requirements

For procurement and finance teams running agents against live ERPs, the audit trail and reversibility model is designed to satisfy:

  • Separation of duties: the builder who configures an agent can be different from the user who approves its deployment and the buyer who reviews its escalations. Roles and permissions are set at the workspace level.

  • Four-eyes for high-value actions: use escalation thresholds to require human approval above a defined transaction value.

  • Audit trail for external audit: the log provides timestamped, immutable evidence of every agent action for internal audit, external audit, or regulatory review.

  • Right to explanation: every agent decision is traceable to the data it read and the rule it applied. There are no opaque AI decisions in the transaction record.

Last updated

Was this helpful?