Loading today’s stories
Product1 distinct publisher3 min readPublished
A devops.com argument worth taking seriously: the hard part of production agents is what happens after step one, and the fix is orchestration engineering, not prompting.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
Start with the arithmetic in the piece's own diagram. A stateless service holds progress in process memory, so a host failure discards the activities that already succeeded and the retry begins at the first step [7]. The work lost to a crash therefore tracks how far the run got: fail at step six and you repeat six, fail at step two and you repeat two [1]. Checkpointing each completed activity, which is what devops.com means by a durable runtime, bounds that loss at roughly one step, because a replacement worker replays the history and continues from where execution stopped [7][8]. For processes measured in minutes and hours rather than milliseconds [3], that is the difference between a workflow that finishes and one that keeps starting over.
The human step is the part you cannot engineer around. The piece's list of what breaks a synchronous agent API runs: the request times out, the user closes the browser, an external system is unavailable, and the approval arrives six hours later [5]. The first three are machine conditions with machine answers. The fourth is a release manager's afternoon, and it is there by design, since each of the three workflows described has at least one point where a person decides [2]. Something that cannot sleep for six hours and wake with its context intact cannot run that shape of work, whatever model sits inside it.
Which makes the most useful sentence in the piece the one about what teams actually build. On stateless APIs, developers end up writing custom queues, status tables, retry logic, compensation logic and ad hoc workflow tracking, and the cost lands in operating the system rather than in the first prototype [6]. Set that against the capabilities attributed to the missing durable runtime: preserve progress, coordinate parallel work, wait for external events, resume reliably [8]. It is the same list [2]. No one decides to write a workflow engine; a team putting agents onto real systems writes one anyway, in fragments, with no owner for the parts that were never named [2].
What follows is a change in where review attention goes. If the workflow is the application and the model is one activity inside a larger execution graph [9], the artifact to argue about in design review is the graph: which activities are idempotent, where the checkpoints sit, what a half-finished run does when a dependency dies. That is the standard set of distributed-systems concerns, which is exactly what the piece says an agent becomes once it executes a process instead of answering a question [11]. The governance argument points the same way. Scoped permissions, observability and auditable evidence are placed inside the workflow [10], which means the audit trail is only as durable as the runtime keeping it.
One caveat, and it is a real one. This is a single argument from a single publisher, and the material carries no measurements: no failure rates, no operating cost, no named engines. It asserts the shape of the problem convincingly and says nothing about its size. Teams evaluating a durable execution layer will have to produce that number themselves, and the honest place to get it is the incident log for whatever stateless agent is already in production.
Ranked by verification strength, evidence, and original report placement.
The piece describes three example agent workflows (assessing a change request, adjudicating an insurance claim, triaging a security alert) which have little in common at the domain level but share a shape: multiple steps, several systems, independent failure modes, and at least one point where a person decides.
Those workflows take minutes or hours, not milliseconds.
Many enterprise AI conversations focus on model selection, prompt engineering, retrieval-augmented generation and tool calling, which do not answer what happens after the agent begins executing long-running work across multiple systems.
The piece lists the questions that break an agent implemented as a synchronous API: what if the HTTP request times out, what if the user closes the browser, what if an external system is unavailable, and what if a human approval arrives six hours later.
Teams on stateless APIs quickly end up building custom queues, status tables, retry logic, compensation logic and ad hoc workflow tracking; the hidden cost is not the first prototype but operating the system after it begins handling real workloads.
In the piece's Figure 1, a stateless service holds progress in process memory, so a host failure discards completed work and the retry begins again from the first step, while a durable runtime checkpoints each completed activity so a replacement worker replays the history and continues from where execution stopped.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Coherent argument, no measurement
A single publisher supplies every claim. The mechanical content is internally consistent and matches well-understood distributed-systems reasoning about checkpointing versus process-memory state, which keeps this above the floor. But nothing is measured: no recovery times, failure rates, cost comparisons, benchmarks, or named production systems, and the illustrative workflows are hypothetical constructions rather than observed cases. The supplied body also terminates mid-section, so part of the argument is unavailable for assessment.
No adoption signal in cluster
The cluster contains no release, deployment, benchmark, pricing, licensing, or usage disclosure. The article names commercial runtimes as a good fit for the pattern, but naming a product is not evidence that anyone adopted this architecture, and inferring adoption from a recommendation would be a guess. No adoption observations were recorded.
Framing runs ahead of the evidence
Positive but moderate. The 'missing runtime' framing, the declaration that the workflow is the application, and the governance prescriptions are stated with more certainty than a zero-measurement, single-source argument earns, and the piece routes its conclusion toward specific commercial products. The gap is held down rather than large because the underlying engineering point — long-running multi-step work needs durable state and recovery — is uncontroversial and the mechanism is stated precisely enough to be tested.
Prescription lands on named vendor products
The argument's structure creates an identifiable interest: after establishing a problem in general terms, it resolves specifically to Azure Durable Functions as 'a strong fit for this pattern' with Azure AI Foundry as the model layer, and no alternative durable-execution runtime is compared or even mentioned in the supplied text. No sponsorship or affiliation disclosure appears in the supplied body, so the direction of incentive is visible while its origin is not established — scored as a clear but unconfirmed vendor alignment rather than a proven conflict.
Moderate-low: one truncated source
Confidence in this assessment is limited by the cluster itself. Publisher emphasis and the claim set are easy to read from the text, so the Perspective and Incentives readings are reasonably firm. But with a single publisher, no adoption data, and a body that ends mid-sentence, the Evidence and Hype Gap scores rest on a narrow and partially unavailable record and would move materially if a second source or any measurement arrived.
product
Agents Are Not Microservices With an LLM Attached, and the Retrofit Never Arrives1 distinct publisher
product
Half the incident clock goes to search, and telemetry tools cannot read the answer1 distinct publisher
product
OpenTelemetry is free; the collector fleet, the retention policy and the on-call rota are not1 distinct publisher
build
Invoked in three runs, executed in none: the cost rule that never got asked1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 26, 2026