# Agent runtimes, orchestration and harnesses The runtimes, orchestration systems and harnesses turning model calls into durable work with state, recovery and inspectable transitions. Source: https://aecon.ai/guides/ai-agent-runtimes-orchestration-harnesses Author: Agentic Economy Published: 2026-09-13 Updated: 2026-09-14 **Chapter 6 of The Hitchhiker's Guide to the Agentic Economy** [Report hub](/guides/hitchhikers-guide-agentic-economy-2026) · Previous: [context, memory and data](/guides/ai-agent-context-memory-data) · In this chapter: [the controlled execution path](#section-a-model-call-is-not-a-durable-unit-of-work) · [run-state machine](#section-the-run-state-machine) · [market map](#section-who-supplies-runtimes-and-orchestration) · [sandboxes](#section-sandboxes-are-an-execution-boundary-not-an-orchestrator) · [run contract](#section-an-agent-run-contract) · Next: [tools, browsers and service access](/guides/tools-browsers-and-service-access) ## Our view The durable asset in an agent system is the controlled execution path, not the framework name. A framework can make a first model call easy. A production route has to preserve what was accepted, what has run, what is waiting, what may be retried, what requires approval and what external effect actually occurred. Framework choice matters less than five observable properties: 1. the run can pause and resume without losing its state; 2. a retry can be safe because the logical effect has an idempotency rule; 3. a worker or process failure does not silently lose the run; 4. each state transition is inspectable by the people accountable for the job; and 5. an ambiguous external effect can be reconciled before the run is closed. **Runtime** means the process and infrastructure that executes work. **Orchestration** means the state transitions, scheduling, branching, waiting, retry, cancellation and compensation that coordinate that work. A **harness** is the boundary around a model that supplies context, tools, memory, approvals, policy checks and the execution loop. These are related layers, not interchangeable labels. The Australian Signals Directorate uses the same wider control boundary in its current guidance. It describes an agentic AI harness as the model plus the surrounding infrastructure that manages context, memory, tools, permissions and execution ([ASD, "Agentic AI harnesses"](https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/agentic-ai-harnesses)). This is globally relevant architecture, not an Australia-specific runtime. > **Key Takeaways** > > - A model response becomes a durable unit of work only when the system gives it a run identity, a state record, a recovery path and an acceptance condition. > - Checkpointing the orchestration state does not prove that a network side effect happened once. The side effect needs its own intent, idempotency and receipt or reconciliation record. > - Waiting for a person, retrying a transient error, cancelling a run and compensating an earlier effect are different states. Combining them into `failed` hides operational decisions. > - A sandbox can isolate files, processes and network access while the orchestrator loses the job, or the orchestrator can survive while the sandbox expires. The contract must join both lifecycles. > - Provider documentation establishes available capability at a date. It does not establish production adoption, reliability or accepted business value. > - The right commercial comparison is cost per accepted job, including model calls, orchestration, sandbox resources, storage, review, recovery and unresolved effects. This chapter uses provider documentation, official repositories and product pages checked on 13 September 2026. Product names, preview status, pricing and limits can change. Documented features are recorded separately from adoption and outcome evidence. ### Sources and scope Agentic Economy compiled the market snapshot from the primary provider sources linked in this chapter. The method records what a provider says a product supports, then asks what evidence would be needed to establish use or reliability in a buyer's route. No provider was independently benchmarked here, and no synthetic job is used as evidence of production performance. [About Agentic Economy](/about) explains the publication and its Australian focus. Corrections can be submitted through the [contact page](/contact). ## Runtimes are separating from orchestration The market is dividing into three overlapping layers. Agent frameworks assemble model calls, tools and state. Managed runtimes host and supervise agent execution. Durable workflow systems persist long-running work across failures, approvals and external events. Sandboxes form a fourth adjacent category by isolating the environment in which code or browser work executes. Vendors are expanding across these boundaries. Model and cloud providers are adding managed agent runtimes. Framework companies are adding persistence and deployment. Workflow companies are adapting durable execution to model-directed work. Sandbox providers are moving closer to the runtime through session APIs and reusable environments. Our view is that the winning products will be defined less by their demo syntax than by the execution state they can preserve and explain. OpenAI's stated direction makes the convergence explicit: “Useful agents need a powerful harness that manages context, uses tools efficiently, and coordinates subagents” ([OpenAI, "Introducing the Agents API"](https://openai.com/index/introducing-the-agents-api/)). That is a platform claim, not a neutral market verdict, but it shows where model providers are expanding: beyond inference and into the operating layer around the model. ## A model call is not a durable unit of work ![A switchyard illustrates how a durable runtime routes work through explicit states instead of treating one model call as the whole job.](/media/editorial-library/switchyard-medium.webp) A model call is usually a request and a response. A unit of work has a wider lifecycle: ```text accept objective and authority -> create job and run identity -> select versioned context and policy -> execute bounded steps -> record checkpoints and effects -> wait, ask for approval or retry when required -> reconcile external state -> deliver and obtain acceptance ``` The distinction is important because a model can finish while the job remains unresolved. A tool may time out after the service accepted the request. A person may not answer an approval prompt for two days. A worker may die after a database commit but before recording the response. A sandbox may reach its time limit while a process is still running. Each event requires a named transition and an operator decision. ### Three layers with different owners | Layer | Primary responsibility | Questions it answers | What it cannot prove by itself | | --- | --- | --- | --- | | **Runtime** | Start processes, allocate workers, enforce resource limits, stream output and terminate work | Where is the process? Is its lease alive? What resources and version are running? | Whether the business job is complete or an external effect is committed | | **Orchestration** | Persist state, schedule steps, branch, wait, retry, cancel, compensate and resume | Which transition is next? What has been checkpointed? What can be replayed? | That an external provider did or did not apply a request during a transport failure | | **Harness** | Join model, context, tools, memory, policy, approvals, output schema and evidence | What may the model see or call? Which action is awaiting approval? What was exposed? | That a valid tool call produced the intended business outcome | The application or system of record still owns the meaning of a business effect. Chapter 7 covers tool and service access. Chapter 9 covers identity, authority and policy. Chapter 10 covers evaluation, observability and incident evidence. This chapter joins those boundaries at the run level. ## The run-state machine The state machine below is a compact control model. It is not a provider standard. A production implementation may add domain-specific states, while preserving the distinctions that determine whether a person can act. ```text admitted | v running -------------------------------> completed | ^ | | +--> waiting_for_input --------------------+ | | | +--> running | +--> cancelled | +--> awaiting_approval -------------------> running | | | +--> cancelled | +--> retry_wait --------------------------> running | | | +--> failed | +--> compensating --> compensated | | | +--> failed | +--> needs_reconciliation | +--> cancelling --> cancelled | | | +--> needs_reconciliation | +--> needs_reconciliation --> reconciling | +--> completed +--> compensated +--> failed +--> cancelled ``` `admitted` means the job has entered this runtime; it does not mean that its outcome has been accepted. `waiting_for_input` means the run is paused for a required fact or user response. `awaiting_approval` means the system has enough information to present an action but lacks the required authority. An approval denial or expiry ends or narrows that action; it is never converted into approval by a retry. `retry_wait` is a scheduled decision with an attempt budget, not an unbounded loop. `compensating` means a defined technical or domain action that reverses or offsets an earlier effect where the domain supports it; it is not a promise of financial or legal remedy. `needs_reconciliation` means an external effect is uncertain and must not be silently replayed. Run completion requires execution and external-effect evidence; business acceptance remains a separate decision in the job record. Every transition carries a run ID, a monotonic transition ID, an event time, the actor or service that caused it, the previous state, the next state, a reason and the relevant version. State alone is not enough. An operator needs the transition history and the evidence that permitted it. ### Retry is a business decision Retries are appropriate for a bounded class of failures: a lost worker before a durable checkpoint, a rate-limit response with a known retry rule or a temporary dependency outage. They are unsafe when the system cannot tell whether a side effect committed, when the request is not idempotent or when the input has changed under the run. The retry key identifies the logical effect, not the attempt. A new attempt can then ask the destination system for the status of that effect rather than creating a new one. If the destination cannot answer, the run moves to reconciliation rather than pretending that another request is safe. ## The double-durability seam The most important seam in agent execution is between durable orchestration and durable effects. ```text orchestration durability effect durability ------------------------- --------------------------- run identity logical effect identity checkpoint / event history intent record lease / worker ownership idempotency key pause / resume provider receipt or status retry / cancellation reconciliation and compensation ``` Orchestration durability answers, “What did this run believe and what step should it take next?” Effect durability answers, “What did the outside system receive, commit or reject?” Both are needed for a reliable route. For example, suppose a worker sends an update to an external system and loses its network connection before receiving the response. A checkpoint taken before the call proves that the step was ready. It does not prove whether the update happened. A checkpoint taken after the call is unavailable because the worker disappeared. The safe path records an intent with a stable idempotency key, queries or receives a destination status where possible, and holds the run in `needs_reconciliation` until the effect is known. A retry without that seam can duplicate the consequence. This is why “exactly once” needs careful qualification. A runtime may execute a workflow step once in its own history, while the external request can be delivered more than once unless the destination or application supplies idempotency. Durable infrastructure reduces uncertainty. It does not remove the need for a domain-level effect record. ### What durability covers At minimum, the run record preserves: - the accepted objective, owner, authority and acceptance rule; - workflow, prompt, model, tool, policy and sandbox versions; - state transitions and checkpoints, including the last safe resume point; - inputs, selected context references and material tool results; - each logical external effect, idempotency key, intent, receipt and status; - approval requests, approver identity, scope, expiry and decision; - retry budget, backoff, timeout and cancellation reason; - sandbox identifier, image or template, network policy, TTL and snapshot reference; - completion, failure, compensation or reconciliation evidence; and - retention, deletion and incident ownership. The record need not copy every prompt or document into every system. It does need stable references, hashes or protected evidence sufficient to distinguish a replay from a new action and to investigate a material result. ## Who supplies runtimes and orchestration The market is not one category. Some suppliers provide a graph library, some provide a model-agent runner, some provide a managed agent runtime, some provide a durable workflow engine and some provide an isolated execution environment. Buyers often combine them. | Supply layer | Representative provider | Documented capability at 13 September 2026 | Buyer and business model | Evidence boundary | | --- | --- | --- | --- | --- | | **Graph framework and control plane** | [LangGraph and LangSmith](https://docs.langchain.com/oss/python/langgraph/persistence) | LangGraph checkpoints graph state by thread, supports interrupts, resume and retry; LangSmith Agent Server adds runs, a queue, workers, PostgreSQL-backed persistence and Redis signalling, with cloud, hybrid and self-hosted deployment options ([Agent Server](https://docs.langchain.com/langsmith/agent-server), [deployment](https://docs.langchain.com/langsmith/deployment)). | Open-source graph framework plus hosted or self-hosted observability and deployment; usage, seats and infrastructure vary by plan. | Documentation establishes persistence and deployment modes. It does not establish a common production failure rate or accepted-job denominator. | | **Agent SDK and runner** | [OpenAI Agents SDK](https://openai.github.io/openai-agents-python/agents/) | `Runner` manages turns, tools, handoffs and guardrails; `RunState` can serialise a paused run and resume it, including human approval interruptions ([running agents](https://openai.github.io/openai-agents-python/running_agents/), [human in the loop](https://openai.github.io/openai-agents-python/human_in_the_loop/)). The SDK documents integrations with Temporal, Dapr and Restate for durable long-running execution. | SDK-led application development with model and platform usage, plus customer-owned or third-party durability and hosting choices. | The SDK documents a runner and extension points. A session or `RunState` is not automatically a complete durable workflow service, and integration availability is not adoption evidence. | | **Open agent framework and managed runtime** | [Google ADK and Agent Runtime](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/adk) | ADK documents workflow and multi-agent orchestration, tools, evaluation and local or managed deployment. Agent Runtime is a fully managed, container-based runtime that supports ADK and other frameworks subject to its runtime contract ([runtime](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime)). ADK resumability continues completed workflow tasks from an invocation ID, but side-effecting tools may run more than once ([resumability](https://adk.dev/runtime/resume/)). | Open-source framework paired with Google Cloud managed runtime and related platform services, generally consumption and infrastructure based. | Current documentation demonstrates a clear capability boundary and an explicit at-least-once tool caveat. It does not prove that a buyer's tools are safely replayable. | | **Workflow graph and durable extension** | [Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/) | Workflows execute graph supersteps with checkpoint support. Checkpoints can capture executor state, pending messages and requests; the Durable Extension adds persistent sessions, durable execution, checkpoint and resume, distributed scale and human-in-loop waits ([checkpoints](https://learn.microsoft.com/en-us/agent-framework/workflows/checkpoints), [durable extension](https://learn.microsoft.com/en-us/agent-framework/integrations/durable-extension)). | Framework and hosting choices around Azure Functions, Foundry hosted agents or customer-owned compute; cloud and infrastructure usage plus enterprise services. | The docs distinguish ordinary workflow checkpoints from the Durable Task infrastructure. Storage, trust boundaries and application policy remain buyer responsibilities. | | **Durable workflow engine** | [Temporal](https://docs.temporal.io/) | Temporal documents crash-resilient workflows that resume after worker, network or host failure and can run from seconds to years. Its AI guidance covers long-running agent state, human approval and retryable processing pipelines ([durable AI](https://github.com/temporalio/documentation/blob/main/docs/ai/index.mdx)). | Open-source server and SDKs plus Temporal Cloud, with managed usage and storage pricing. | The engine preserves workflow history and coordinates retries. Activities that touch external systems still need idempotency and reconciliation. | | **Workflow and data-flow orchestrator** | [Prefect](https://docs.prefect.io/v3/concepts/tasks) | Tasks have tracked states, retries, caching, concurrency and timeouts. Flows can pause or suspend for typed input, and the state model distinguishes retrying, paused, suspended, cancelling, cancelled, failed and crashed ([interactive workflows](https://docs.prefect.io/v3/advanced/interactive), [states](https://docs.prefect.io/v3/concepts/states)). | Open-source orchestration plus Prefect Cloud managed control plane and hosted plans, with usage and infrastructure costs. | Strong workflow primitives do not make Prefect an agent-specific harness or prove that a model trajectory is useful. | | **Data and asset orchestrator** | [Dagster](https://docs.dagster.io/) | Dagster documents op retry policies, run retries after worker failure and re-execution from failure while reusing outputs where an IO manager supports it ([op guidance](https://docs.dagster.io/guides/build/ops), [run retries](https://docs.dagster.io/deployment/execution/run-retries), [re-execution API](https://github.com/dagster-io/dagster/blob/master/python_modules/dagster/dagster/_core/execution/api.py)). | Open-source data orchestration plus Dagster Plus managed service and enterprise capabilities. | It is primarily an asset and data orchestrator. Re-execution semantics and materialisation storage must be checked for the buyer's effect boundary. | | **Isolated agent sandbox** | [E2B](https://www.e2b.dev/) | E2B documents isolated sandboxes for code and tools, custom templates and filesystem snapshots. Its hosted service describes per-session microVM isolation and usage-based runtime pricing ([documentation](https://e2b.dev/docs), [pricing](https://e2b.dev/pricing)). | Hosted sandbox usage charged by runtime, with enterprise and customer-environment options described by the provider. | Isolation and snapshot capability describe an execution substrate. They do not provide the outer run's acceptance, effect receipt or recovery policy. | | **Serverless sandbox and compute** | [Modal Sandboxes](https://modal.com/docs/guide/sandboxes) | Sandboxes expose commands, files and services with a lifecycle, reconnect by ID and a documented time limit. Modal documents filesystem snapshots for longer-lived work and metered resources ([resources](https://modal.com/docs/guide/sandbox-resources)). | Managed, pay-for-use compute and sandbox resources, generally metered by requested or used CPU, memory and duration. | A reconnectable container is not a durable workflow history. Limits, snapshots and billing need to be in the run contract. | | **Isolated workspace runtime** | [Daytona Sandboxes](https://www.daytona.io/docs/sandboxes) | Daytona documents isolated containers or VMs, dedicated filesystem and network namespaces, GPU support, pause and resume, snapshots and a separate control architecture ([architecture](https://www.daytona.io/docs/architecture/)). | Hosted sandbox and control-plane usage, with resource and lifecycle billing and customer-managed options described in its documentation ([billing](https://www.daytona.io/docs/billing)). | The workspace can outlive a process, but that does not establish that the corresponding orchestration state or external effects are recoverable. | | **Edge and serverless sandbox** | [Cloudflare Sandbox](https://developers.cloudflare.com/sandbox/) | The Sandbox SDK runs isolated containers through Workers, Durable Objects and Containers, with commands, files, background processes and services. Cloudflare documents separate VM isolation and paid-plan resource pricing ([security](https://developers.cloudflare.com/sandbox/concepts/security/), [architecture](https://developers.cloudflare.com/sandbox/concepts/architecture/), [pricing](https://developers.cloudflare.com/sandbox/platform/pricing/)). | Cloudflare Workers, Durable Objects, Containers, logs and network usage under paid plans; package and SDK maturity must be checked at purchase. | The current documentation labels the SDK 1.0 path as preview. Cloudflare's substrate can host a sandbox, but the buyer still owns job semantics and effect reconciliation. | This table describes available supply, not a winner. The providers can be composed. For example, an OpenAI runner can call a sandbox client, a LangGraph graph can be hosted on a managed runtime, and a Temporal workflow can hold a run around an independently provisioned worker. The composition is where the control boundary becomes real. ### Provider capability versus adoption evidence The same word, “durable”, can refer to different evidence. The market therefore needs an explicit durability ladder. | Evidence available | What it establishes | What remains unproven | | --- | --- | --- | | **Official documentation** | The provider describes a supported feature, limit or deployment mode at a checked date | Reliability under the buyer's workload, failure distribution and contract performance | | **Open-source repository or SDK** | Code, interfaces and an inspectable implementation are available under stated terms | That the hosted service uses the same path, or that the route is maintained for the buyer's lifecycle | | **Hosted availability and pricing** | A buyer can procure a service with a stated commercial boundary | Successful deployment, accepted work, support quality or total cost | | **Public case study, customer logo or partner integration** | Someone publicly claims a relationship or use case | Comparable volume, independent validation, failure rate or causal business value | | **Production trace and effect records** | A named job population can be measured for recovery, duplication, acceptance, cost and incidents | Generalisation beyond that population and configuration | | **Independent comparative evidence** | Multiple routes can be compared under a declared workload and failure protocol | Long-term maintainability, organisational fit and changing provider terms | The public sources reviewed for this chapter provide substantial documentation, repositories, integrations and hosted offerings. They do not provide a comparable denominator of production runs across the named providers. A public SDK count, GitHub activity, job listing, logo or constructed demonstration is therefore not used as proof of adoption or durable reliability. The missing evidence is a population of real runs linked to state transitions, effect outcomes, acceptance, recovery time and cost. ## Business models around the controlled path The commercial layers overlap, but four models recur. ### Open framework, paid control plane LangGraph, OpenAI Agents SDK, Google ADK and Microsoft Agent Framework make some framework or SDK code available while providers and partners monetise managed deployment, models, traces, seats, support, infrastructure or enterprise controls. The buyer gets speed and ecosystem reach. The tradeoff is a possible control-plane dependency and a need to verify export, retention, region, version and self-host paths before a consequential workflow is embedded. ### Managed agent runtime LangSmith Agent Server, Google Agent Runtime and Microsoft's Foundry and Durable Task options sell a managed path for deployment, workers, storage, scaling, identity integration and operations. The buyer pays for a reduced platform burden while the full route still includes always-on or burst compute, state and trace storage, network transfer, approval waits, sandbox resources and provider support. A managed runtime can remove operational toil without removing application-owned idempotency. ### Durable workflow service Temporal, Prefect and Dagster monetise orchestration around a workflow or data platform. Open-source deployment can reduce licence dependency while moving the cost into operations, upgrades and on-call ownership. Hosted offerings charge for managed control-plane capacity, actions, storage or plan features. Their state models and retry semantics determine whether they can carry an agent route across an external effect boundary safely. ### Metered sandbox and compute E2B, Modal, Daytona and Cloudflare Sandbox charge for some combination of CPU, memory, disk, active duration, storage, network, logs or managed control-plane use. Enterprise and customer-environment options change the deployment boundary rather than the basic economic question. Long pauses, snapshots, idle workspaces, egress and cleanup can matter as much as execution seconds. The useful cost denominator is an accepted job, not a successful model call: ```text cost per accepted job = (model and inference + orchestration and state + sandbox and compute + storage and network + human approval and correction + recovery, duplicate and reconciliation work) / accepted jobs ``` Chapter 4 covers model and inference economics. Chapter 7 covers tool and service access. The runtime layer makes the other costs visible when work pauses, retries or has to be recovered. ## Sandboxes are an execution boundary, not an orchestrator An agent may need to inspect untrusted files, run code, render a document, use a browser or start a temporary service. A sandbox can reduce the blast radius of that execution by isolating processes, files, network access and resources. It does not decide whether the business job is allowed, complete or accepted. The named suppliers document different versions of the same separation: | Sandbox concern | What the provider may preserve | What the outer run still has to record | | --- | --- | --- | | **Isolation** | A container, VM or namespace boundary for process, filesystem and network activity | Image or template digest, user or tenant boundary, egress allowlist, injected secret scope and resource limit | | **Workspace state** | Files, processes, snapshots or volumes that can be resumed or restored | Sandbox ID, snapshot ID, creation and expiry, source versions and whether state is trusted after restore | | **Process lifecycle** | Start, reconnect, pause, timeout, terminate and cleanup operations | Which run owns the process, what step was active, termination evidence and orphan cleanup owner | | **Long duration** | A longer TTL, persistent volume or snapshot-based continuation | Whether the run lease, approval and authority are still valid when work resumes | | **External effect** | Network access or a service endpoint from inside the sandbox | Intent, idempotency key, receipt, status query and reconciliation state outside the sandbox | OpenAI's sandbox-agent documentation lists local and hosted clients including E2B, Modal, Daytona and Cloudflare, and documents saved sandbox state and resumable `RunState`. That is useful integration supply, but the documentation also makes the sandbox an explicit execution layer rather than a guarantee about an external outcome ([sandbox agents](https://openai.github.io/openai-agents-python/sandbox_agents/), [sandbox clients](https://openai.github.io/openai-agents-python/sandbox/clients/)). Google ADK documents a code-execution sandbox with persistent code and data within a session, while its resumability documentation warns that side-effecting tools may execute more than once ([code execution](https://adk.dev/tools/google-cloud/code-exec-agent-engine/), [resumability](https://adk.dev/runtime/resume/)). The double-durability seam is especially visible here. A snapshot can preserve a file and a process while the outer worker loses its transition record. Conversely, an orchestrator can resume the run while the sandbox has expired and the file or process is gone. A safe contract treats the sandbox as a leased dependency, verifies its version and state on resume, and moves the run to reconciliation when a process may have acted externally. ### Sandbox controls that are easy to miss - **Network policy:** code isolation is not data isolation if the sandbox can call every host on the internet. - **Credentials:** inject short-lived, scoped credentials and keep the credential exchange outside untrusted workspace files. - **Resource limits:** CPU, memory, disk, process count and wall-clock limits are part of availability and cost control. - **Snapshot trust:** a snapshot may contain secrets, generated code or poisoned data; restore rules need an owner and validation. - **Cleanup:** timeouts and cancellations need evidence that background processes, volumes, tokens and endpoints were released. - **Tenant separation:** sharing a sandbox or volume across tenants is a different risk from sharing a model context. The boundary must be named. ## An Agent Run Contract **AE analysis artifact: Agent Run Contract.** This is a proposed control record, not a provider standard. It owns one execution lifecycle and references the current context, service, delegation and authority records rather than copying them. Chapter 10 defines the [shared record ownership and join keys](/guides/ai-agent-evaluation-observability-security#section-one-job-record-five-linked-control-views). Complete the contract before a consequential route is released, then bind each field to evidence an operator can inspect. ### Contract template ```yaml contract_version: 1 job: job_id: objective: acceptance_rule: owner: authority_reference: run: run_id: parent_run_id: workflow_version: model_and_prompt_versions: state: admitted | running | waiting_for_input | awaiting_approval | retry_wait | compensating | cancelling | needs_reconciliation | reconciling | completed | compensated | failed | cancelled transition_log: checkpoint: store: last_committed_transition: resume_rule: retention_and_deletion: retry_and_timeout: retryable_failures: max_attempts: backoff_and_jitter: model_tool_run_timeouts: cancellation_grace: effects: - effect_id: attempt_ids: intent_record: idempotency_key_and_namespace: receipt_or_status_query: reconciliation_status: ambiguity_rule: compensation_rule: waits_and_approvals: - wait_id: input_required: - approval_id: approval_scope_and_digest: approver: approval_expiry: execution_isolation: sandbox_provider_and_id: image_or_template_digest: network_and_secret_policy: resource_limits: snapshot_or_workspace_reference: cleanup_owner: recovery_and_completion: process_failure_action: dependency_failure_action: operator_stop_path: delivery_record: effect_receipt_references: reconciliation_record_references: business_acceptance_reference: unresolved_items: ``` ### Contract invariants The template becomes useful when its transitions are testable. At minimum: 1. A run cannot enter `completed` while required approvals or external effects are unresolved. Run completion does not create business acceptance. 2. Every retry refers to the same logical effect and records why replay is safe or why reconciliation is required. 3. A worker loss leaves a durable last transition and a named owner for any in-flight effect. 4. A resumed run verifies workflow, policy, authority, sandbox and context versions before continuing. 5. Cancellation records whether work stopped before an effect, after an effect or in an unknown state. 6. Compensation is a declared domain operation, not an assumption that every external action can be undone. 7. Sandbox expiry, restore failure or cleanup failure is visible in the run state and cost record. 8. Acceptance is separate from process completion. A process can finish and still require review or correction; an unresolved external effect must remain in reconciliation rather than `completed`. The material procurement question is which fields a vendor persists, which transitions it guarantees, how it exports them and where the application must supply the effect record. A generic claim of durable execution does not answer those questions. ## How the runtime categories separate The contract makes runtime routes comparable without reducing them to feature checklists. The report's [production path](/guides/hitchhikers-guide-agentic-economy-2026#section-how-infrastructure-enters-production) moves from supervised read to approved effect, unattended durability and remote delegation. High-consequence work can require the entire control path before its first live action. | Question | Evidence to request or run | Stop condition | | --- | --- | --- | | Can a run survive process and worker loss? | Kill a worker at each checkpoint and inspect the resumed transition history | The run disappears, skips a committed step or replays an unclassified effect | | Can a retry be safe? | Repeat a timed-out operation with the same logical effect key | The destination creates a duplicate or cannot report status | | Can a person wait? | Pause for an approval, let the worker and host restart, then resume or expire the approval | Approval scope is lost, widened or silently accepted after expiry | | Can cancellation be trusted? | Cancel during model work, sandbox work and an external call; inspect process and effect state | Work continues without evidence, or the effect state is unknown and the run closes | | Can the route be inspected? | Reconstruct one completed and one failed run from transition, checkpoint, tool, receipt and acceptance records | Operators need provider support to answer basic state questions | | Can the route exit? | Export state, effect records, context references and evidence; replay a bounded run on another route | Export loses meaning, authority, receipts or enough history to reconcile | The smallest route that passes these tests may be a framework-native checkpointer for low-consequence work, a separate durable engine for long-running or high-consequence work, or a combination. The job, rather than the vendor category, determines the route. ## What the market has not resolved The market has not settled where durable state should live. Frameworks, model platforms, workflow engines and application databases can each claim part of the run. The harder question is which system owns recovery when a model call, worker, sandbox or external service fails between checkpoints. This unresolved seam is driving vendors towards the same territory: persistent run state, human approval, retry control, traceability and operator intervention. We expect consolidation around managed control planes, but not a single runtime standard. Applications will continue to combine specialised orchestration, workflow and sandbox products where the job crosses several systems. ## Where we see the market going Runtimes are moving from framework convenience towards durable operating control. Graph libraries, managed runtimes, workflow engines and sandboxes will coexist because they own different failure boundaries, but the market will increasingly judge them on recovery, effect reconciliation and cost per accepted job. The most valuable control plane will be the one that can establish what the outside world did after a timeout or worker loss. Checkpoints without effect receipts remain incomplete. Portable state plus portable evidence will determine whether managed runtimes become infrastructure or lock-in. ## Unresolved market questions The thesis in this chapter is deliberately testable. **The controlled execution path would be less important than framework choice if** comparable production evidence showed that most valuable agent jobs are short, reversible request-response interactions; process loss and retries rarely create duplicate or unknown effects; and switching frameworks requires little revalidation because the surrounding application already owns all material state. **The double-durability seam would be overstated if** external systems commonly provided a transactional handoff, portable receipt and status query that let an orchestrator prove effect state across failures without an application-level intent or idempotency record. **Sandbox separation would not justify its cost if** controlled process-level execution produced the same incident severity, recovery time, accepted-job rate and total cost, while sandbox isolation added no meaningful reduction in blast radius. **Managed runtime differentiation would be weak if** buyers could export state, effect evidence, approvals, context references and recovery semantics between providers without material rework, and support or operational outcomes did not differ. **Adoption would be established only when** providers or independent users publish a comparable population of runs with workload definition, failure protocol, accepted outcomes, recovery data and cost. Documentation, integrations, public logos and synthetic jobs remain useful supply signals, but they are not that evidence. ## Summary Durable agent work is a controlled execution path. The useful unit is a run that can be accepted, paused, resumed, retried safely, inspected after process failure, cancelled with evidence and closed only after the external effect and business acceptance are known. The market supplies graph frameworks, agent runners, managed runtimes, durable workflow engines and sandboxes. They solve different parts of the path and can be combined. The decisive design is the seam between orchestration durability and effect durability. A checkpoint preserves what the run knows. An intent, idempotency key, receipt and reconciliation record preserve what the outside world may have done. The [Agent Run Contract](#section-an-agent-run-contract) makes that seam purchasable and testable. It asks every provider and buyer to name the state, checkpoint, retry, approval, isolation, recovery, completion and evidence boundary. That is a more durable decision than choosing a framework by catalogue size. ## Limitations - This is a dated documentation-led market snapshot, not an independent benchmark or a survey of customer deployments. - Provider terms, prices, quotas, product names, preview labels and runtime limits may change after 13 September 2026. - The named providers expose different abstractions, so a feature with the same name may have different persistence, retry and failure semantics. - Public sources rarely expose comparable production denominators for accepted jobs, duplicate effects, reconciliation time or total cost. - Sandbox isolation claims are recorded as provider documentation; this chapter does not independently test escape resistance, regional handling or incident response. - Domain-specific compensation, records retention, privacy, identity and service-authority decisions remain with the accountable organisation and the adjacent chapters' boundaries. ## About the author and editorial record Agentic Economy is the accountable publisher of this report. Joel Chan founded the publication in Perth to research the infrastructure, companies and operating choices shaping the agentic economy in Australia and globally. This chapter is source-led market analysis, not a sponsored ranking or a claim that every listed product has been independently tested. Previous: [context, memory and data](/guides/ai-agent-context-memory-data) · Next: [tools, browsers and service access](/guides/tools-browsers-and-service-access).