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.

Durable plane

A timeout should not become a double posting.

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.

Get the written assessment MuleSoft IDP

Founded 2022 · Founder in the Salesforce MVP Hall of Fame · Dubai HQ · Kochi studio

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.

Without it, with it

A write that might hold, or one that will.

Without this plane

With it

A timeout retries and posts twice: One write key, so a retry is safe
Long jobs die with the session: Long jobs run on a queue
A failed write vanishes: Failures land with an owner
No way to undo: A rollback named in the spec

The write that scares you

Three desks where the write went wrong.

Typical write failures. None of them is a model failure.

Example
Finance manager, Ajman steel trader
Today: The bank portal rejected a payment file overnight. Nobody knew until month end.
After: A failed write lands in a dead-letter lane with a named owner, instead of vanishing.
For CFOs
Example
Operations head, Dubai property developer
Today: Handover updates the CRM and the ERP but not the service desk. Someone reconciles by hand.
After: Each step runs from a queue with a compensation step, so a half-finished handover is finished or undone.
Real estate
Example
Claims supervisor, Riyadh health insurer
Today: Claim documents arrive in a rush after the weekend, and the batch fails.
After: Arrivals queue first, fields are checked before any write, and a reviewer signs only the exceptions.
MuleSoft IDP

Examples of the work, not case studies. Roles and cities are typical of the desks we see.

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.

The brief · one email

Name the write you would not let an agent make.

We will tell you what has to exist before that changes. The assessment is free: a short read of the org and a written note. If you go ahead, the first build week is a fixed AED/SAR 14,900 (about USD 4,050), credited in full when you sign the build within 60 days. The honest no: if the work is a software factory with a named delivery date, we are the wrong partner.