Agent Runtimes | AI Wars of 2026
State, tools, and recovery. Source-backed analysis from AI Wars of 2026.
Part III — Technologies That Turn AI Into Action
Agent Runtimes
An agent that works across several tools needs more than a model response. Something must preserve progress, assign the next step, and decide what happens when a dependency fails.
Big Idea
A runtime carries work across tools and time. Its value depends on how it handles interrupted work, failed dependencies, and decisions that still belong to people.
The examples below establish specific mechanisms and limitations. They do not yet provide a matched comparison of repeated workflow use, so this chapter remains in research.
Resume from completed work
AWS's integration of Lambda durable functions with Pydantic AI makes model and tool calls durable execution steps. AWS says an interrupted agent can resume from the last completed step without the developer writing the checkpoint and retry logic. The integration is available where Lambda durable functions is available. Source 1
This addresses a concrete problem: restarting a workflow can repeat costly model work or an external action. The announcement describes the offered mechanism; it does not establish exactly-once effects in every connected service or a measured production failure rate. The task, external service, and point of interruption still matter when testing recovery.
Coordinate models without confusing the benchmark with the workflow
GitHub's HydraFusion explores multi-model orchestration rather than relying on a single model for every step. Its reported results support the case for studying the coordinating system as well as the models it selects. They are not a measurement of developer productivity, and offline results do not establish how the same arrangement performs across ordinary repositories. The competitive implications are discussed in Microsoft. Source 2
Follow the dependencies when work fails
GitHub's August availability report describes an Actions job-assignment defect that prolonged recovery: runners received jobs that had already been revoked and retried them instead of taking valid work. Copilot coding agent and code review were among the affected dependent services. This was an infrastructure failure affecting agents, not evidence that an agent chose an incorrect tool action. Source 3
The report also distinguishes delayed task-status updates from failed execution: in another incident, cloud agent tasks continued to run and complete while their displayed status lagged. A runtime therefore needs both execution recovery and an accurate account of progress. A stale status can mislead an operator even when the underlying work succeeds. Source 3
Change the runtime in small steps
GitHub describes migrating the Copilot agent runtime from TypeScript to Rust component by component while the product continued to receive other changes. Ported components were released incrementally, and existing end-to-end tests were used to check the replacements. The account describes agents performing much of the translation while engineers retained architectural choices and final merge decisions. Source 4
The migration also produced regressions that required diagnosis and repair. The case illustrates a supervised way to change a runtime; it does not establish that incremental migration prevents regressions or that agent-written code is more reliable. It is a first-party engineering account, not an independent comparison of productivity, reliability, or total cost. Source 4
Keep human review inside the application
OpenAI's Fyxer customer story describes specialist tasks, task-specific evaluations, and feedback from users' edits to generated email drafts. This is a concrete application design. Accepting a draft unchanged is not an independent check of its correctness, and the story does not establish a comparable productivity result. Source 5
freee describes a different division of work in accounting: people confirm or correct initial rule proposals, the system reuses approved rules, and exceptions or important decisions return to people. Agent Hub connects through non-public freee APIs. These are vendor-described mechanisms, not independently measured evidence that every exception is detected or that the arrangement transfers to other accounting systems. Source 6
Both cases locate review in the workflow itself. What needs checking differs: an email draft, a reusable accounting rule, and an exception decision are not interchangeable units of human oversight. The limits of permission and intervention are examined in Controlled Action.
The counterargument
Durable execution, queues, retries, and review steps existed before agents. Their presence does not by itself establish a new platform advantage. The competitive question is whether a runtime makes a defined workflow more useful or dependable than the available alternatives, including a simpler automation without an agent.
What remains unanswered
A meaningful comparison needs repeated tasks, failure conditions, intervention rates, and recovery outcomes. It should record whether external actions were duplicated, whether operators could see the true state, and whether completed work met its requirements. These examples supply reasons to test those properties, not a ranking of runtimes.
Sources
Source references
Source 1: AWS Lambda durable functions integrates with Pydantic AI
Amazon Web Services
Published: 2026-09-10
AWS Lambda durable functions gains an integration with Pydantic AI, an open-source Python agent framework. Each model call and tool call becomes a durable execution step, so an agent interrupted by a timeout resumes from the last completed step rather than restarting, without the developer writing checkpoint and retry logic. AWS states two motivations: avoiding repeated payment for token work already done, such as a chain of model calls across many documents, and avoiding repeated side effects such as billing a customer twice. Available in all regions where Lambda durable functions is available. This is a product availability record and establishes that the capability is offered; it establishes no adoption, reliability outcome or production use.
Source 2: Project HydraFusion: Frontier quality via multi-model orchestration
GitHub
Published: 2026-09-04
GitHub's announcement of a research preview that performs runtime orchestration across models from multiple providers using Single, Cascade, and Critique execution patterns, available through an experimental flag in GitHub Copilot CLI. GitHub reports that on TerminalBench 2.1 it improved verified task quality by 4.9 percentage points at 67% lower estimated cost than Claude Opus 5. The results are vendor-run, offline, and cost-estimated rather than measured; a research preview behind an experimental flag is not evidence of production use or adoption.
Source 3: GitHub availability report: August 2026
GitHub
Published: 2026-09-09
GitHub's monthly availability report for August 2026, covering five incidents. In the 6 August Actions incident, lasting 10 hours and 42 minutes, at least 74 organizations saw workflows fail or queue; recovery was prolonged by a latent job-assignment defect that handed runners jobs already revoked, which they retried instead of picking up valid work. Copilot coding agent and Copilot code review were among the dependent services affected. In the 20 August incident, at least 54 organizations saw Copilot cloud agent task status lag by up to 60 to 90 minutes while the underlying agent tasks continued to run and complete. Organization counts are GitHub's own, measured against each organization's normal baseline, and are stated as minimums rather than totals. The report establishes operational reliability of agent-dependent services on the dates shown; it establishes no adoption, productivity or workflow-outcome measure.
Source 4: Migrating the GitHub Copilot runtime to Rust, using Copilot
GitHub
Published: 2026-09-16
GitHub describes a supervised, incremental migration of the Copilot agent runtime to Rust. Its account includes an agent applying a compatibility exception after deleting an SDK method and an engineer requiring the method's restoration before merge. This is a first-party account of a caught regression and human oversight, not independent productivity evidence, a general reliability measure, or a complete realized-ROI comparison.
Source 5: How Fyxer built an AI executive assistant people trust
OpenAI
Published: 2026-09-14
OpenAI's customer story describes Fyxer's specialist tasks, task-specific evaluation, and feedback from users' edits to email drafts. Its acceptance and retention figures are company-reported and lack the cohort and observation details needed for an independent comparison. The architecture is evidence of a described application, not proof that accepted drafts are correct or that productivity improved.
Source 6: freee、「freee顧問先管理 | AIエージェント」と「freee Agent Hub」の正式提供を開始
freee via PR TIMES
Published: 2026-09-15
freee's September 15 release describes human confirmation and correction of proposed accounting rules, reuse of approved rules, and return of exceptions and important decisions to people. Agent Hub connects through non-public freee APIs. Named customer examples include automation and time-saving claims, but the release does not supply independent reproduction, an error-rate denominator, or a complete realized-ROI calculation.