The AI Agent Transaction Problem

At 10:14:07, the procurement agent created supplier V-20418.

At 10:14:09, ERP accepted the corresponding vendor. At 10:14:12, payment terms were activated. Four seconds later, the external bank-verification service rejected the beneficiary account because the account holder did not match the registered legal entity.

The workflow dashboard showed Failed. That status was technically correct and operationally useless.

The supplier existed. The ERP vendor existed. Payment terms existed. A vendor-created event had already been published and downstream systems had consumed it. The bank account had failed verification but the enterprise was no longer in the state it had been in before the workflow started.

Nothing about the word failed described the business reality. This is where agent architecture stops being mainly about tool use.

Once an agent can change state across independent systems, it is no longer simply selecting functions and interpreting responses. It is coordinating a distributed business transaction across systems that do not share a transaction manager, do not share rollback semantics and may not even agree on whether an operation succeeded.

We have become very good at discussing what tools an agent can call. The harder question is what happens after the fourth tool call fails and the first three have already changed the enterprise.