The Production Gap: 5 Patterns for Building Long-Running AI Agents

Addy Osmani and Shubham Saboo (Google Cloud), published in Turing Post · email · 2026-05-22 source ↗ Reader 🖥️

Agent Governance (Internal)Agent Memory Agent-to-Agent Protocols Human-in-the-Loop Long-Running & Managed Agents MCP (Model Context Protocol)Multi-Agent Orchestration

To survive contact with real production workloads, AI agents must be redesigned as long-running, stateful server processes — using checkpoint-and-resume, in-place delegated approval, governed multi-layer memory, ambient event-driven processing, and fleet orchestration with A2A/MCP interoperability — because most current agent architectures are 'secretly stateless' and silently reconstruct context from scratch on every turn.

practical · argumentative — A practical/prescriptive guest post: it argues for adopting five architectural patterns when building production agents whose work spans days. The piece is also clearly a sponsored articulation of the Google Cloud Agent Runtime / Gemini Enterprise Agent Platform product narrative — its prescriptions are framework-tinged even when the patterns themselves are platform-neutral.

Structure

Part	Role
Framing / 'the production gap'	Diagnosis — establishes the problem that demos hide and that production work (multi-day insurance claims, week-long sales sequences, financial reconciliation) exposes: agents reconstruct context per interaction and lose reasoning chain, soft signals, and confidence gradients.
Vendor anchor	Context — announces Google Cloud Agent Runtime support for long-running agents up to seven days. Frames the patterns as 'what we've seen work in production.'
Pattern 1: Checkpoint-and-Resume	Sub-thesis + evidence — argues for treating agents as long-running server processes that checkpoint progress at calibrated granularity; supported by a google.adk code example (DocumentProcessor checkpointing every 50 docs).
Pattern 2: Delegated Approval (Human-in-the-Loop, Done Right)	Sub-thesis + critique — argues that JSON-serialized webhook HITL is broken because it loses implicit reasoning context; instead the agent should pause in place, retain full execution state, consume zero compute while waiting, resume on sub-second cold start.
Pattern 3: Memory-Layered Context (and Why You Have to Govern It)	Sub-thesis + risk argument — distinguishes long-term knowledge-base memory from working memory and introduces the failure mode of 'memory drift'; argues for three governance mechanisms (agent identity, centralized registry, boundary-enforced policy).
Pattern 4: Ambient Processing	Sub-thesis + examples — argues for event-driven, human-free agents (Pub/Sub content moderation, BigQuery data quality, support-ticket triage) and adds an architectural rule: externalize policies into the governance layer instead of hardcoding into agents.
Pattern 5: Fleet Orchestration	Sub-thesis — argues for a coordinator/worker decomposition (sales prospecting example: research, scoring, sequencing, outreach, follow-up), declaratively expressed as graph-based workflows so the structure is enforced by the framework rather than by an LLM-followed system prompt.
A2A and MCP: The Interoperability Layer	Bridge argument — patterns alone are insufficient because organizations consume agents built by other teams/companies; A2A standardizes agent-to-agent comms, MCP standardizes agent-to-tool/data comms; agent cards + registry enable discovery without bespoke integration.
How to choose / closing	Decision rule + prediction — diagnostic question: 'what is the longest uninterrupted unit of work your agent needs to perform?'; closes with a competitive-advantage claim that companies building stateless agents will be refactoring in 12 months.
Vendor CTA	Disclosure — explicitly a guest post sponsored by Google Cloud promoting the Gemini Enterprise Agent Platform.

Key terms

Production gap Long-Running & Managed Agents
The chasm between agent demos (short, clean, single-turn tasks) and real workloads (multi-day, partial-failure, human-paced) that most tutorials never address.
Long-running agent Long-Running & Managed Agents
An agent whose unit of work spans hours to days (Google Cloud Agent Runtime supports up to seven days) and which maintains durable state across that span — not just session state.
Stateless (as in 'secretly stateless') Long-Running & Managed Agents
Agent architectures that reconstruct context from scratch on every interaction, losing reasoning chain, soft signals, and confidence gradients — even when developers believe they are stateful.
Checkpoint-and-resume Long-Running & Managed Agents
Persisting agent progress (last_processed index, partial results, timestamp) at calibrated intervals so a crash or restart does not lose work.
Pause in place Human-in-the-Loop
When awaiting human approval, the agent retains its full live execution state (reasoning chain, working memory, tool call history, pending action) and consumes zero compute while waiting; sub-second cold start on resume.
Memory drift Agent Memory
When an agent's accumulated experience (long-term memory writes) silently changes its behavior over time — e.g., generalizing from a few atypical interactions, or leaking data between workflows via shared memory pools.
Working memory vs. long-term memory Agent Memory
Working memory = low-latency, high-accuracy, session-scoped details needed right now. Long-term memory = knowledge-base-like accumulation across sessions, organized by topic. Author insists they be kept distinct.
Governance layer Agent Governance (Internal)
A boundary service sitting between agents and their memory/tools, evaluating every access request against organizational policies (block PII writes before they happen, not audit after). Includes agent identity (cryptographic IAM), a centralized registry of active agents and versions, and policy enforcement at the boundary.
Ambient processing Long-Running & Managed Agents
Agents that watch event streams (Pub/Sub, BigQuery rows, support tickets) and act in the background without user prompting — content moderation, anomaly detection, classification/routing.
Fleet orchestration Multi-Agent Orchestration
Managing multiple long-running agents as a coordinated whole: a coordinator agent decomposes work to specialists (research/scoring/sequencing/outreach/follow-up), each independently versioned with its own identity, tool permissions, and registry entry.
Graph-based declarative workflow
Coordination logic expressed as a declarative graph that the framework enforces, rather than as a system prompt that the LLM might decide to shortcut.
Agent card Agent-to-Agent Protocols
An A2A-standardized self-description published at a well-known URL: capabilities, auth requirements, rate limits. 'Like OpenAPI for agent-to-agent.'
A2A (Agent-to-Agent) Agent-to-Agent Protocols
Open protocol standardizing how agents communicate with other agents, including cards and a discovery registry.
MCP (Model Context Protocol) MCP (Model Context Protocol)
Open protocol standardizing how agents communicate with tools and data sources — a Stripe connector and a BigQuery connector look identical to the agent.
Time accounting (dead time vs. productive time)
In HITL pauses, the wall-clock gap between agent and reviewer is dead time for the agent but productive time for the human; the agent does not drift, degrade, or need re-priming.

Propositions

explicitMost agent architectures are 'secretly stateless' — they reconstruct context from scratch every turn, losing reasoning chain, soft signals, and confidence gradients.conf: high
explicitcorroboratedThe production gap is the gap between what demos can show (short, single-turn tasks) and what real workflows require (multi-day, partial-failure-tolerant operations).conf: high
supports ←Presentation: From AI Agent Demo to Production: Automated Testing and Evaluation · p4 — Zhou Yu's account of why manual chat-testing fails to catch real production behavior is a concrete instance of the general 'production gap' between what demos show and what real workflows require.
extends ←Podcast: Strands Agents with Clare Liguori · p7 — Names a concrete mechanism for the demo-vs-real-workflow production gap (eval sets tuned to imagined 'what is X' queries vs. actual 'how do I' queries) and prescribes continuous live-traffic evaluation as the fix.
explicitestablishedAgents should be modeled as long-running server processes, not request handlers — borrowing patterns from data pipelines: checkpoint progress, handle partial failures, ensure idempotency.conf: high
supportsJobRunr Introduces ClawRunr, an Open-Source Java AI Agent · p2 — Generalizes ClawRunr's JobRunr-as-substrate design into a pattern: agents as long-running processes borrowing checkpointing, partial-failure handling, and idempotency from job infrastructure.
extendsAnthropic's Designs Three-Agent Harness Supports Long-Running Full-Stack AI Development · p4 — Generalizes the structured-handoff-artifact idea into a full data-pipeline discipline: checkpointing, partial-failure handling, and idempotency for long-running agents.
extendsJobRunr Introduces ClawRunr, an Open-Source Java AI Agent · p2 — Generalizes ClawRunr's specific move (reuse a mature job library for durability) into the principle: model agents as long-running server processes borrowing data-pipeline patterns.
extends ←Cloudflare Turns CI Pipelines into TypeScript Workflows · p1 — Applies the same checkpoint/resume, idempotency-constrained durable-process pattern already documented for long-running AI agents to a different domain: CI/CD pipeline execution.
supports ←Podcast: Strands Agents with Clare Liguori · p11 — An independent practitioner account (Strands/AWS) converging on the same prescription -- persist-and-resume state, context management, self-tracking work artifacts -- for hours-long agentic tasks.
supports ←Prompting Claude Fable 5 · p10 — Primary-source vendor confirmation that a frontier model's run lengths (minutes-to-hours) force modeling agents as asynchronous long-running processes rather than blocking request handlers — the central thesis of the long-running-agents piece.
extends ←Article: Implementing Durable Workflows on Postgres Without an External Orchestrator · p4 — Turing Post names checkpoint progress, partial-failure handling, and idempotency as the three required properties of any long-running process; this article gives a concrete Postgres implementation of exactly those three properties for workflows.
explicitCheckpoint granularity is an engineering tradeoff — too frequent is wasteful, too infrequent is risky; the right number depends on the cost of each unit of work (the post uses 50 documents as illustrative).conf: high
explicitStandard webhook-based human-in-the-loop is broken because JSON serialization discards implicit reasoning context and notifications get lost among other alerts.conf: high
explicit⚡ disputed & corroboratedA correctly designed HITL pause keeps the agent's full execution state live and consumes zero compute while waiting; resumption is sub-second.conf: high
supports ←Google's Genkit Ships Agents API with Detached Turns and Human-in-the-Loop for TypeScript and Go · p3 — Genkit's detach()/poll() mechanism is a concrete, shipped instantiation of the turing-post's prescriptive claim that a correctly designed HITL/long-running pause should keep full execution state live server-side while the client is disconnected.
contradicts ←Multi Agent Collaboration Gets Persistent Compute in Bedrock AgentCore · p7 — Turing Post holds up 'zero compute while waiting, sub-second resumption' as the correctly designed pattern for long-running agent pauses. AgentCore runtime instances explicitly do not achieve this by default — they bill continuously at EC2 rates while a session is up, and this article's own cost analysis treats manually stopping sessions when idle as one of only two available cost levers, implying idle instances keep costing money unless a human or process intervenes.
explicitAn organization running 20+ concurrent long-running agents needs a structured, unified inbox ('Needs your input', 'Errors', 'Completed') — not Slack channels or email threads.conf: high
extendsGenie Lessons: Nobody Wants Agents · p2 — Takes Beck's user-side coordination burden as real and prescribes infrastructure for it: a structured unified inbox for fleets of 20+ concurrent agents.
explicitcorroboratedLong-term and working memory must be architecturally distinct stores, not a single memory pool.conf: high
extendsDeveloper Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security · p3 — Answers the newsletter's 'unresolved' cross-session memory question with a concrete prescription: architecturally distinct long-term and working memory stores with governance at the memory boundary.
refinesDeveloper Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security · p3 — Answers the 'cross-session memory is the unresolved question' claim with an architecture: long-term and working memory must be distinct stores, and drift is a managed failure mode.
extends ←Podcast: Strands Agents with Clare Liguori · p12 — Gives a concrete implementation of a distinct long-term memory store (semantic-search database of past successful trajectories) separate from the ledger's single-conversation working memory.
supports ←Paweł Huryn's Post · p1 — Turing Post's principle that 'long-term and working memory must be architecturally distinct stores, not a single memory pool' is exactly what Huryn's four-part taxonomy operationalizes, with two further distinct long-term stores (semantic vs. episodic vs. procedural).
extends ←The oldest architecture in computing · p7 — Turing Post argues long-term and working memory must be architecturally distinct stores; Vogels extends this with a concrete real-world example (Kiro Crew's markdown/vector/key-value split, mirroring the brain's distinct memory types) instantiating the same pattern.
explicitMemory drift is a real production failure mode: agents generalize from atypical interactions or leak data between workflows via shared memory.conf: high
explicitcontestedAgents must be governed the way microservices are governed: cryptographic identity, a centralized registry of active agents and versions, and policy enforcement at the memory/tool boundary.conf: high
contradictsAWS MCP Server Reaches GA with Full API Coverage and IAM-Based Governance · p8 — AWS reduces agent safety to constraining the call surface (not decision-making); Turing insists governance must reach the decision surface via identity, registry, and policy at the tool/memory boundary.
explicitcorroboratedPolicy decisions belong in the governance layer, not in agent code or prompts; otherwise every policy change requires redeploying every agent.conf: high
supports ←The Meter Was Always Running · p12 — Near-identical claim in different words: Turing Post says policy decisions belong in the governance layer, not in agent code or prompts; Haelen says the control plane is where policy decisions live and enforcement/observation are two faces of the same layer that must sit outside anything the agent can edit.
explicitcorroboratedAmbient agents — event-driven, unsupervised — are a distinct class from interactive agents and amplify the cost of hardcoded policy.conf: high
supports ←The AI agent that shows up before you ask · p1 — Viktor's unprompted check-ins are a concrete, anecdotal instance of the 'ambient, event-driven agent' class that piece describes architecturally — though this piece supplies none of the underlying trigger/state mechanics.
explicitcorroboratedCoordination logic should be expressed as a declarative graph enforced by the framework, not as a system prompt that an LLM might shortcut.conf: high
supports ←The Self-Building Agent: A LangChain4j Experiment · p3 — The measured 3x speedup from replacing supervisor coordination (LLM-decided at runtime) with workflow coordination (framework-enforced SequenceAgent/LoopAgent) is a concrete before/after case supporting the claim that declarative, framework-enforced coordination beats LLM-driven coordination expressed in prompts.
explicitEach specialist agent should be independently updatable; a bad deployment in one specialist should not cascade.conf: high
explicitReal leverage comes from agents built by different teams (and companies, in different languages) being able to discover and collaborate — which requires open protocols (A2A and MCP).conf: high
extendsAWS MCP Server Reaches GA with Full API Coverage and IAM-Based Governance · p4 — Generalizes MCP-enables-portability from single-client AWS access to cross-team, cross-company agent discovery and collaboration via open protocols.
explicitCross-organizational collaboration is possible while each organization enforces its own security model independently at the protocol boundary.conf: medium
explicitThe diagnostic question for whether long-running patterns apply is: what is the longest uninterrupted unit of work your agent needs to perform? Hours/days = yes; minutes = no.conf: high
explicitCompanies building stateless agents today will be refactoring in twelve months; companies building stateful, governed, interoperable agents will compound advantage.conf: medium
explicitStatefulness, governance, and interoperability are not optional add-ons but load-bearing infrastructure once agents run for hours-to-days.conf: high
implicitcorroboratedPersistent state implicitly turns agent behavior into a function of accumulated memory, not just code and prompts — meaning behavioral drift is a property of the system, not a bug.conf: high
supports ←The Meter Was Always Running · p4 — Both treat agent state as an accumulating stock that drives behavior, cost, and risk rather than a fixed request payload -- Turing Post frames it as an architecture requirement (checkpoint/resume, distinct memory stores), Haelen as an observability requirement (watch the state grow turn by turn).
refines ←The oldest architecture in computing · p8 — Turing Post frames persistent memory as making behavioral drift 'a property of the system, not a bug'; Vogels reframes the same underlying dynamic positively — proposing active forgetting/decay as the designed countermeasure that keeps accumulated memory from degrading a system, rather than treating drift as an unavoidable cost.
implicitdevelopedThe platform/runtime is now a more decisive engineering choice than the LLM itself — the seven-day persistence and sub-second cold-start claims depend on infrastructure, not the model.conf: high
supportsDeveloper Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security · p7 — Independently asserts the same shift from a Google-stack vantage point: the runtime/harness around the model is now more decisive than the model itself.
extends ←Multi Agent Collaboration Gets Persistent Compute in Bedrock AgentCore · p1 — Turing Post's claim that persistence duration (its example: seven days) is an infrastructure/runtime property, not a model property, is extended by a second concrete vendor data point: AWS's runtime instances offer up to fourteen days, reinforcing that these numbers are competitive runtime-layer specs, not model capabilities.
implicitcontestedCoordination expressed in prompts is unreliable because LLMs will shortcut it — i.e., natural-language orchestration is not durable orchestration.conf: high
contradictsHarness design for long-running application development · p10 — Turing Post argues natural-language orchestration is not durable because LLMs shortcut it, against Anthropic's claim that file-based inter-agent messages are sufficient orchestration (albeit at three-agent vs fleet scale).
implicitAgents are operational artifacts (like microservices) and must inherit operational disciplines (IAM, registry, policy engines, canary deploys), not data-science disciplines (notebooks, evals).conf: high
implicitThe patterns are framework-neutral in principle but the article privileges a specific stack: Google ADK + Agent Runtime + Gemini Enterprise Agent Platform + A2A + MCP.conf: high

Arguments

You must redesign agents as long-running, stateful server processes. strength: high

Explicit premises:

Real workflows (claims, sales sequences, financial reconciliation) span days, not seconds.
Most current architectures reconstruct context every turn and lose reasoning chain, soft signals, and confidence gradients.
When the agent runs for days, that loss is catastrophic — partial failures must be recoverable.

Implicit premises:

Long-running execution actually delivers more value than running many shorter agents serially — i.e., the workflow has irreducibly multi-day character.
Persistent infrastructure (a runtime that can hold state for seven days) is available and economical.

Inferences:

Choice of agent runtime/platform now matters more than choice of LLM for production reliability.
Many production failures attributed to 'the model' are actually failures of stateless architecture.

Human-in-the-loop must be implemented as in-place pause, not webhook-serialized handoff. strength: high

Explicit premises:

JSON serialization loses implicit reasoning context.
Notifications compete with other alerts and get lost.
If the human responds hours later, deserialization plus re-priming risks behavioral drift.
Sub-second cold-start resumes preserve continuity at zero compute cost.

Implicit premises:

The underlying runtime supports zero-cost persistent execution-suspension at scale (cost-of-pause must be essentially zero, otherwise pausing thousands of agents for hours becomes prohibitive).
Humans will not delay so long that the world has changed — the agent's preserved state remains valid on resume.

Inferences:

If preserved state goes stale faster than humans respond, in-place pause loses its advantage and webhook HITL is at least as good.
Reviewer queueing infrastructure ('unified inbox') is a first-class engineering concern, not a UX afterthought.

Memory must be layered and governed at the boundary. strength: high

Explicit premises:

Working memory and long-term memory have different access patterns and SLAs.
Memory drift can change agent behavior silently.
Shared memory pools across agents create data leakage risk.
Boundary policy enforcement can block disallowed writes (e.g., PII) before they happen.

Implicit premises:

The cost of evaluating every memory access against policy is acceptable at production scale.
Drift can be detected and constrained at the access layer, not only in the model — i.e., bad behavior shows up as bad accesses, not just as bad reasoning.
Agents have stable cryptographic identities that survive code/prompt updates.

Inferences:

Memory becomes auditable in a way prompts and LLM outputs are not — governance moves the observability surface from text to access logs.
There is now a missing role: 'agent memory steward' (analog of DBA).

Policies must live in an external governance layer, not in agent code/prompts. strength: high

Explicit premises:

Ambient agents run unsupervised for long stretches.
If policy is hardcoded, every change requires redeploying every agent.
Externalized policy lets the fleet adapt without downtime and without version skew.

Implicit premises:

A central authority can express policies coherently across the fleet (organizationally and technically).
The policy engine itself is reliable enough to be in the hot path of every access.

Inferences:

Policy change becomes a runtime configuration event, akin to a feature flag flip.
Centralized governance becomes a single point of failure and a juicy target — a new attack surface the post does not name.

Multi-agent coordination should be expressed declaratively as a graph, not in prompts. strength: high

Explicit premises:

Prompts can be shortcut by the LLM.
Declarative graphs are enforced by the framework.
Independent updatability of specialists prevents cascade failures.

Implicit premises:

Most production coordination patterns are static enough to be expressed declaratively — i.e., truly emergent multi-agent behavior is rare or undesirable.
The graph framework is itself trustworthy and well-understood.

Inferences:

Agentic 'emergent collaboration' loses ground to engineered, deterministic workflows — the same arc as 'autonomous microservices choreography' giving way to orchestrators.
The line between 'agentic system' and 'workflow engine with LLM nodes' continues to blur.

Open protocols (A2A + MCP) are necessary to capture the value of cross-team and cross-org agent fleets. strength: high

Explicit premises:

Most organizations won't build every agent themselves.
Cross-language, cross-team integration without standards requires bespoke negotiation each time.
Cards + registry give discovery; MCP gives uniform tool/data access.

Implicit premises:

These specific protocols (A2A, MCP) will win adoption — the bet is on standards, not on a particular vendor's mesh.
Card-based capability description is sufficiently expressive for real coordination needs (no hidden semantic mismatches).

Inferences:

If A2A loses to a competing standard, the patterns still hold but the interoperability story has to be rebuilt.
Agent cards become a new attack surface (capability spoofing, rate-limit abuse).

Companies building stateful, governed, interoperable agents will out-compound companies building stateless agents.

Explicit premises:

Stateless agents will hit production walls.
The companies that adopt the five patterns plus A2A/MCP will avoid that wall.

Implicit premises:

The market values multi-day automated workflows enough to reward the investment.
The Google Cloud Agent Runtime / similar runtimes will be available and economical.
Refactoring cost in 12 months will be higher than building it right now — i.e., it's not cheaper to wait for tooling to mature.

Inferences:

Early-mover advantage hinges as much on operational maturity (governance, registry, IAM-for-agents) as on model quality.

Narratives

DocumentProcessor agent that classifies and extracts from a list of documents, checkpointing every 50 docs (last_processed index, partial results, timestamp).
→ Concrete illustration of Pattern 1 — and a normative example that agents should look like data-pipeline code, not like chatbots.
An agent pauses at hour 8 awaiting human review; the reviewer responds at hour 32; 24 hours are dead time for the agent but productive for the human; resume is seamless.
→ Shows how 'pause in place' converts wall-clock latency into zero-cost waiting and reframes HITL as an asynchronous, low-friction handoff.
A content moderation agent reads new uploads from Pub/Sub and routes flagged content to human review; a data quality agent watches BigQuery and delegates remediation via A2A; a customer event agent classifies tickets and routes them to specialist downstream agents.
→ Concrete instantiation of Pattern 4 (ambient processing) and an implicit argument that the Google Cloud event substrate is the natural home for such agents.
Sales prospecting workflow: a coordinator decomposes work into research, scoring, sequencing, outreach, follow-up — each a specialist agent with its own identity, permissions, registry entry.
→ Concrete illustration of Pattern 5; shows how fleet orchestration looks in a recognizable business workflow.
A customer onboarding workflow involves a Python coordinator, a Go identity-verification agent (security team), a Java credit-assessment agent (risk), a Go account-provisioning agent (platform), and a TypeScript communication agent (marketing).
→ Illustrates the cross-team, multi-language end-state of A2A/MCP — and implicitly argues that the value of the protocols is organizational (independent team velocity) at least as much as technical.
Vivid framing of the 'production gap': processing thousands of insurance claims, running week-long sales sequences, reconciling financial data across systems — workflows that take days, not seconds.
→ Establishes the empirical referent the entire piece is responding to and primes the reader to recognize that single-turn agents cannot do this work.

Questions addressed

✅ Why do agents that work fine in demos break in production?
Because production workflows are multi-day and most architectures are secretly stateless — they reconstruct context per turn and lose the reasoning that justified previous decisions.
✅ What architectural patterns make long-running agents viable?
Checkpoint-and-resume, in-place delegated approval, layered+governed memory, ambient processing, and fleet orchestration — composed and joined to A2A/MCP for interoperability.
✅ How do you do human-in-the-loop correctly at multi-day timescales?
Pause the agent in place with full execution state preserved, zero compute, sub-second resume, and route reviews through a structured unified inbox.
✅ How do you keep multi-agent fleets from drifting or leaking data over time?
Treat agents like microservices: cryptographic identity, centralized registry, policy enforcement at the memory/tool boundary, externalized policy.
✅ How do you achieve cross-team, cross-language, cross-org agent collaboration without bespoke integration code?
Adopt A2A (agent-to-agent) and MCP (model-context-protocol) as open standards; publish agent cards; rely on a central registry for discovery; enforce per-organization governance at the protocol boundary.
⭕ How do you size the human reviewer fleet to the agent fleet?
Not addressed beyond 'unified inbox' — see gap below; this is the territory Osmani's 'Orchestration Tax' piece occupies.
⭕ How do you detect memory drift before it produces a visible failure?
The post names the risk and prescribes governance to prevent unauthorized writes, but does not describe drift detection — only access control.
⭕ Who watches the governance layer, and what happens when it fails?
Centralized policy enforcement becomes a single point of failure and a high-value attack surface; the post does not name this.
⭕ When is the seven-day persistence horizon the wrong tool — i.e., when is a workflow better decomposed into shorter, independent agent runs?
Only the inverse question is addressed ('if minutes, you probably don't need long-running agents'); the choice between long-running vs. short-running-with-handoff is not interrogated.

Gaps

incompleteThe implicit failure model is not made explicit. The patterns are pitched as a coherent system but the specific breakdowns they prevent are scattered: context loss after a 4-hour crash (Pattern 1), reasoning-context loss on HITL serialization (Pattern 2), behavioral drift and cross-workflow data leakage (Pattern 3), policy-version skew across an unsupervised fleet (Pattern 4), LLM-shortcutting orchestration logic and cascade-failure deploys (Pattern 5), and bespoke integration tax (A2A/MCP). A reader looking for 'which pattern solves which specific production breakdown' has to reverse-engineer the mapping.
Read next: Read Reed's 'Ironies of A²I²' (Bainbridge revisited) for the failure-modes-of-automation framing the post is implicitly using but never names; pair with Grab's multi-agent engineering-support post for a concrete incident catalog from an actual production deployment.
incompleteHuman throughput is treated as a non-issue. The post mentions 'managing twenty concurrent long-running agents' and a 'unified inbox' but never confronts the reality that the human review queue itself is the binding constraint — the central thesis of Osmani's own 'Orchestration Tax is You' piece. Pattern 2's elegant in-place pause optimizes the agent side of the handoff while the human side scales linearly with agent count.
Read next: Read Osmani's 'Orchestration Tax is You' alongside this article — same author, opposite end of the telescope. Together they expose the gap: 'pause in place' is necessary but not sufficient; without batching, prioritization, and judgement-content sorting, the agent fleet just queues faster in front of the human bottleneck.
incompleteMemory drift is named but not operationally addressed. Governance prevents unauthorized writes; it does not detect agents whose accumulated long-term memory is subtly warping their reasoning. The post stops at IAM-for-memory; it does not propose drift detection, periodic memory audits, or rollback mechanisms — and gives no guidance on memory garbage collection over multi-week timescales.
Read next: Karpathy's 'LLM knowledge bases' extraction (in this library) and Karpathy's 'kb-tool built' piece for the orthogonal view that memory is a tool with editable artifacts, not a black-box store; revisit Bainbridge/Reed for why 'silently changing behavior' is the failure mode automation literature has studied for forty years.
incompleteFramework-neutrality is asserted in form (the patterns) but undermined in substance. The code uses google.adk; the only named runtime is Google Cloud Agent Runtime; the CTA is the Gemini Enterprise Agent Platform; A2A is Google-backed; the seven-day persistence number is a vendor capability claim. A reader trying to implement these patterns on LangGraph, the Anthropic SDK, OpenAI Assistants, Mastra, or a homegrown stack has to translate every prescription — and several (notably 'zero-compute pause' and 'sub-second cold start') are runtime-dependent guarantees, not just design choices.
Read next: Read 'Anthropic's three-agent harness' and 'Anthropic harness design for long-running application development' for how the same problem space looks from the SDK-and-harness perspective rather than the managed-runtime perspective; read 'Block Goose' and 'OpenClaw setup' for OSS-stack equivalents.
uninformedThe centralized governance layer is presented as an unalloyed good. No mention of the centralization risk: a policy engine in the hot path of every memory and tool access is both a high-availability requirement (downtime stalls the entire agent fleet) and a high-value attack surface (compromise = read/write to every memory bank). The post inherits microservices-governance vocabulary without inheriting microservices-governance failure modes.
Read next: Schneier and the supply-chain attack extractions in this library (CNCF Kusari, OpenClaw malicious skills) for the adversarial framing; classic site-reliability literature on policy-engine SPoFs.
incompleteThe diagnostic question ('what is the longest uninterrupted unit of work?') is only directional. It does not help a team decide whether a 6-hour workflow is better as one long-running agent or as four 90-minute agents handing off through a queue. The 'compose-or-decompose' question is the real architectural choice and is unanswered.
Read next: Kniberg's 'Multi-agent workflows' and 'Anthropic harness design' for the decomposition-vs-persistence tradeoff worked out in opposing directions.
illogicalThe competitive-advantage claim — 'companies building stateless agents today will be refactoring in twelve months' — is offered as if self-evident but rests on the very premise the article is selling: that multi-day workflows are the workloads that matter. For organizations whose agentic workloads are genuinely bounded (single-session research, short bursts of tool use), the refactoring prediction does not follow.
Read next: Treat the closing prediction as marketing prose; the diagnostic question two paragraphs earlier is the honest version.

Closes gaps elsewhere

Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security · g3 — Supplies the governance layer the newsletter omits: cryptographic identity, a central agent registry, and policy enforced at the memory/tool boundary rather than as a UX/completion-predicate surface.
Harness design for long-running application development · g5 — Addresses the other kind of long-running the gap flags: multi-day agents interleaving with humans and events, via checkpointed server-process patterns, live-state HITL pauses, distinct memory stores, and naming behavioral/memory drift as a production failure mode (p3, p6, p8, p9, p20).
AWS MCP Server Reaches GA with Full API Coverage and IAM-Based Governance · g1 — Addresses the IAM 'call surface vs decision surface' gap with policy-in-the-governance-layer, declarative coordination graphs, and live-state HITL pauses for consequential actions.
JobRunr Introduces ClawRunr, an Open-Source Java AI Agent · g4 — Provides the agent memory-pattern guidance the gap's reading direction called for: long-term vs working memory as architecturally distinct stores, memory drift as a named failure mode, and policy enforcement at the memory boundary.
Henrik Kniberg's Post · g4 — Supplies the missing multi-agent failure-mode discussion: memory drift and cross-workflow data leakage, LLM-shortcut coordination, and cascade failures from specialist deployments, with mitigations (p9, p13, p14).
AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · g4 — Supplies the missing reliability-engineering treatment for production agents: checkpoint granularity tradeoffs, idempotency, partial-failure handling, and zero-compute resumable human-in-the-loop pauses.

The Production Gap: 5 Patterns for Building Long-Running AI Agents

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Closes gaps elsewhere

Related documents