What an A/R agent taught us about trust boundaries

Accounts receivable is a useful place to make agentic AI concrete. The work reaches across records, correspondence, payment promises and business relationships. An overdue invoice is a signal that something needs attention; it does not tell you what should happen next.

The receivables transformation described on our homepage connects follow-up, recorded promises, payment plans and management information. The design question behind that work is broader than writing a better reminder: how does the process decide what to do, act within its authority and establish whether the account has moved forward?

Context comes before action

An overlooked invoice, a disputed charge and a promise to pay are different situations. AI can help interpret the correspondence and assemble the context. The current account records and agreed rules provide the other part of the picture.

Those sources have different roles. A customer’s email can explain a delay or propose a payment date. It cannot grant the agent a new permission, change the business’s policy or establish that money has arrived. The system has to preserve those distinctions.

AI can propose an action. The system enforces whether it is permitted.

Give the agent a business operation

A defined operation such as recording a promise is easier to control than broad access to edit account data. The service can check who is asking, which account they can access and whether the requested change fits the rules. It can record the source and handle a retry without creating a second promise.

The same principle applies when preparing follow-up or handling a payment plan. The permitted action, its required information and any approval conditions belong in the system around the model. Instructions to the model help it choose well; they are not a substitute for enforcing authority.

People handle the exceptions

Within defined policy, AI can triage the case and select a permitted next action. When the policy does not cover the situation, the case goes to a person with the context needed to make a decision. Actions that explicitly require approval also wait for that approval.

Within policy

The agent chooses and carries out an allowed step. The action and its result are recorded.

Outside authority

The system refuses the action. A new prompt cannot grant a missing permission.

An unresolved exception

The responsible person makes the call. Their decision becomes part of the case record and evidence for improving the policy.

Close the loop on the result

Sending a reminder completes a task; it does not resolve the debt. A promise needs a later check. A dispute needs an owner and a resolution. A confirmed payment changes what the process should do next.

That result feeds back into AI triage and judgement. With the account context updated, the next decision can be different: cancel the scheduled reminder, check a missed commitment or keep an unresolved case visible. Recorded human decisions also show where the policy needs to become clearer.

Improvement becomes part of the operating process: gather outcomes, identify what should change, and test the change against real cases. The goal is a capability that can do more useful work while keeping its authority and responsibilities understandable.