How agents act on ERPs

How Riff connects to your ERP and what "taking action" actually means at a technical level.

The most common question from IT and procurement leadership before a Riff pilot: "What exactly does the agent do in our ERP?"

This page answers that directly.

How Riff connects

Riff connects to your ERP through native integrations. Supported out of the box:

• Infor LN / M3 — procurement, inventory, financials

• SAP S/4HANA — procurement, AP, supplier management

• Oracle ERP Cloud — procurement, financials, supply chain

• Microsoft Dynamics 365 — procurement, finance, operations

Each integration is configured once in your Riff workspace — credentials stored in Riff's encrypted secrets manager, never in code. Once connected, agents in your workspace can use that integration as a tool.

Custom ERP connections and middleware (REST APIs, message queues, SFTP) are configured the same way — builders define the connection, agents use it.

Two kinds of operations: read and write

Agents can do two things with your ERP:

Read — query data to inform a decision. Check open POs, read invoice status, look up supplier records, pull delivery schedules. Read operations carry no risk of changing data.

Write — take action: create a record, update a field, approve a line, send a communication. Write operations change your ERP.

Write access is the part that matters most from a governance perspective. Riff's approach to this is the typed actions model.

Typed actions: pre-declared, permissioned, logged

Every action an agent can take against your ERP is typed — pre-declared at build time, before the agent ever runs.

What this means in practice:

1. The builder defines the action. When building the agent, you specify exactly what write operations it's allowed to perform: "create a PO confirmation record in Infor LN", "update invoice status to 'matched' in SAP", "send a chase email from the agent's inbox." These are explicit, named operations — not open-ended instructions for the AI to figure out.

2. Each action is reviewed before deployment. You can inspect every action the agent is configured to take before it goes live. There are no hidden capabilities.

3. Every execution is logged. Each time the agent takes an action, it writes to the audit trail: what it did, what data it read, what it changed, when, and which agent ran it. The log is immutable.

4. The agent only does what it's typed to do. If a situation arises that doesn't match one of the agent's pre-declared actions, it doesn't improvise — it escalates to a human.

What this is not

Riff agents are not "AI generating API calls on the fly." They don't write SQL or construct ERP requests dynamically at runtime based on a prompt.

The operations are defined, reviewed, and approved by the builder before deployment. The AI reasoning happens around when to trigger those operations and what data to pass to them — not what operations to perform.

This distinction is what makes Riff auditable and appropriate for ERP write access. The set of things an agent can do is bounded and knowable before it runs.

Escalation when the agent can't decide

If the agent encounters a situation that doesn't fit its configured decision logic — an ambiguous supplier reply, a quantity discrepancy outside tolerance, a missing PO reference — it escalates rather than guessing.

Escalations appear in:

• The agent's Task Board in your Riff workspace

• The buyer's email or Slack (configurable)

• Any downstream system you've wired an escalation action to

The escalation includes the full context: what the agent was doing, what it read, and why it stopped. The human picks up from there.

See Reversibility and audit trail for how the audit log and undo paths work.