Your AP Workflow Shouldn't Live in Code
Think about a vending machine. The recipe is welded inside. It makes one sandwich, and it makes it well. If you want a different sandwich, you do not ask the machine. You commission a new machine from the factory.
Most AP platforms work this way, even the ones that now advertise AI. The workflow, meaning which statuses exist, which moves are allowed, and what it takes to approve or dispute something, is baked into the software. Changing it is an engineering project.
Where the workflow actually lives
On a traditional platform, you cannot point to your workflow. It is spread across thousands of lines of code throughout the application. The only complete description of how your process works is the code itself.
That creates a gap. A business user explains a rule to an analyst, the analyst explains it to an engineer, and the engineer turns it into code. Somewhere along the way, what you wanted and what the system does can drift apart, and nobody can easily check.
A kitchen instead of a machine
Direct Commerce works more like a professional kitchen. The kitchen, the equipment, and the food safety rules stay fixed. Every recipe is a card you can read, compare against earlier versions, and test before a paying customer ever sees it. The head chef signs off before anything is cooked.
In our system, every state, every allowed transition, and every buyer policy is stored as configuration. It is a defined object you can read, version, and change through a governed edit, with no new software release.
Say a buyer wants to cap supplier appeals at two, within 180 days. On the older approach, that means digging through code, shipping a release, and running a test cycle. Here, it is a named field in the workflow definition. An authorized person approves it, and the system enforces it from the next event onward. The whole change takes minutes.
Where AI fits
In this picture, AI is the apprentice. It reads every ticket, notices patterns, and drafts better recipe cards with evidence behind them. Then it hands them to the chef. It never cooks for a customer and it never changes a card on its own.
Here is a real example from capture. A reviewer corrects an extracted field, such as choosing the child supplier name printed beneath a parent company name. The platform compares what the reviewer changed against what it expected and writes a plain-English rule scoped to that supplier. The rule carries a rolling accuracy score. If its accuracy drops, it is retired automatically. If it keeps proving out, it can be promoted to apply more broadly.
Why this is safe
Two things matter most here, and both are about control.
First, rule changes are checked before they can take effect. Rules are written in a closed language that limits what a rule can look at and what it can do. A validation step confirms the rule makes sense for the document type. And every AI-proposed rule waits in a pending state until a person approves it.
Second, nothing hides. Policies are versioned, so you can see what a rule said a year ago and trace exactly which rule led to a specific outcome. Where money moves, the workflow engine does the math deterministically, and AI only helps write the rules that run inside it. Decisions are reproducible, and a replay produces the same result.
Why this is hard to retrofit
An AI that can safely improve a workflow needs a few things in place. It needs a transparent orchestration layer that returns clear errors it can learn from. It needs an event-driven system so it can react to new information as it arrives. And it needs a workflow that exists as a readable, testable definition rather than scattered logic.
For us, building this from the ground up turned out to be easier than reworking a batch-driven system into something that could do these things.
The simplest way I know to put it: our workflows are not buried in code. They are a living document that our platform enforces. AI proposes improvements, and you approve every change.
If you want to see how this works in practice, we would be glad to show you.