Declare per step which writes may safely be repeated, retry only those, compensate where a compensating action is defined, and halt in a resumable state for a named operator.
A run starts, and every step in it is declared in advance as safe to repeat or not safe to repeat.
02
A step succeeds, and its result enters the run state before the next step is allowed to begin.
Reason
03
A step times out, and the missing answer is recorded as an absence, not as a failure.
04
A retry is considered, and it happens only where the step it would repeat was declared safe to repeat.
05
A step fails outright, and the compensating action defined for it is proposed rather than improvised.
Decide
06
A message arrives twice, or out of order, and the run state decides which one it keeps.
07
A compensating action fails, and the run stops half-undone with both halves written down.
Out
08
A run cannot go on, and it halts at a checkpoint a named operator is able to resume it from.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Sequencing, state and declared retries belong to the agent. A half-finished run belongs to a named operator, who decides whether it is resumed, compensated or abandoned.
Example workflow
One run, trigger to resumption
AgentHuman
1Run triggeredA scheduled window, an upstream event, an API call or an operator starting it by hand
2Steps and their retry classes loadedThe step order, which writes are declared safe to repeat, and the compensating action defined for each
3Steps executed, state heldThe step results, the run state, the outcomes still unknown and the confidence
4Controls appliedWrite-boundary checks, idempotency checks, ordering checks and the confidence threshold
No human action required
Stages 1 to 4 run unaided, and no undeclared write happens at any of them — the agent is sequencing, and the operator lane opens at the confidence gate.
5DecisionSplits at the confidence gate
Every step resolved
Goes to the named operator to close.
Anything unresolved
Adds a platform owner read first.
Operator review
The run is held at its last checkpoint, with the step that stalled and what it wrote.
Resume · Compensate · Send to platform review
Closed — by the named operator▼
6Downstream systems updatedOnly where write access and approval policy allow it
7Outcome evaluatedDouble writes, failed compensations, resumptions and what review found
Corrections
Each operator resumption is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Executing a write not declared safe to repeat.
Inventing a compensating action nobody defined.
Declaring a half-finished run finished.
Deciding that a timed-out step succeeded.
Automation boundaryAgent acts unaided
✓Sequence the run and hold its state between steps.
✓Retry only the steps declared safe to repeat, and nothing else.
✓Run the compensating action already defined for a failed step.
✓Halt the run at a checkpoint an operator can resume.
Any write happens inside the boundaries agreed at implementation, and nowhere else.
Changing the order the steps run in.
Widening what the agent is allowed to write to.
Abandoning a run and the partial writes under it.
Changes to retry, timeout or boundary rules.
Example output
One run, annotated
This serves a team who will be asked weeks later what a run actually wrote; below is one run exactly as the agent leaves it.
Run output · single executionIllustrative example
Run
Recorded as
Step
Evidence of record
Confidence
Held for
Purchase to pay, one supplier invoice
Payment step timed out
Outcome unknown
Run log, 3 August 2026
Held unretried
The named operator, by name
As receivedTaken from the run log and the step results themselves — nothing on this side is inferred.
What the record holdsStep resultsRun stateTimeout entry
Why no retry hereA timeout is an absence of information, and this write may not repeat.
ActionResumeCompensateSend to platform review
What the score decidesBelow the configured threshold a run gets a platform read before the operator sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every runFrom the systems it touches
03Evidence
Where the retry is allowed
Close orchestration runs the accounting calendar and warehouse orchestration releases work inside the four walls; this is cross-system process orchestration, and its subject is the retried write.
01Approved path
A retry is not free
Repeat a write nobody declared safe to repeat and the second attempt is not a correction — it is a second write, and both of them stand.
02Human review
What was checked, and not found
No system in this workflow offers exactly-once delivery from end to end, and the systems involved do not agree on ordering, so duplicate and out-of-order messages are handled as ordinary traffic rather than assumed away.
04Build an evidence trail
The run, the step that failed inside it and the operator who resumed it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
A workflow-level replay-safety figure can read clean while long-running approval chains carry most of the resumptions. Nestack reports the resumption rate by workflow, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Long-running approval chains
9.4%
3.7×
Review
Third-party payment steps
6.7%
2.6×
Review
Batch-window integrations
4.2%
1.7×
Watch
Single-system routine runs
2.2%
0.9×
Normal
Bar: resumption-rate lift vs. single-system baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What a retried write costs
The loop shuts when the step retried into a double write is a standing case. That suite is what the next run released is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Resumption rate rises on long-running approval chains.
02Diagnose
The step that timed out, retried, and paid the same invoice twice is worked backwards until one cause is left standing.
03Improve
Changes leave numbered, and the runs that forced them are filed underneath.
04Verify
Nothing releases while a single run case is still red.
05Learn
It is kept for good, and the idempotency rules are rewritten alongside it.
Learn → DetectThe return edge. The next run is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, systems, run orchestration, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Process-inventory and automation-boundary work.
02Source-system and API assessment.
03Step-definition and write-boundary rule mapping.
04Run-state ingestion and step binding.
05Retry, timeout and idempotency logic.
06Confidence scoring and hold routing.
07Operator resumption workflow.
08Workflow-engine integration.
09Idempotency and compensation cases.
10Guardrails and write-boundary controls.
11Run-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne workflow, one system pairProductionProduction workflow systemsAdvancedMultiple workflows / systems
Introduced at Pilot
Orchestration to your step definitions✓✓✓
Named operator resumption✓✓✓
Process-inventory baseline✓✓✓
Introduced at Production
Reporting by workflow—✓✓
Operator review workflow in your systems—✓✓
Approved write-back—✓✓
Workflow-engine integration—✓✓
Introduced at Advanced
Multi-system compensation chains——✓
Cross-system run packs——✓
High run volume——✓
Multi-system idempotency controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, run volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live workflows and the systems each one writes to→Process inventory and write-boundary definitionWeek 1
02Representative runs, including the ones that failed→Step binding, retry classes and the orchestration baselineWeek 2
03Your compensating actions and who may run them→Write-boundary mapping, retry classes and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Workflow-engine and API assessment, then integration setupWeek 2
05Runs you would not want replayed→Replay cases and the evaluation roundWeek 4
06What no run record may guarantee→Confidence scoring, hold routing, guardrails and write-boundary controlsWeek 3
07A named operator who resumes a stalled run→Release to the named operator, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Six weeks of real work rather than six equal columns; the fifth carries two phases because it must.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Process discovery, write-boundary definition and the automation boundaryW2System integration and the process-inventory baselineW3Run orchestration, retry logic and resumption controlsW4Evaluation suite, replay cases and failure-mode testingW5Workflow-engine integration, pilot runs and targeted correctionsW6One release cycle run under the platform owner, then Agent Care handover
Reading the bandA bar sits over the weeks its own work is named in, and week five carries two by design.
At the end of W6Once the replay record validates, Agent Care assumes the agent.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Operations AI agent
Build a workflow orchestration agent around the write your last retry made twice.
Show us one process that crosses several systems and the step in it nobody is sure about. A write happens only at the steps you declared it may happen at, under the retry class agreed for each one. Everything else halts resumable and waits for a named operator.
