{
  "id": 3472598,
  "title": "The Missing Runtime for Long-Running AI Agents",
  "url": "https://urgent.news/2026/08/26/the-missing-runtime-for-long-running-ai-agents",
  "topic": "ai",
  "section": "AI",
  "published": "2026-08-26T09:06:32.000Z",
  "source": {
    "name": "DevOps.com",
    "slug": "devops-com",
    "url": "https://devops.com/the-missing-runtime-for-long-running-ai-agents/"
  },
  "original_language": "en",
  "account": "Enterprise AI agents require more than advanced models; they demand resilient execution environments capable of managing multi-step processes, handling failures, pausing for human review, and resuming smoothly after disconnections or delays. While AI agents perform exceptionally well in demos, production systems demand a different set of capabilities. Consider an agent responsible for reviewing a change request, which must access deployment history, assess risk, consult policy, obtain approval from a release manager, and then initiate the rollout. Similarly, an insurance claim adjudication agent would extract relevant information, cross-reference it with historical data, apply underwriting rules, and route exceptions to a human adjuster. Likewise, a security alert triage agent would enrich indicators, correlate them with past incidents, evaluate the criticality of affected assets, and hold containment until an analyst signs off.\n\nThese workflows, despite their differences in domain, share commonalities: they involve multiple steps, involve multiple systems, are subject to independent failure modes, and often require human intervention at some point. They also take minutes or hours to complete, not mere milliseconds. The primary challenge is not just intelligence but execution.\n\nMany discussions around enterprise AI focus on model selection, prompt engineering, retrieval-augmented generation, and tool calling. While these aspects are crucial, they do not address what occurs after the agent begins executing long-running operations across various systems. Most AI applications are still designed as request-response systems, which works well for simple tasks like Q&A, summarization, and content generation. However, enterprise workflows are fundamentally different. For instance, a procurement review agent might parse a contract, compare its terms to a standard template, verify vendor risk ratings, invoke a sanctions screening service, and provide a recommendation. These steps may execute independently, fail independently, and complete at different times. Once an agent transitions from answering a question to executing a process, it begins to resemble a distributed system. It now requires state management, retries, coordination, observability, and recovery mechanisms. Stateless APIs, which are commonly used initially, break down when real workflows are introduced. They cannot manage long-running state, handle timeouts, user disconnections, external system unavailability, or lengthy human approvals. Developers often end up building custom queues, status tables, retry logic, compensation mechanisms, and ad hoc workflow tracking. The hidden cost lies not in the initial prototype but in the operational challenges that arise once the system begins handling genuine workloads.\n\nThe missing piece is a durable runtime—a workflow engine that can preserve progress, coordinate parallel tasks, wait for external events, and reliably resume execution. In a stateless service, progress is held in memory, so a host failure results in lost work, requiring the system to start over from the first step. In contrast, a durable runtime checkpoints each completed activity, allowing a replacement worker to replay the history and continue from the point of interruption. The key design shift is recognizing that the workflow is the application, not just the model. The model is merely one activity within a larger execution graph. In production-grade agentic systems, an orchestrator coordinates the work, while specialized agents handle specific tasks. These agents are domain-specific but often follow a similar pattern: one gathers and enriches raw data, another retrieves reference material, another looks for precedent among prior cases, and another evaluates policy or risk conditions. This design makes the system more manageable. Each agent has a focused responsibility, and the orchestration layer is responsible for execution flow, state management, retries, progress tracking, and handling human interactions. By using a durable orchestrator as the agent runtime, the system can be cleanly separated into two layers: the AI services, which reason about the problem, and the activity functions, which perform the actual work. The durable orchestrator manages sequencing, retries, timers, and external events. Specialized agents run on the model layer with narrowly defined access, while every completed activity is checkpointed so the workflow can be reconstructed after a failure or system restart. Fan-out/fan-in patterns naturally map to multi-agent systems, as many subtasks are independent and can run in parallel. The orchestrator can distribute work to specialized agents, wait for their completion, and then aggregate the results.",
  "summary": "Enterprise AI agents need more than stronger models. They need durable execution environments that can coordinate multi-step workflows, survive failures, pause for human review and resume reliably after disconnects or delays. AI Agents Have Moved Beyond Chat Demos AI agents work beautifully in demos. A user asks a question, a large language model generates a […]",
  "key_points": [
    "Enterprise AI agents need resilient execution environments for multi-step processes.",
    "Durable runtime checkpoints each completed activity to enable workflow continuation after failures."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}