---
type: "post"
id: "building-always-on-agents-claude-by-anthropic-b69b9f"
slug: "building-always-on-agents-claude-by-anthropic-b69b9f"
title: "Building always-on agents: Claude by Anthropic"
description: "Anthropic published a guide to building agents that sleep between runs, resume from events, and carry state across sessions."
retrieval_nugget: "Anthropic published a guide to building agents that sleep between runs, resume from events, and carry state across sessions. Its five-part architecture—event inbox, timers, memory, permissions, and outbox—turns “always-on” into a durable system design problem, with practical implications for reliability, cost, and user control."
published_at: "2026-11-13"
updated_at: "2026-11-13"
record_date: "2026-11-13"
date_kind: "published_at"
topics: ["anthropic","claude"]
entities: ["Anthropic","Claude Platform","Opus 5.5","Opus 5","William Hu"]
related_patterns: ["agent-security-moves-to-runtime-boundaries"]
novelty_label: "new_fact"
what_changed: "Anthropic’s new guide explains the architecture and core primitives for always-on agents, including how agents manage context across sessions and act proactively."
prior_refs: ["https://newruntime.com/posts/dreaming-with-a-dynamic-workflow-9b7927/","https://newruntime.com/posts/building-effective-agent-automations-claude-dev-blog-55ed08/"]
source_url: "https://claude.com/resources/articles/building-always-on-agents"
source_urls: ["https://claude.com/resources/articles/building-always-on-agents"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:building-always-on-agents-claude-by-anthropic-b69b9f"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/building-always-on-agents-claude-by-anthropic-b69b9f/","markdown":"https://newruntime.com/posts/building-always-on-agents-claude-by-anthropic-b69b9f.md","json":"https://newruntime.com/posts/building-always-on-agents-claude-by-anthropic-b69b9f.json"}
markdown_url: "https://newruntime.com/posts/building-always-on-agents-claude-by-anthropic-b69b9f.md"
---

# Building always-on agents: Claude by Anthropic

## Retrieval answer

Anthropic published a guide to building agents that sleep between runs, resume from events, and carry state across sessions. Its five-part architecture—event inbox, timers, memory, permissions, and outbox—turns “always-on” into a durable system design problem, with practical implications for reliability, cost, and user control.

## Summary
Anthropic published a guide to building agents that sleep between runs, resume from events, and carry state across sessions. Its five-part architecture—event inbox, timers, memory, permissions, and outbox—turns “always-on” into a durable system design problem, with practical implications for reliability, cost, and user control.

## What happened
Anthropic’s Claude Platform guide, written by William Hu and dated November 13, 2026, defines always-on agents as stateful and proactive systems that manage context across sessions and act without direct supervision. The agent is not literally running all the time: it wakes when an event arrives, performs a run within a session, records what happened, and returns to sleep. Anthropic attributes renewed interest in this design to better model judgment and falling intelligence costs. It says Opus 5.5 cost 78% less per solved task than Opus 5 on one long-horizon coding benchmark, versus 40% less on typical workloads.

The first primitive is a durable event inbox. Webhooks, scheduled tasks, and background jobs write events to a list—often a database table—rather than calling the agent directly. A handler accepts the event and a worker reads pending work, starts or resumes a session, and marks events complete. Anthropic recommends tracking status, deduplicating with source identifiers, and keeping one active worker per inbox to avoid duplicated or conflicting runs. The worker should use the inbox as its source of truth so a replacement can retry work after a crash. Pending events can be batched; events that continue earlier work can resume an existing session, while others start new sessions.

Timers make the system proactive. Anthropic distinguishes follow-ups, such as checking on a reply, from recurring schedules, such as a daily newsletter. Timers live in durable storage separate from the inbox. A scheduler polls for due timers, updates or completes them, and adds resulting events to the inbox. The scheduler can be a custom service or a durable execution engine. Memory is also stored separately so it survives workers: Anthropic suggests retaining instructions, user notes, prior messages, and task progress, while keeping only information that cannot simply be looked up elsewhere. Persistent memory may live in a database or object store; a pointer to an issue tracker is preferable to copying information already held there.

Before each run, the agent loads its system prompt, tools, and memory. Anthropic recommends keeping this context overhead lean and using prompt caching to reduce costs. Existing sessions also bring back prior messages and tool calls; if they grow too long, teams can compact older messages or start a new session, while saving anything that must persist in memory. Permissions are the highest-risk primitive because the agent acts unattended with user access. Anthropic recommends a credential proxy that injects secrets outside the agent environment, risk classifiers that block dangerous actions, and human review for important decisions. A deferred tool call can end a run while awaiting approval; the user’s response then returns as an inbox event and resumes the saved session. The guide also identifies an outbox as a core primitive for getting work back to the user.

## What the archive adds
New Runtime’s earlier coverage on November 5, 2026 described a hands-on dynamic-workflow implementation of Managed Agents dreaming, including transcript loading, wiki-style memory updates, and a nightly cron option ([Dreaming with a dynamic workflow](https://newruntime.com/posts/dreaming-with-a-dynamic-workflow-9b7927/)). This guide is a new fact on the broader agent-memory thread: it frames memory as one component in a larger always-on runtime rather than focusing on memory curation alone.

## Trend signal
This guide supports the pattern that agent security is moving to runtime boundaries: unattended runs need durable permissions, credential handling, and approval paths, not only behavioral instructions ([Agent security moves to runtime boundaries](https://newruntime.com/patterns/agent-security-moves-to-runtime-boundaries/)). It also touches the need for governed memory write and correction loops, but its clearest contribution is the runtime security boundary.

## Why now
Anthropic says recent model improvements have made always-on agents more practical: models have better judgment about user intent and when to check in, while intelligence has become cheaper, particularly for long-horizon work. The guide’s benchmark comparison is offered as an example of the cost shift, not as a general guarantee.

## Why it matters
The guide’s useful distinction is between an agent loop and the system that makes repeated runs dependable. Teams need durable event handling so a crash does not erase work, explicit rules for concurrency and retries, and memory that survives workers without loading an entire history into every context window. Those choices affect both operating cost and whether users can trust an agent to continue a task later.

The permission design matters just as much. An unattended agent can hold access that its user is not actively supervising. A proxy can keep credentials out of the agent environment, while risk review and deferred approvals separate routine execution from actions that need a person. These patterns do not prove that an agent is safe, but they give builders concrete boundaries to test. Anthropic’s cost comparison may make long-running tasks more attractive, yet lower model cost does not remove the infrastructure, review, or failure-recovery work. The practical unit is a completed task that can be recovered, inspected, and safely delivered.

## What happens next
- **More agent products will expose durable event, memory, and approval primitives as first-class runtime components.** (6 months, 65%). Watch for: developer platforms documenting persistent sessions and deferred approvals together.

## Limits and uncertainty
Anthropic presents this as a best-practices guide, not a measured evaluation of the complete architecture. The cited 78% and 40% cost reductions are tied to one long-horizon coding benchmark and typical workloads, respectively; the page does not establish that other workloads or teams will see comparable savings. The guide describes recommended components and implementation choices, but those recommendations do not by themselves demonstrate reliability, security, or user acceptance in production. The proxy and classifier patterns also require threat modeling and testing against the specific tools, credentials, and actions an agent can access.

## Skill to build now
Build a minimal durable inbox for one agent workflow this week. Persist each incoming event with a unique source identifier and status; make the handler acknowledge quickly; have a single worker claim pending items and record completion. Then kill the worker mid-run and verify that a replacement can safely retry without losing or duplicating the task. Add session resumption only after that recovery path works.

## Reader takeaway
“Always-on” is a user experience, not a continuously running model. Build the durable event, memory, permission, and delivery systems around the agent loop—and test recovery and approval behavior before giving it unattended access.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Anthropic](https://newruntime.com/topics/anthropic.md): Explore the anthropic topic hub.
- topic hub: [Claude](https://newruntime.com/topics/claude.md): Explore the claude topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)