Long-running AI work is getting easier to launch.

That is good for operators who need background research, multi-step review, document extraction, or tool-heavy workflows that do not finish in one interactive turn.

But as soon as the run survives the original session, time becomes part of the control layer.

The system now has to answer harder questions.

How long is the run still authorized to continue?

When does approval expire?

When do temporary credentials stop being valid?

How long should retries continue before the workflow must stop, refresh context, or escalate?

That is why AI teams need a deadline contract.

A deadline contract is the run-level policy that binds absolute expiration, per-step timeouts, heartbeat expectations, approval windows, credential-lease ceilings, retry cutoffs, and post-expiry behavior into one visible rule set.

Why this matters now

The current infrastructure trend is clear. Model platforms make long-running work easier. Workflow engines make durable execution normal. Temporary credentials make access safer by shortening how long it lives. Cancellation and recovery semantics are asynchronous by design.

Each of those trends is individually reasonable.

Together, they create a hidden failure mode: the workflow can still be alive after the authority behind it is stale.

That can mean an agent is still retrying after the approval window closed, still polling after the business deadline passed, or still holding partial state after the credentials that justified the action have already expired.

The issue is not just technical neatness. It is operational legitimacy.

The primary docs already show that time is part of workflow identity

1. OpenAI background mode turns one request into a long-lived run

OpenAI's current background-mode guide says background mode lets developers execute long-running tasks asynchronously, poll response objects over time, and keep polling while the request is in queued or in_progress state.

That is useful. It also changes the control problem. The work is no longer bounded by one open connection or one active user interaction. Once the run continues in the background, the business needs a rule for how long that run is still allowed to exist.

2. AWS Step Functions exposes task deadlines and heartbeat requirements explicitly

AWS Step Functions' current Task-state docs say TimeoutSeconds specifies the maximum time a task can run before it fails with States.Timeout. The same docs say HeartbeatSeconds determines how often an activity worker must send heartbeats and that heartbeats indicate the task is still running and needs more time to complete.

The current Step Functions error-handling docs go further. They say States.Timeout is reported when a task runs longer than TimeoutSeconds or fails to send a heartbeat for longer than HeartbeatSeconds.

That is the platform telling operators something simple: work without an explicit time boundary is not a production contract.

Abstract evidence pipeline showing deadline checks, heartbeat gates, approval expiry, and escalation controls for long-running AI agents
Reliable agent workflows need more than retries. They need aligned deadlines for task runtime, heartbeat cadence, approval validity, and credential expiry.

3. Temporal shows that durable workflows still need multiple clocks

Temporal's current activity-failure guide documents several timeout classes: Schedule-To-Start, Start-To-Close, Schedule-To-Close, and heartbeat-driven failure detection. Its workflow-execution overview says a Temporal Workflow Execution is durable, reliable, fully recoverable after failure, and can execute for seconds or years.

That is powerful infrastructure. It also proves the same point from another angle. Durability is not permission. A workflow that can survive failure still needs policy saying when the business wants it to stop trying, stop waiting, or stop acting without a fresh review.

4. Temporary credentials already have hard expiry

AWS IAM's current temporary-credentials guide says temporary credentials expire after a specified interval, calls made with expired credentials fail, and the temporary credentials cannot be extended or refreshed beyond the original interval.

That matters because AI teams increasingly do the right thing and avoid standing privileges. They use short-lived credentials instead. Good. But once the access lease is shorter than the possible workflow runtime, the system needs a clear rule for whether the run pauses, reacquires approval, requests a new lease, or fails closed.

5. MCP cancellation is a request, not magical instant rewind

The current Model Context Protocol cancellation utility says either side can send a cancellation notification for an in-progress request and that both parties must handle race conditions gracefully. The same page says invalid cancellation notifications should be ignored for unknown, completed, or malformed requests.

That is a direct reminder that cancellation is part of an asynchronous protocol, not proof that every downstream effect stopped instantly. Deadline policy cannot depend on wishful thinking about cancel buttons.

What breaks when the deadline contract is missing

1. Approval outlives intent

A manager approved a run at 9:00. The workflow is still retrying at 3:00. The evidence bundle has changed, the queue is different, and the person who approved it is in another meeting. Without a deadline contract, the system may keep moving under stale authority.

2. Credential leases and workflow retries drift apart

Temporary credentials are safer than long-lived secrets. But if the retry policy outlasts the credential lease, operators need to know whether the workflow should stop, refresh the lease under the same approval, or require a new signoff.

3. Heartbeats prove liveness, not legitimacy

A task can still be alive according to heartbeats while being too old to continue under business policy. Runtime liveness and governance validity are not the same thing.

4. Cancellation arrives after partial work

In asynchronous systems, a cancellation request and a completed side effect can cross in flight. If the workflow has no absolute deadline and no post-expiry rule, teams can misread a cancel event as proof that nothing consequential happened.

5. Recovery becomes a stale-state replay

Durable execution is useful only when resume policy is explicit. If a run wakes up after an outage, the system still needs to ask whether the approval, credentials, evidence freshness, and business deadline are all still valid.

What a deadline contract should include

1. An absolute run expiration

Give every run a maximum age. After that timestamp, the workflow must fail closed, escalate, or request a fresh start. Do not let retries keep work alive indefinitely just because the orchestrator can.

2. Step-level timeout and heartbeat policy

Record the per-step runtime ceiling, heartbeat expectations, and which failures should be retried versus routed to human review.

3. Approval-window rules

Say how long an approval is valid, what kinds of scope change void it, and whether reacquiring credentials or refreshing evidence also requires a new approval receipt.

4. Credential-lease alignment

Keep the access lease visibly tied to the run. If the run deadline is longer than the lease, document how the system reacquires access and who must approve that renewal.

5. Retry and redrive cutoff

Retries should stop before the run becomes operationally stale. Redrive policy should name the latest point a run can be resumed without reopening approval, refreshing evidence, or reacquiring scoped credentials.

6. Post-expiry behavior

Expiry should trigger a deterministic action: stop, quarantine, request re-approval, reacquire leases, or split unfinished work into a new run. Silent drift is not acceptable policy.

7. Evidence of the active clock

Store the run start time, absolute deadline, latest heartbeat, approval expiry, credential expiry, retry count, and final expiry outcome in one record another operator can inspect without guesswork.

Questions buyers and operators should ask

  1. What is the maximum age of one AI run before it must stop or be re-approved?
  2. Do approval receipts, credential leases, and retry policy all point to the same effective deadline?
  3. What happens if the task is still healthy according to heartbeats but the business deadline has passed?
  4. Can the workflow resume after an outage without first re-checking approval, evidence freshness, and access validity?
  5. When cancellation is requested, what proof shows whether any downstream side effect already happened?
  6. Where can an operator see the run's remaining time budget right now?

The commercial takeaway

Long-running AI automation is becoming normal infrastructure.

The next differentiator will not be who can keep a workflow alive the longest.

It will be who can prove the workflow stayed inside valid time, valid authority, and valid review boundaries the whole way through.

The teams that define a deadline contract will have a clearer answer when a run crosses a shift change, survives a disconnect, burns through its first credential lease, or wakes up after an outage. They will know whether to continue, refresh, or stop.

If the organization cannot name the deadline that governs one AI run, it cannot fully explain why that run was still allowed to act.

Related reads

Sources consulted