Step 3 of 7 Failed Across Three Systems. Which One Holds the Truth?

Start with the concession, because the platforms that connect these systems are genuinely good at what they do. Prebuilt connector breadth and API-led connectivity collapse months of point-to-point plumbing into reusable, governed APIs. Low-code recipes let a revenue-ops team automate a fulfillment flow without a platform team in the loop. And the newer agent control planes genuinely discover, secure, and govern which APIs and agents may be invoked — identity on the call, policy at the gateway, the whole API estate under one set of rulesets. That is real engineering and real value. None of it is the problem.

The problem is subtler, and it's structural. In every one of these architectures, the platform sits between your systems and choreographs calls between them. The order flow you drew on a whiteboard — capture payment, reserve inventory, schedule shipment — is not an object that exists anywhere. It is an implied sequence. Its state is smeared across the endpoints it touches: the payment status lives in the OMS, the reservation lives in the ERP, the shipment lives (or doesn't) in the carrier system. The connection is governed. The recipe is governed. The agent call is governed. The business transaction is governed by nobody — because it doesn't exist as a durable thing you can point at.

That's the sentence to sit with: when step 3 fails, there is no process to roll back — only three endpoints in disagreement.

Watch what the platforms actually offer you at the moment of failure. One well-known recovery model is restart from the last good point — replay the flow from the last checkpoint. Another is fall back to a backup agent — if the primary path errors, route to a secondary. Both are legitimate reliability features. Both are also forward-only continuation, and continuation is not the same as rollback.

Retrying step 3 does nothing about the payment captured in step 1 or the inventory reserved in step 2. If the retry finally succeeds, you may double-charge or double-reserve unless every downstream call happened to be idempotent — which, across a heterogeneous SaaS estate, is a property you hope for, not one the platform guarantees. If the retry keeps failing, you're left with a half-committed transaction and a manual reconciliation ticket. The platform did its job: it faithfully re-drove the flow. What it cannot do is undo the effects that already landed in systems it doesn't own — because it never owned the transaction in the first place, only the calls.

Compensation is the thing that's missing. A real business rollback isn't "run the flow again." It is: the shipment failed, so release the inventory reservation and void or refund the capture — in the right order, exactly once, with a record of each reversal. That is a semantic operation on a process. You cannot checkpoint your way to it.

Some enterprise-automation vendors go further and market transactional integrity across CRM, ERP, and HR. It's worth being precise about what that phrase can and cannot mean, because the words evoke database ACID guarantees the architecture cannot deliver.

True transactional integrity across systems requires a distributed commit protocol — two-phase commit — where every participant can prepare, hold a lock, and then commit or abort on a coordinator's command. Independent SaaS APIs do not expose that. There is no prepare phase on a payment API, no distributed lock you can hold across a carrier's REST endpoint, no coordinator the CRM will obey. You physically cannot two-phase-commit across systems you reach only through their public interfaces.

So what does the claim deliver in practice? Almost always eventual reconciliation: a background process that periodically detects drift between systems and repairs it — a sweep that notices the ERP and the OMS disagree and nudges them back into alignment minutes or hours later. That's genuinely useful, and for many flows it's enough. But it is not compensation, and it is not integrity. It is after-the-fact repair, with a window of inconsistency in the middle and no per-action business audit of what was reversed, when, by whose authority, and why. Calling that "transactional" sets an expectation the endpoints can't honor.

Entroid starts from the opposite end. Instead of choreographing calls between systems and hoping their states converge, it makes the process itself the first-class runtime object — with durable, governed state that lives on one runtime, not scattered across the endpoints. In the five-primitive fabric, a Deterministic Workflow carries that state and its governance inline; Connectors are the only primitive that touches an external system, so every external effect is a typed, audited edge of a process the runtime already knows about.

That single architectural choice is what turns compensation, idempotency, exactly-once, and replay from things you hand-wire per recipe into properties of the runtime. Walk the same failure again:

• Step 1 — capture payment through a Connector. The runtime records the effect and registers its compensating action (void / refund) against the process's durable state.
• Step 2 — reserve inventory through a Connector. Same discipline: the effect is logged, its inverse (release reservation) registered against the process.
• Step 3 — schedule shipment through a Connector. It fails.

Now the runtime does what a checkpoint can't. It runs the saga in reverse — release the reservation, then void the capture — each compensation executed through its Connector as a governed, reversible edge; each carried out exactly once because the runtime holds the idempotency keys and dedup state; each written into one immutable per-action audit. When the endpoint recovers, an operator can deterministically replay the process from step 2 against durable history rather than guessing which of three systems to trust. There is a truth now — because there is a process that holds it.

Here is the concession that keeps this credible: ES does not repeal distributed systems. It cannot two-phase-commit a payment API any more than anyone else can — no one holds a lock inside a system reached only through its public interface. It also does not remove integration; it runs over your existing estate through governed Connectors, and the ES Engineering Toolkits still do the real work of ingesting, transforming, and connecting.

What changes is where the guarantees live. The distributed pattern ES implements is the saga — local effects paired with compensations — which is the architecturally correct answer for a business transaction spanning independent endpoints. The difference is that the saga, its durable state, its idempotency, and its audit are owned by the runtime as structural properties, not reconstructed by hand in every recipe and swept up after the fact by a nightly reconciliation job. The connector stays the thin, audited edge. The business runs in the fabric.

That is the whole distinction, and it's worth stating plainly. An integration platform can tell you, with excellent fidelity, which calls it made. A process fabric can tell you what the business did, what it undid, and why — because the process, not the wiring between systems, was the thing it governed.