Main site

Operations AI agent · Orchestration

Workflow Orchestration AI Agent

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.

Typical delivery
4–6 weeks
Deployment
Your stack
Named operator
Write boundary
After launch
Agent Care

What this agent does

Sequences the run, never calls it finished

In

  1. 01

    A run starts, and every step in it is declared in advance as safe to repeat or not safe to repeat.

  2. 02

    A step succeeds, and its result enters the run state before the next step is allowed to begin.

Reason

  1. 03

    A step times out, and the missing answer is recorded as an absence, not as a failure.

  2. 04

    A retry is considered, and it happens only where the step it would repeat was declared safe to repeat.

  3. 05

    A step fails outright, and the compensating action defined for it is proposed rather than improvised.

Decide

  1. 06

    A message arrives twice, or out of order, and the run state decides which one it keeps.

  2. 07

    A compensating action fails, and the run stops half-undone with both halves written down.

Out

  1. 08

    A run cannot go on, and it halts at a checkpoint a named operator is able to resume it from.

  2. 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

  1. 1Run triggeredA scheduled window, an upstream event, an API call or an operator starting it by hand
  2. 2Steps and their retry classes loadedThe step order, which writes are declared safe to repeat, and the compensating action defined for each
  3. 3Steps executed, state heldThe step results, the run state, the outcomes still unknown and the confidence
  4. 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

  1. 6Downstream systems updatedOnly where write access and approval policy allow it
  2. 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 required

8 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 boundary

    Agent 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 execution

Illustrative example
Run
Purchase to pay, one supplier invoice
Recorded as
Payment step timed out
Step
Outcome unknown
Evidence of record
Run log, 3 August 2026
Confidence
Held unretried
Held for
The named operator, by name

As received

Taken from the run log and the step results themselves — nothing on this side is inferred.

What the record holds

  • Step results
  • Run state
  • Timeout entry

Why no retry here

A timeout is an absence of information, and this write may not repeat.

What the score decides

Below the configured threshold a run gets a platform read before the operator sees it.

Action

ResumeCompensateSend to platform review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every run

From 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.

04

Build 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.

  • Workflow engines

    • Camunda
    • Temporal
    • Airflow
    • Step Functions

  • Enterprise systems

    • SAP
    • Oracle
    • NetSuite
    • Salesforce
    • ServiceNow

  • Messaging and events

    • Kafka
    • RabbitMQ
    • SQS
    • Azure Service Bus

Agent

Cross-system orchestration

  • Reads the run state
  • Sequences the steps
  • Holds for the operator

  • Integration middleware

    • MuleSoft
    • Boomi
    • Workato
    • Tray

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six valves between the model and your systems

Six valves along one line, the last the tightest. What flows on is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeHalt the run before the write step when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, step definitions and retry rules, and note the version each run executed under.Track
L4TraceabilityRecord each step, what it returned, every retry attempted and the operator who resumed the run.Record
L3Operator releaseHold a stalled run for a named operator; the hold governs resumption, not whether the earlier writes were right.Gate
L2Write-boundary rulesTest each write against the boundary agreed at implementation, and refuse a step that falls outside it.Restrict
L1Confidence thresholdsRoute a run carrying an unresolved step to a platform owner read before the operator sees it.Require review
Model coreRun executed — the steps, what each returned, the retries and what is still unknown
L1 – L2
Test whether a run may go on
L3
Leaves the resumption to a named operator
L4 – L5
Keep the run and the step behind it
L6
Halts before the write step when signals degrade

How Nestack evaluates it

Evaluate the whole run — not only the step that came back wrong.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the run a business process leans on

  1. E1Final-output evaluationDid the run leave the systems it touched in the state it recorded?
  2. E2Step-level evaluationDid the agent read the live run state and the current step definitions?
  3. E3Tool evaluationDid it call the correct system and the correct record?
  4. E4Confidence calibrationDo low-confidence runs actually attract more operator resumptions?
  5. E5Slice evaluationHow does performance change across specific workflows?
  6. E6Business outcomeHow many runs needed an operator before they could close?

Floor — the systems a run writes to

Failure modes

Where each failure originates in the agent

Seven failure modes, each placed at the stage a run first shows it.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • MX-03

      Stale checkpoint read

      The checkpoint no longer matches the system downstream.

    Stage gathers

    The run state, the steps, the keys and the limits

  2. 02 · Reasoning

    2 modes

    • MX-04

      Timeout read as failure

      An unknown outcome is retried and paid twice.

    • MX-06

      Idempotency wrongly declared

      A step marked safe to repeat was not.

    Stage proposes

    The steps run, the retries and what is unknown

  3. 03 · Tool / write

    2 modes

    • MX-02

      Resumed without the read

      A stalled run moves on without the platform read.

    • MX-05

      Ordering assumed

      An older message overwrites a newer state.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • MX-01

      Compensation left half-done

      The compensating action failed and left it half-undone.

    Stage returns

    The state the business process is left in

  5. 05 · Change / Version

    1 mode

    • MX-07

      Silent retry drift

      A rule change widens what the agent will repeat.

    Stage tracks

    Model, prompt, retry rules and step limits

  • Sev-1 · a write outside the boundary
  • Sev-2 · the same write lands twice
  • Sev-3 · a step stalls, the run halts
See the complete Operations failure-mode catalogue

Affected slices

Long chains absorb the resumptions

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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Long-running approval chains9.4%3.7×Review
Third-party payment steps6.7%2.6×Review
Batch-window integrations4.2%1.7×Watch
Single-system routine runs2.2%0.9×Normal

Bar: resumption-rate lift vs. single-system baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Resumption rate rises on long-running approval chains.

  2. 02

    Diagnose

    The step that timed out, retried, and paid the same invoice twice is worked backwards until one cause is left standing.

  3. 03

    Improve

    Changes leave numbered, and the runs that forced them are filed underneath.

  4. 04

    Verify

    Nothing releases while a single run case is still red.

  5. 05

    Learn

    It is kept for good, and the idempotency rules are rewritten alongside it.

  6. Learn → Detect

    The 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.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Process-inventory and automation-boundary work.Week 1
  2. 02Source-system and API assessment.Week 1, Week 2
  3. 03Step-definition and write-boundary rule mapping.Week 1, Week 2
  4. 04Run-state ingestion and step binding.Week 2
  5. 05Retry, timeout and idempotency logic.Week 2, Week 3
  6. 06Confidence scoring and hold routing.Week 3
  7. 07Operator resumption workflow.Week 3, Week 4
  8. 08Workflow-engine integration.Week 5
  9. 09Idempotency and compensation cases.Week 4, Week 5
  10. 10Guardrails and write-boundary controls.Week 4
  11. 11Run-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final 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 price
Confirmed after discovery based on integrations, workflow complexity, run volume, approval controls and deployment requirements.
Separate from build
Build 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.

  1. 01Your live workflows and the systems each one writes to

    Process inventory and write-boundary definition

    Week 1

  2. 02Representative runs, including the ones that failed

    Step binding, retry classes and the orchestration baseline

    Week 2

  3. 03Your compensating actions and who may run them

    Write-boundary mapping, retry classes and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Workflow-engine and API assessment, then integration setup

    Week 2

  5. 05Runs you would not want replayed

    Replay cases and the evaluation round

    Week 4

  6. 06What no run record may guarantee

    Confidence scoring, hold routing, guardrails and write-boundary controls

    Week 3

  7. 07A named operator who resumes a stalled run

    Release to the named operator, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, 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.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Process discovery, write-boundary definition and the automation boundary

W2System integration and the process-inventory baseline

W3Run orchestration, retry logic and resumption controls

W4Evaluation suite, replay cases and failure-mode testing

W5Workflow-engine integration, pilot runs and targeted corrections

W6One release cycle run under the platform owner, then Agent Care handover

Reading the band
A bar sits over the weeks its own work is named in, and week five carries two by design.
At the end of W6
Once the replay record validates, Agent Care assumes the agent.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your live workflows
Named operator
Write boundary
After launch
Agent Care available

Nestack Agents · Workflow orchestration

AGT-OP-08 · Agent Care available after launch

Build a workflow orchestration agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your workflows

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.