Can the agent just call the API and retry?

For a read, yes. For a write, no. Without an idempotency key and a compensation path, a retry is a second invoice.

Do we need a workflow engine?

If the process spans systems and takes longer than a request, yes. If it is one call inside a transaction, a queue and a good error path are enough. We will say which.

Should long jobs move into MuleSoft?

Not automatically. Long-running orchestration that already works can stay where it runs until a cutover is earned. Fronting it is not the same as owning it.

Does human review defeat the point?

No. Review on the exceptions is what lets the confident path post automatically. Review on everything is a different problem, and we will tell you that too.

Architecture

A timeout should not become a double posting.

The first week is in the org, reading what already exists. Reads are cheap to get wrong. A write moves money, changes a record of care, or signs something. That belongs behind a queue, an idempotency key, and a path a person can reverse. The honest no: if the work is a software factory with a named delivery date, we are the wrong partner.

Send the brief

What it is

Where long work and real writes live.

The durable plane is the deterministic backbone under a non-deterministic runtime. It holds state when the model, the API, or the network fails halfway.

01Queues and bufferingAnypoint MQ or a cloud queue between the caller and the writer, with a dead-letter lane someone actually watches.

02Workflow stateDurable workflow engines such as Temporal for multi-step pipelines: retries with backoff, compensation, and a history you can replay.

03Document intakeIDP classifies, extracts, and validates before anything is written, with a reviewer on the exceptions rather than on everything.

04Compute for the long tailContainers and managed services on AWS or Google Cloud, including scale-to-zero hosts, for extraction, embedding, and batch work that has no business inside an agent loop.

05Platform eventsChange data capture and platform events so work leaves the org without blocking the person who clicked save.

Why it matters

The four incidents we get called about.

None of them are model failures. All of them are write failures, and all of them land on your operations team rather than the vendor.

In an org

A claims or invoice desk.

The document arrives, the fields are extracted, and the write is the part that has to hold.

01
Buffer the arrival
A spike in documents becomes a queue depth, not a failed batch and an apology.
02
Extract, then validate
Totals, allowed items, and required parties are checked before the record is touched. Confidence decides who signs.
03
Write once
An idempotency key per document, so a retry cannot post twice. This is the whole plane in one sentence.
04
Retry, then compensate
Backoff on transient failures, a compensation step on partial success, and a dead-letter lane with an owner.
05
Leave evidence
The trail ties the record back to the document, the policy, and the person who approved the exception.

Document to record, durably. Intake buffers the arrival, extraction and validation happen before any write, exceptions route to a reviewer, and the posting step is idempotent with a compensation path.

Mermaid source

flowchart TD
  A["Document arrives: email, portal, scan"] --> Q["Queue: buffer and backpressure"]
  Q --> E["IDP: classify, extract, validate"]
  E -->|"confident"| W["Idempotent write to ERP or Salesforce"]
  E -->|"exception"| H["Reviewer queue: a person signs"]
  H --> W
  W -->|"failure"| R["Retry with backoff, then compensate"]
  W --> T["Trace: which identity, which policy, which document"]

How Mindcat helps

Where we would start in your org.

Pick the write that scares you most. Make that one boring first.

Questions

What we actually say.

Can the agent just call the API and retry?: For a read, yes. For a write, no. Without an idempotency key and a compensation path, a retry is a second invoice.
Do we need a workflow engine?: If the process spans systems and takes longer than a request, yes. If it is one call inside a transaction, a queue and a good error path are enough. We will say which.
Should long jobs move into MuleSoft?: Not automatically. Long-running orchestration that already works can stay where it runs until a cutover is earned. Fronting it is not the same as owning it.
Does human review defeat the point?: No. Review on the exceptions is what lets the confident path post automatically. Review on everything is a different problem, and we will tell you that too.

What to read next.

The brief

Name the write you would not let an agent make.

We will tell you what has to exist before that changes.

A timeout should not become a double posting.

flowchart TD A["Document arrives: email, portal, scan"] --> Q["Queue: buffer and backpressure"] Q --> E["IDP: classify, extract, validate"] E -->|"confident"| W["Idempotent write to ERP or Salesforce"] E -->|"exception"| H["Reviewer queue: a person signs"] H --> W W -->|"failure"| R["Retry with backoff, then compensate"] W --> T["Trace: which identity, which policy, which document"]