A Buyer's Guide to Long-running agent workflows

A workflow that runs for three days will span several deployments. It starts under one version of the code, one prompt, and one model, and it finishes under others, because nobody pauses releases for in-flight runs. The agent that resumes on Thursday is not the agent that planned on Tuesday, and the plan it is executing was made by a version with different behaviour. Nothing failed. The workflow is being completed by a different system from the one that started it.

A long-running workflow outlives the version that began it, and finishes as something else.

Long-running agent workflows means work spanning hours to weeks, where version skew, deployment during execution, and external waits are the design problems rather than durability.

Why “Context” Is Becoming the New Cloud Infrastructure Layer

Understand how context infrastructure is reshaping retrieval and intelligent systems.

Download Whitepaper

However, most attention goes to persistence and retries, which handle interruption and say nothing about a run being continued by a different version of the system.

If you are a CTO or Head of Engineering at an enterprise, the intent of this article is:

Define why version skew is the distinguishing problem
Show how human and external waits change the design
Lay out how abandonment gets handled

To do that, let's start with the basics.

What Are Long-Running Agent Workflows? The Basic Definition

At a high level, these are agent workflows whose duration exceeds a single process lifetime: hours, days, or weeks, typically because they wait on a human, an external system, or a scheduled event. Durability handles the interruption. What durability does not address is that during a multi-day run your code will be deployed, your prompt may be revised, and your model may be updated, so the run's later steps execute under a configuration its earlier steps did not anticipate. The plan and the executor have diverged.

To compare:

A long-running workflow is a construction project where the drawings are revised while the building goes up. Each revision is an improvement. The foundations were poured to the old ones.

Why Do Long-Running Workflows Matter?

Issues that they address or resolve:

Runs continuing under a different code and prompt version
Deployments interrupting in-flight work
External and human waits with no bounded duration

Resolved Issues by Design Done Well

Version pinned per run or skew handled explicitly
Deployments safe during active runs
Waits bounded with timeout and abandonment behaviour

Core Components of Long-Running Workflow Design

Version pinning or explicit skew handling per run
Deployment compatibility across in-flight versions
Wait state design for human and external dependencies
Timeout and abandonment semantics
Visibility for runs measured in days

Modern Long-Running Practice

Workflow definitions versioned with runs pinned
Backward compatibility maintained across deployments
Wait states with explicit timeouts
Abandonment producing a defined end state
Run inventory visible with age and status

These practices handle the real problem. Pinning a run to its workflow version is what prevents a plan being executed by a different system.

Other Core Issues They Will Solve

Deployments proceeding without pausing releases
Stalled runs surfaced rather than lingering
External waits bounded rather than indefinite

In Summary: Long-running workflows are distinguished by version skew and unbounded waits, not by durability, which is the part already solved.

Importance of Long-Running Workflows in 2026

Agent work increasingly spans human and external timescales. Four reasons explain why this matters now.

1. Deployments are frequent.

A multi-day run will span several releases in any active codebase.

2. Prompts and models change.

Behaviour can shift mid-run without any code deployment.

3. Waits are unbounded by default.

A run waiting on a human or an external event may wait indefinitely.

4. Old runs are invisible.

A workflow started three weeks ago and stalled rarely appears anywhere.

Traditional vs. Modern Long-Running Design

Durability addressed vs. version skew addressed
Deployments avoided during runs vs. compatibility maintained
Waits unbounded vs. timeouts and abandonment defined
Runs invisible vs. inventory with age and status

In summary: A modern design assumes the system will change during the run.

Details About the Core Components of Long-Running Workflow Design: What Are You Designing?

Let's go through each component.

1. Version Layer

Which system executes.

Version decisions:

Workflow definitions versioned
Runs pinned to their version
Migration path for long-lived runs

2. Compatibility Layer

Deploying safely.

Compatibility decisions:

Backward compatibility maintained
Breaking changes gated
In-flight runs tested against new versions

3. Wait Layer

Human and external dependencies.

Wait decisions:

Timeouts per wait state
Reminder and escalation behaviour
External dependency failure handling

4. Abandonment Layer

Ending without completing.

Abandonment decisions:

Abandonment criteria defined
End state produced deliberately
Compensation triggered where needed

5. Visibility Layer

Seeing old runs.

Visibility decisions:

Run inventory with age and status
Stalled runs surfaced
Ownership assigned

Benefits Gained from Design Done Well

Runs completed by the system that planned them
Deployments proceeding safely
Stalled work surfaced rather than lingering

How It All Works Together

Workflow definitions are versioned and runs are pinned to the version they started under, so a plan made on Tuesday is executed by the behaviour that made it rather than by whatever shipped since. Where pinning is impractical, skew is handled explicitly with backward compatibility maintained across deployments and breaking changes gated so in-flight runs are not broken by a release. Wait states carry explicit timeouts with reminder and escalation behaviour, because a run waiting on a human has no natural end and will otherwise sit indefinitely. Abandonment criteria produce a defined end state with compensation triggered where external actions need offsetting. And a run inventory shows age and status so a workflow stalled three weeks ago is visible to somebody who owns it.

Common Misconception

We have durable execution, so long-running workflows are handled.

Durability solves interruption, which is the problem that arises in minutes. The problems that arise over days are different in kind. Your code will deploy several times during a three-day run, your prompt may be revised, your model may be updated, and the run will finish under a configuration its plan did not anticipate. Meanwhile a wait on a human approval has no natural end, so a run can sit for weeks with nobody aware it exists. None of that is a durability question, and durable execution frameworks address it only if you use the versioning they provide.

Key Takeaway: Durability handles interruption. Version skew and unbounded waits are what days and weeks introduce.

Real-World Long-Running Design in Action

Let's take a look at how it operates with a real-world example.

We worked with a team whose multi-day runs finished under different versions, with these constraints:

Version workflow definitions and pin runs
Maintain backward compatibility across deployments
Bound waits with timeouts and abandonment

Step 1: Version and Pin

Same system throughout.

Definitions versioned
Runs pinned
Migration path defined

Step 2: Keep Deployments Safe

Compatibility maintained.

Backward compatibility held
Breaking changes gated
In-flight runs tested

Step 3: Bound the Waits

Nothing indefinite.

Timeouts per wait state
Reminders and escalation
External failure handled

Step 4: Define Abandonment

A real end state.

Criteria defined
End state produced
Compensation triggered

Step 5: Make Runs Visible

Age and status.

Inventory maintained
Stalled runs surfaced
Ownership assigned

Where It Works Well

Frameworks supporting workflow versioning
Waits with identifiable owners for escalation
Teams able to maintain backward compatibility

Where It Does Not Work Well

Durability treated as the whole problem
Breaking changes deployed during active runs
Waits with no timeout or owner

Key Takeaway: Version and pin, keep deployments compatible, bound the waits, define abandonment, make runs visible.

Common Pitfalls

i) Ignoring version skew

A multi-day run spans deployments and finishes under a different configuration from the one that planned it. Pin runs to their version.

Started Tuesday under one version
Finished Thursday under another
Nothing failed

ii) Breaking changes during runs

A deployment that changes a workflow's shape can strand every in-flight run. Maintain compatibility and gate breaking changes.

iii) Unbounded waits

A run waiting on a human has no natural end and will sit indefinitely. Set timeouts with reminders and escalation.

iv) No run inventory

A workflow stalled three weeks ago is invisible until someone asks about the case. Maintain visibility with age and ownership.

Takeaway from these lessons: The distinguishing problem is that the system changes while the run is in progress.

Long-Running Workflow Best Practices: What High-Performing Teams Do Differently

1. Version workflow definitions and pin runs

Ensure a run is completed by the behaviour that planned it.

2. Maintain backward compatibility across deployments

Let releases proceed without stranding in-flight work.

3. Set explicit timeouts on every wait state

Prevent runs sitting indefinitely on a human or external dependency.

4. Define abandonment criteria and end states

Give a run that will never complete a deliberate ending with compensation.

5. Maintain a run inventory with age and ownership

Make stalled work visible before someone asks about the case.

Logiciel's value add is helping teams design long-running workflows for version skew and unbounded waits, which is what days and weeks actually introduce.

Takeaway for High-Performing Teams: Version and pin, stay compatible, bound waits, define abandonment, keep runs visible.

Signals You Are Doing This Well

How do you know it is working? Not by durability, but by whether a deployment can happen mid-run. These are the signals that separate long-running design from persistence.

Runs are pinned. Each executes under the version that planned it.

Deployments are safe. Releases proceed without stranding in-flight work.

Waits are bounded. Every wait state has a timeout and an owner.

Abandonment is defined. Runs that cannot complete end deliberately.

Runs are visible. Age, status, and ownership are known.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. Long-running design depends on, and feeds into, the surrounding platform. Ignoring the adjacencies is the most common scoping mistake.

Agent state persistence supplies durability. Agent orchestration supplies the step model. Human-in-the-loop gates create the waits. Prompt versioning contributes to skew. Naming these adjacencies upfront keeps the work scoped and helps leadership see version skew as the distinguishing problem.

The common mistake is treating each adjacency as someone else's problem. The version pinning is your problem. The compatibility is your problem. The wait bounds are your problem. Pretend otherwise and Tuesday's plan will be executed by Thursday's system. Own the adjacencies you depend on, partner with the teams that hold them, and share the design.

Conclusion

Durable execution solves the problem that arises in minutes, which is interruption, and long-running workflows introduce different problems entirely. A run spanning three days will span several deployments, so it starts under one version of the code, prompt, and model and finishes under others, executing a plan made by behaviour that no longer exists. A wait on a human approval or an external event has no natural end, so runs sit for weeks unnoticed. Version workflow definitions and pin runs to them, maintain backward compatibility so releases can proceed, bound every wait with a timeout, define abandonment, and keep a visible run inventory.

Key Takeaways:

A multi-day run is completed by a different version of the system than started it
Durable execution addresses interruption, not version skew
Waits on humans and external events are unbounded unless deliberately bounded

Designing long-running workflows well requires assuming change. When done correctly, it produces:

Runs completed by the behaviour that planned them
Deployments proceeding without stranding work

Why Great CTOs Don't Just Build, They Evaluate

Learn how disciplined evaluation separates credible AI systems from hype.