Long-Running & Managed Agents

Agents redesigned as durable, stateful, hours-to-days processes — checkpointing, pausing in place, running ambiently — often sold as vendor-managed runtimes.

Also known as: long-running agent, Long-running, long-horizon tasks, managed agents, Claude Managed Agents, background agents, claw, agent runtime, checkpoint-and-resume, stateless (as in 'secretly stateless'), ambient processing, heartbeat, proactive, task lifecycle, production gap, agent view

How authors use it

Oldest first (extraction date when no publication date is known).

AuthorTheir termTheir meaning
Building AI Agents For The Enterprise
Anthropic (vendor-published; Reader recorded the byline as 'Claude') · 2025		Claude Managed Agents'Prebuilt, configurable agent harness available via the Claude Platform' — the execution layer (compute, memory, storage, sandbox) for agents, offered as managed infrastructure so engineering teams don't build it themselves. Cited as what unlocked Rakuten's bi-weekly release cadence.
Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI
No Priors: AI, Machine Learning, Tech, & Startups · 2026-03-20		clawA persistent, autonomous agent system (like Claude) that loops, has memory, runs in its own sandbox, and acts on your behalf even when you are not watching
Harness design for long-running application development
anthropic.com · 2026-03-24		Long-runningMulti-hour autonomous coding sessions (concretely: 3.8 to 6 hours in the case studies) that produce 'rich full-stack applications' end-to-end without human intervention. Not formally defined by a time threshold but operationalized in the examples.
Measuring AI impact, assessing readiness, and new data trends
DX · 2026-04-03		background agentsAutonomous AI agents that work outside the human-in-the-loop workflow -- proactive, asynchronous, handling tasks like dependency upgrades without human prompting
All of AI's New Models and Tools
AI Daily Brief · 2026-04-09		long-horizon tasksAI agent sessions that run autonomously for hours (up to 8 hours), performing hundreds or thousands of tool calls with self-review loops, as opposed to short single-turn interactions.
All of AI's New Models and Tools
AI Daily Brief · 2026-04-09		managed agentsAnthropic's productized infrastructure for deploying AI agents at scale: pre-built harness, sandboxed environment, permission controls, and multi-agent monitoring, sold as a service.
Anatomy of a perfect Openclaw setup
Corey Ganim · 2026-04-10		heartbeatA scheduled polling event where the agent checks if anything needs attention; configured via HEARTBEAT.md.
Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security
Claude Team · 2026-05		Claude Managed AgentsAnthropic-operated agent runtime where Claude handles long-running tasks with managed memory, sandboxing, and network plumbing — i.e. the vendor takes responsibility for the agent's execution substrate, not just the model call.
Developer Newsletter: higher usage limits, dreaming for Claude Managed Agents, and Claude Security
Claude Team · 2026-05		Agent viewA control-plane UI for dispatching and supervising many concurrent Claude Code sessions, with humans pulled in only on demand. Treats the developer as a fleet manager.
The latest AI news we announced in May 2026
The Keyword Team (Google) · 2026-05		ProactiveSoftware that initiates actions in the background without explicit prompting — managing inbox, scheduling, monitoring information, suggesting actions
JobRunr Introduces ClawRunr, an Open-Source Java AI Agent
Diogo Carleto · 2026-05-18		Task lifecycleStates a task moves through (todo, in_progress, completed, awaiting_human_input) with tasks stored as Markdown files under workspace/tasks/
Why Google Isn't Chasing Claude Code
AI Daily Brief · 2026-05-21		managed agentsCloud-hosted, persistent agent runtimes (Spark on Google Cloud VMs; managed agents in Antigravity 2.0) that run independently of the user's device
The Production Gap: 5 Patterns for Building Long-Running AI Agents
Addy Osmani and Shubham Saboo (Google Cloud), published in Turing Post · 2026-05-22		Production gapThe chasm between agent demos (short, clean, single-turn tasks) and real workloads (multi-day, partial-failure, human-paced) that most tutorials never address.
The Production Gap: 5 Patterns for Building Long-Running AI Agents
Addy Osmani and Shubham Saboo (Google Cloud), published in Turing Post · 2026-05-22		Long-running agentAn 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.
The Production Gap: 5 Patterns for Building Long-Running AI Agents
Addy Osmani and Shubham Saboo (Google Cloud), published in Turing Post · 2026-05-22		Stateless (as in 'secretly stateless')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.
The Production Gap: 5 Patterns for Building Long-Running AI Agents
Addy Osmani and Shubham Saboo (Google Cloud), published in Turing Post · 2026-05-22		Checkpoint-and-resumePersisting agent progress (last_processed index, partial results, timestamp) at calibrated intervals so a crash or restart does not lose work.
The Production Gap: 5 Patterns for Building Long-Running AI Agents
Addy Osmani and Shubham Saboo (Google Cloud), published in Turing Post · 2026-05-22		Ambient processingAgents that watch event streams (Pub/Sub, BigQuery rows, support tickets) and act in the background without user prompting — content moderation, anomaly detection, classification/routing.
How building software is changing at Anthropic
The Pragmatic Engineer · 2026-07-28		Claude Managed AgentsAnthropic's pre-built harness product for production agents, runnable on Anthropic-managed cloud infrastructure, a customer's own infrastructure, or with any sandbox the customer chooses — an interface decoupling the agent 'brain,' the sandbox 'hands,' and the event-log 'session.'
The AI agent that shows up before you ask
Ernie Svenson · 2026-09-08		proactiveAn agent that initiates contact and work without being prompted in the moment — it asks whether you did the thing, asks what would move it forward, and offers to do part of it, rather than waiting for a command or firing a static, ignorable reminder.

Documents (33)

Propositions touching this concept (49)

By publication month, oldest first (extraction month when no publication date is known).

2022-08

2025

2025-12

2026-03

2026-04

2026-05

2026-06

2026-07

2026-08

2026-09

2026-10

Tensions

How much of the build pipeline should run with no human reading the code (the 'dark factory')?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: Not simple optimism vs pessimism but a disagreement about preconditions and hidden costs. Ocytko's is a projection of where tooling is heading; Bangser and Verraes both supply reasons the projection is unsafe by default — learning-loss and missing prerequisites. Bangser has the stronger argument that the loss is structural (you cannot buy back organisational learning), which even an improving platform does not address.
How far can day-2 operations be handed to self-healing / autonomous remediation?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: Ruby's report is descriptive (where practice actually stands) and Ocytko's is aspirational (where platforms could go); the gap between 'remediation is withheld' and 'failure modes disappear' is precisely the distance the optimists are projecting across. Bangser supplies the reason the gap may not close on efficiency grounds alone — the withheld human step is also the learning step.
Should the harness/platform-building function be centralised, or emerge per-team?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: A precise split about the organisational form of the scaffolding, not its existence: both want shared architecture guidance, but Edwards-Alexander wants the building capability distributed (friction as feature) while Ocytko wants it concentrated in a platform (constraint as feature). Each concedes the other's pole — Edwards-Alexander keeps a central harness; Ocytko warns against over-constraining — which is why this is a live, unresolved tension rather than a clean contradiction.
Reversibility as a hedge vs a one-way commitment to deeper autonomy.
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: Incompatible risk models. Verraes treats deep AI-dependence as the danger to insure against; Herlein treats not-committing as the existential danger. They cannot both be the rational strategy: reversibility trades some upside for exit options, while flywheel-commitment trades exit options for compounding lead. The tie-breaker is empirical (will access/economics deteriorate?) and neither has evidence — Fowler's 'tokenpocalypse' data leans slightly toward Verraes.
Where is the locus of safety for non-engineers / citizen developers building software?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: Four different answers to the same governance question: the platform (Ocytko), the director's discipline (Ruby), the tooling interface (Bangser), or nobody-knows-yet (Ördög). Ruby and Ocytko are the true opposites — Ruby puts the burden on a human management skill, Ocytko designs the human out by making failure modes disappear in the platform. That both are held by attendees of one retreat is a measure of how unsettled the citizen-developer problem is.
What is the right metaphor for the human-AI relationship in coding?
from: What is the right approach to building harnesses around AI coding agents, and where are the limits?
Assessment: These metaphors are not mutually exclusive but they lead to different design decisions. Garg's teammate metaphor emphasizes collaboration rituals and may underplay the need for hard constraints (you don't sandbox a teammate). Böckeler's governor metaphor is the most theoretically rigorous but may overclaim the applicability of control theory to creative work. Osmani's engineering metaphor is the most actionable but may miss the social and organizational dimensions. Thoughtworks' organizational metaphor captures the broadest scope but is the hardest to operationalize.
Context size: should you shrink the problem to fit a small usable window (decompose / reset), or grow and trust a large window?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: The apparent 'grow / trust the big window' position for CODING largely dissolves once retrieval is separated from coding — which is exactly Pocock's move ('good for retrieval, less good for coding') and musistudio's (longContext is a routed escalation, not the coding default). No text argues you should code inside a full 1M window. The only genuine pressure toward trusting a bigger window is the vendor-forward Fable 5 / Opus 4.6 claim that coherence loss is being engineered away — but that is a moving target (convergence 5), not a stable dial, and even the harness paper only relaxed context resets AFTER measuring that the new model no longer needed them. A secondary, live sub-dispute survives: reset vs compact. Pocock, the harness paper and best-practices favor clearing/resetting to a fresh agent; Hills and Osmani lean on compaction. The reset camp has the better argument on today's models — compaction preserves the same anxious agent — but the disagreement is real and unresolved. Verdict: shrink-and-decompose is the default for coding; grow only as an explicit retrieval escalation; prefer reset over compact unless the model version has demonstrably killed context anxiety.
Effort/reasoning: does more thinking make output better, or does more reasoning make it worse (over-engineering / over-editing)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: This looks like a head-on collision but is really the corpus resolving a category error, so I keep it as a divergence-under-adjudication rather than a live two-camp fight. The two things bundled into one 'effort' dial are separable: reasoning DEPTH (deliberation and research before acting — what stellaraccident measures as the Read:Edit ratio) versus action SCOPE (how much the model rewrites — what nrehiew measures as over-editing). They are separable but DEFAULT-COUPLED: more reasoning, unconstrained, tends to produce more scope. nrehiew is the empirical bridge — constrained reasoning models are the MOST faithful, proving depth and tight scope combine positively when you address them separately. Fable 5 already acts on this, pairing 'reduce effort' with a distinct anti-over-engineering instruction. The actionable verdict: do NOT cut reasoning depth to fix over-editing (that is stellaraccident's exact grievance and it backfires into shallow, edit-first behavior); keep the depth and add an explicit scope constraint. The failure is treating one knob as if it controls both correctness-depth and edit-scope.
Should the harness/platform and its safety be centralized or left distributed across teams?
from: What is the future of software development in the agentic/AI age?
Assessment: A real operating-model split. Edwards-Alexander's distributed stance rests almost entirely on the DevOps-team analogy (his own extraction flags it as asserted-on-intuition, not argued), whereas the platform camp has the stronger concrete case for the citizen-developer safety problem — you cannot distribute production-data guardrails to non-engineers. The tension is partly reconcilable: Ocytko himself concedes a platform tight enough for non-engineers may be too constraining for expert engineers' identity and innovation, which is exactly the freedom Edwards-Alexander is protecting. The unresolved question is whether one platform can be both.
How far should software be automated — toward the fully-autonomous dark/software factory, or held back to bounded autonomy with humans in the loop?
from: What is the future of software development in the agentic/AI age?
Assessment: The spectrum runs from Ördög/Ocytko (full automation is arriving and desirable) to Bangser/Ruby/Verraes (deliberately withhold the last step). The decelerationists have the better of the safety argument today — Ruby's 'nobody will cede the blast radius' and Bangser's 'removing humans removes learning' identify concrete, unmet prerequisites — but Ördög's context-dependence (backends, COBOL) shows the boundary is domain-specific, not absolute. The real disagreement is less about capability than about who absorbs the blast radius when an autonomous fix goes wrong.
Is preserving human understanding of the system a first-order value, or is comprehension safely offloadable so long as output is verifiable?
from: What is the future of software development in the agentic/AI age?
Assessment: The optimist-practitioner vs. skeptic-humanist axis. Fowler and Nilsson treat comprehension and craft as intrinsic goods whose loss is a harm even when output is fine; Herlein and Ocytko treat comprehension as instrumental — replaceable by verification and platform guardrails. The humanist camp has the stronger long-run argument (Fowler's cognitive-debt case and Ocytko's own 'who-guards-the-guards' problem both show verification and guardrails are themselves fallible artifacts that someone must understand), but the offloadable camp is describing what is actually happening at scale. The crux is whether verifiability can ever be robust enough to make understanding optional — which Ruby's own Goodhart gap (a passable oracle diverging from true intent) suggests it cannot fully be.
How should newly-empowered citizen developers be made safe — constrained platform, human stewardship, or supported API-first tooling?
from: What is the future of software development in the agentic/AI age?
Assessment: All three agree citizen developers are inevitable and must not be blocked, but the safety mechanism differs — encode it in a constraining platform (Ocytko), transfer it through human relationships (Laycock), or expose it as consumable interfaces (Bangser). Ocytko's platform-first case is strongest on the specific failure mode both he and Ördög name (non-engineers leaking or bypassing production-data access), which stewardship alone cannot prevent at scale. Laycock's stewardship answers a different problem — sustaining the junior-to-senior pipeline — that a platform does not. The positions are complementary in principle but compete for the same finite investment, and none supplies a concrete governance model for vibe-coded shadow IT.

Open gaps (110)