Anthropic's Always-On Agent Architecture: How 24/7 Task Continuity Works

The article analyzes Anthropic's Building always-on agents guide (November 13, 2026) by William Hu, which provides a reference architecture for agents that can continue tasks across multiple execution runs over days.

One Task, Multiple Runs

A run is a single execution; a session preserves messages and tool-call history across runs. The agent spends most of its time idle — "online" means the task can be continuously followed up. Outside the familiar model-tool loop, Anthropic identifies five responsibilities that form the Harness : inbox (event intake), timer (scheduling), memory (cross-run state), permissions (action authorization), and outbox (output delivery).

Queue First, Execute Later

Concurrent events (e.g., test result + user reply) could start overlapping runs and lose messages. The solution is a persistent inbox table , an HTTP endpoint to write events, and a background worker. Events are written, acknowledged, then processed by the worker. Deduplication uses unique event IDs. The guide recommends one inbox per user, one active worker per inbox to serialize state updates. A CI test callback becomes just another inbox event; the worker saves the test task ID, ends the run, and picks up the result later.

Trigger at Time

Timers are persisted separately. A scheduler periodically checks timers, updates them, and writes due events into the inbox. One-time timers are marked fired; recurring timers advance to the next execution time. The model decides whether to follow up and when ; the scheduler only emits events. Reliability: if timer and inbox share a database, use a transaction; otherwise implement retryable delivery with deduplication.

What to Remember for the Next Round

Memory is split into four categories, differing in how the next run reads them:

Behavioral rules (e.g., "confirm before push") — loaded every run.

User preferences & background — loaded directly if small, indexed if large.

Task progress & follow-up plans — read by task ID.

Already communicated content — checked before sending to avoid duplicate notifications.

External system data (test logs, ticket status) should be stored as references and queried live. Progress claims need artifacts and verification: Anthropic's 2025 long-running agent experiment found models declaring completion after unit tests while user flows remained broken. Their harness used feature checklists, progress files, Git records, and end-to-end validation. Memory and work artifacts must outlive the worker process; the guide suggests mapping file directories (like Claude Code's /memories) to a database or object store. The Memory tool is client-side; persistence depends on the application. Per-run load is controlled: behavioral rules always, task records on demand, system prompt and tools minimized with prompt caching. Optional dreaming reviews history to refresh stale memories.

Save Progress When Waiting for Humans

When the agent needs confirmation (e.g., before push), it uses deferred tool calls : save the session and the pending call, present the question, end the run, and resume on reply. The next day's reply enters the inbox, triggers a new run, and restores the session with the pending call context.

In Claude Code, the PreToolUse hook in non-interactive mode ( claude -p) can defer a single tool call; interactive or parallel calls are not supported. Permissions: auto mode uses a classifier to intercept high-risk actions, letting the model try safer alternatives; critical decisions still require user review. Credentials stay outside the agent environment — a proxy injects real tokens. Recovery must verify latest state (branch updates, changed requirements). Event deduplication does not guarantee external operations run once ; pushes need idempotency or result querying.

Notify When Results Ready

A run can end in three ways: send a message , silent end , or defer and ask . Completed fixes send results; no new progress stays silent; uncertainty asks a question. Avoid notification spam. Start with a simple send tool; later introduce an outbox table with a dispatcher for reliable delivery and retry. Confirmation requests can also go through the outbox. Track what has been notified to prevent repeated reports.

What the Harness Leaves Behind

The design shows tasks can wait for tests, time, or humans, but each wait leaves a record and a trigger for the next run. All five responsibilities can live in one application with an existing database — no microservice split required. This clarifies "Harness subtraction": some processes simplify as models improve (e.g., Anthropic dropped phased development after Opus 4.6 moved evaluation to the end), but scheduling, progress persistence, and permission handling remain system duties.

References

William Hu, Building always-on agents , Anthropic, 2026-11-13 (https://claude.com/resources/articles/building-always-on-agents)

Latent Space, Claude Code's Next Era — Thariq Shihipar, Anthropic , 2026-09-29 (https://www.latent.space/p/thariq)

Justin Young, Effective harnesses for long-running agents , Anthropic, 2025-11-26 (https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)

Prithvi Rajasekaran, Harness design for long-running application development , Anthropic, 2026-03-24 (https://www.anthropic.com/research/harness-design-long-running-apps)

Anthropic, Memory tool documentation (https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool)

Claude Code, Hooks reference: Defer a tool call for later (https://code.claude.com/docs/en/hooks#defer-a-tool-call-for-later)

meng shao, Anthropic always-on agent architecture guide discussion , X (https://x.com/shao__meng/status/2121427594260398327)