An always-on AI agent can look like a process that is constantly thinking. In a reliable system, the model usually runs for a short task, saves what the next run needs, and goes idle until another event arrives. The continuity comes from durable storage and predictable handoffs, not from keeping one conversation or server process alive forever.
Anthropic’s November 13, 2026 guide, Building always-on agents, lays out five building blocks: an event inbox, timers, memory, permissions and an outbox. Those are the vendor’s recommended primitives, not a standard every product must adopt. The useful design question is which responsibilities your application must make durable when a run is interrupted, retried or waiting for a person.
First decide whether the task needs an agent
If the job is a fixed sequence—send a report every Friday, resize an uploaded image, or remind someone at a chosen time—a scheduled function or ordinary workflow may be easier to test and operate. Use a model when the work needs interpretation or flexible decisions that are hard to enumerate in code. Anthropic’s broader agent guidance makes the same case for starting with the simplest system that meets the need; an autonomous loop adds latency, cost and the chance that small errors compound.
Put incoming work in a durable inbox
Do not make a webhook call the model directly and hope the request stays alive until the job finishes. Let the handler authenticate the sender, validate the basic envelope, write the event to durable storage, and acknowledge it quickly. A worker can then claim pending work and start a run. A minimal event record might keep a unique source event ID, account or project ID, arrival time, event type, payload reference and processing status.
The inbox is the record of what still needs attention. If a worker stops after starting a task, another worker can see that the event was not completed and retry it. Give claims a lease or timeout so a crashed worker does not hold the event forever. Use a unique constraint or idempotency key to reject duplicate deliveries, and make the resulting action safe to retry too: deduplicating the event does not prevent a duplicate email or database write if the worker already performed that side effect before it crashed.
Decide which events may run concurrently. Two independent projects can often proceed in parallel; two events changing the same account balance, task or conversation may need serialization. Keep raw event text as untrusted input. A message, issue comment or webhook payload can contain instructions, but it cannot grant new permissions or override the agent’s policy. Fetch authoritative state through the appropriate tool and apply the same server-side access checks as any other request.
Represent schedules as data, then turn them into events
A follow-up and a recurring schedule are related but different. A follow-up is a one-time deadline; a schedule repeats according to a rule. Store timers separately from the ready inbox so a future reminder does not look like work that should run now. A timer can include its owner, due time, recurrence rule, time zone, next-fire value and active or completed state.
A scheduler finds due timers and enqueues an event. For a recurring schedule, updating the next due time and creating the event should be coordinated so a retry cannot fire the same occurrence twice or silently skip it. Include the occurrence’s stable ID in the event’s idempotency key. Use an explicit time zone for user-facing schedules and decide what happens around daylight-saving changes, missed runs and a scheduler outage. The model should not be responsible for staying awake and polling a clock.
Separate the session from memory and source records
A session is the transcript and tool activity for one piece of work. Memory is the selected context a later run should see. Neither should become the only copy of important product data: an order belongs in the order system, a task in the task tracker and an authorization in the access-control layer. Save a reference to those records instead of copying their entire contents into a memory file.
Keep memory small enough to review and useful enough to retrieve. Separate durable user instructions from observations learned during a task. For a remembered fact, record where it came from, when it was observed and whether it can expire; stale preferences and temporary project details should not silently become permanent truth. Avoid storing credentials, payment details or private data merely because they appeared in a conversation. Apply access controls and retention rules to memory just as you would to other stored user data.
Anthropic describes file-based memory for some of its own tools and recommends durable storage for agents that outlive a worker. That is an implementation example, not a requirement to use files. A database, object store or existing product record may fit better. The important property is that the next run can retrieve the right context without treating the previous model transcript as an infallible source of truth.
Make permissions enforceable outside the prompt
An agent prompt can explain what it should do; it cannot, by itself, restrict what a credential or tool will allow. Give each worker only the tools and records it needs. Keep long-lived credentials outside the model context, and have a trusted service attach narrowly scoped access when a request is allowed. Check ownership and authorization at the tool boundary, not only in the agent’s instructions.
Define which actions may happen automatically and which must wait for approval. A request to draft a reply may be low risk; sending it to customers, changing access or making a purchase can be consequential. For a gated action, save the proposed action and the facts the person needs to review. The run can end in a waiting state; the person’s answer returns as a new event that resumes the task. Anthropic documents deferred tool calls in Claude Code as one example of that pattern, while the exact approval interface and thresholds belong to the product you are building.
Deliver from an outbox, not from an unfinished run
The outbox keeps a proposed message separate from its delivery. A run can record a message with a destination, content reference, stable ID and pending status; a dispatcher sends it and marks the result. If the process crashes after delivery but before recording success, the dispatcher may retry. Use the channel’s idempotency feature when available, or make the delivery record and follow-up behavior explicit so a retry does not surprise the user with repeated messages.
Keep operational notices separate from approval requests and final results. Batch updates when several events arrive together, give users a way to pause or change a schedule, and measure whether the agent sends too much or too little. Anthropic recommends starting quietly; a system that wakes on every small event can turn a useful assistant into a notification stream.
Test the interruptions, not just the happy path
- Deliver the same event twice and confirm the final action occurs once.
- Stop a worker after it performs an action but before it marks the event complete; then test the retry.
- Send two events for the same record and confirm ordering or conflict handling.
- Delay a timer, cross a daylight-saving boundary and simulate a scheduler restart.
- Decline or ignore an approval request and verify that the gated action does not run.
- Make message delivery fail, recover and check that no duplicate or misleading success notice appears.
- Change or remove a remembered fact and verify that future runs use the current source record.
Trace each run with a stable run ID and link it to the triggering event, memory references, tool decisions, approval state and final outcome. Do not put secrets or full private payloads in ordinary logs. Evaluate whether tasks finish correctly, whether unsafe actions are blocked, whether retries recover, and whether notifications are useful. A model score alone cannot tell you whether a queue lost an event or a dispatcher sent the same message twice.
Start with the smallest durable loop
A practical first version can be modest: one authenticated event handler, one durable queue, one worker, one store for task state and a clear boundary for approvals. Add recurring timers, curated memory and a separate outbox when the product actually needs them. For an app with followers, for example, a release event might prompt an agent to prepare an update; the app’s owner should still control whether that update is published or sent to followers.
That separation is useful for makers building software people can return to. The agent can interpret new events and prepare work, while the application remains responsible for records, access, delivery and the visible choices a person can make. If an AI coding agent is changing the app itself, pair this architecture guide with a recoverable project workflow before granting it broad access.
How to protect your app when using an AI coding agent
Share an app people can follow on VIBPS
Source: Anthropic: Building always-on agents (November 13, 2026)
Source: Anthropic: Building effective agents (start with the simplest useful system)
Source: Claude Code documentation: How Claude remembers your project
Source: Claude Code documentation: Securely deploying AI agents