Updated August 4, 2026. This article was prepared by the AI Dawn editorial team based on a presentation by the Anthropic team and primary technical sources.
An asynchronous AI agent is a system you can delegate a task to and come back later for the result: it preserves state between steps, performs actions in isolated environments, checks results against measurable criteria, and knows when to involve a human. Long autonomy comes not only from a stronger model. It is created by an architecture with an external session, an independent verifier, controlled memory, and strict access permissions.
The main mistake is to take a chat agent, put it together with tools and secrets in one container, and simply allow it to run longer. If the container crashes, the session is lost. If the agent makes a mistake, it may validate its own error. If it writes a false conclusion into memory, that conclusion will start affecting future runs.
In short: a reliable long-lived agent is built on the following pattern
goal → persistent session → isolated action → independent verification → memory update → next step. A human sets the limits, the budget, and the actions that cannot be performed automatically.
Contents
- Why asynchronous agents became possible
- What a long-lived agent consists of
- Principle 1. Separate the “brain” from the “hands”
- Session as an external event log
- Principle 2. Verify in a separate context
- How to set up an executor–verifier loop
- Principle 3. Memory must learn and correct itself
- Why you should not define a rigid memory schema in advance
- Principle 4. The agent becomes a shared organizational layer
- Risks of long autonomous operation
- Minimum production architecture
- How to launch your first asynchronous agent
- FAQ
- Bottom line
Why asynchronous agents became possible
The product interface always follows the model’s capabilities. When a model could do only a short segment of work, autocomplete and chat were a good fit: a person was always nearby, clarifying the request and correcting the direction. As agents learned to work longer, local coding agents appeared. The next step is tasks that run for hours or days without continuous supervision.
This dynamic is often described using the task-completion time horizon. METR defines it as the length of a task for a human expert at which the agent predictably reaches a specified probability of success. It is not the literal amount of continuous model runtime. For example, an “8-hour horizon” does not mean an agent can complete any eight-hour task a specialist could do: METR’s measurement is based mainly on well-defined programming, machine learning, and cybersecurity tasks. The organization itself warns that current estimates above 16 hours are unreliable because of the limitations of the task set. METR methodology
That is why the upward trend in the chart should not be read as a promise of full autonomy. It shows something else: more and more tasks are long enough that a synchronous interface with constant waiting becomes inconvenient. But the shift to async requires assembling several components at once.
| Component | What it provides | What happens without it |
|---|---|---|
| Persistent session | workflow recovery | a process crash destroys progress |
| Isolated execution | control over files, network, and secrets | an error gets too large a blast radius |
| Verifier | an independent quality signal | the agent confirms a plausible but incorrect result |
| Memory | carrying experience across sessions | repeating the same mistakes |
| Permissions and audit | safe operation within an organization | it is unclear who authorized the action and which data was accessed |
What a long-lived agent consists of
It helps to stop thinking of the agent as a single program. In a production system there are at least five parts.
- The model chooses the next step and interprets the result.
- Control loop calls the model, routes tools, and tracks budget and stop conditions.
- Session stores the sequence of prompts, responses, tool calls, and results.
- Execution environments run code, work with files, and access allowed services.
- Secrets and policy store grants the minimum permissions for a specific action.
This decomposition matters more than the choice of a specific LLM. You can replace the model, recreate the container, and strengthen the verification strategy without losing the task history itself.
Principle 1. Separate the “brain” from the “hands”
In a simple prototype, the control process, file system, tools, and secrets are often in one container. That is convenient as long as the agent lives for a few minutes and an engineer is watching the terminal. For multi-hour work, this setup becomes fragile.
Anthropic describes the solution as separating the “brain,” the “hands,” and the session. The control process lives outside the sandbox, the execution environment is called as a tool, and state is stored separately. If the container stops responding, the control layer gets a call error, creates a new environment, and continues from the log. Claude Managed Agents architecture
The separation solves three problems.
Fault tolerance
The session outlives an individual process and an individual container. Recovery depends not on the memory of the running program, but on the recorded event log and saved artifacts.
Security
Secrets do not need to be placed in the environment where the agent executes generated code. It is better to use an intermediary: the agent forms the intent to call a service, the policy checks the action, and the gateway injects credentials only for the duration of the approved request. The official Managed Agents description separately emphasizes storing credentials outside the sandbox. Production architecture overview
Scalability
One control process can call multiple “hands”: separate containers, a browser, an emulator, a data analysis environment, or a service inside a VPC. This does not necessarily mean a multi-agent system. One model can coordinate several isolated executors.
It is important not to copy the product name, but to preserve the contract:
execute(tool_name, input) → structured_result
The control layer should not depend on where the action is physically executed. Then a local container, a cloud function, and an internal company service become interchangeable implementations of one interface.
Session as an external event log
A normal chat history is a temporary context for the next response. A long-lived agent’s session is an append-only log, that is, a log in which events are added without destroying previous entries.
It includes:
- the launch objective and constraints;
- model responses;
- tool calls and their results;
- links to created files;
- the reviewer’s decisions;
- human actions;
- timestamps, cost, and environment identifiers.
Such a log should not be confused with the context window. The model does not have to receive the full history at every step. It can load a short working state and, when needed, refer back to an older fragment.
This idea aligns with Recursive Language Models: long input is treated as an external object that the model programmatically explores and breaks into parts, instead of fitting it all into one prompt. The RLM authors demonstrated handling inputs up to two orders of magnitude larger than the context window on the tasks they studied, although applying the result to a specific production system requires its own testing. Recursive Language Models article
Practical takeaway: compaction should change the working representation, not the original history. A summary can be rebuilt, but the original events must remain available for investigation, recovery, and a new retrieval strategy.
Principle 2. Verify in a separate context
If you ask an agent to create a result and then evaluate itself in the same long session, the review inherits its original assumptions. The model remembers why it chose the solution and tends to explain it rather than attack it.
An independent verifier gets a different dataset:
- the original objective;
- a measurable completion criterion;
- the artifact to be checked;
- access to tests or primary sources;
- a minimal execution history.
It does not have to be a larger model. For code, the best verifier is often a test runner, compiler, or static analyzer. For publishing, it may be an HTTP 200 check, a visible H1, and fact matching against sources. For finance, it is reconciliation with the accounting system. LLMs are needed where the criterion includes semantic judgment, but even then the output should be tied to evidence.
Anthropic described a generator-evaluator scheme for multi-hour application development: separate planner, executor, and evaluator components worked against criteria, and the result was sent back for refinement. Breakdown of the long-horizon development architecture
How to build an executor-verifier loop
The minimal loop looks like this:
BUILD → VERIFY → PASS or REPAIR → BUILD
But the phrase “repeat until success” is dangerous without limits. The loop should have:
| Field | Example |
|---|---|
| Outcome | all tests pass, the file is created, the source is available |
| Rubric | correctness 50%, completeness 30%, format 20% |
| Evidence | exit code, URL, checksum, record from the source system |
| Budget | maximum 6 iterations or $20 |
| Timeout | no more than 90 minutes |
| Escalation | after two identical errors — to a human |
| Stop condition | verifier returned PASS and attached evidence |
In the transcript, this approach is shown with Parameter Golf, an open OpenAI competition to train a compact model. Participants had to minimize held-out loss on a fixed FineWeb dataset while staying within a 16 MB artifact and ten minutes of training on eight H100s. This is a strong kind of task for an autonomous loop: the metric is numeric, the budget is strict, and the run is reproducible. OpenAI says the competition received more than 2,000 submissions from over 1,000 participants and that coding agents were widely used for experiments. Parameter Golf results
The point of the example is not the specific result of one model. What matters is that the control signal is moved into the environment: the agent changes its hypothesis after a real run, not after the subjective request to “think some more.”
Principle 3. Memory must learn and self-correct
It is useful to split an agent’s memory into two processes.
In-band recording happens during the task. The agent records useful commands, user preferences, local errors, intermediate hypotheses, and the next step. This is fast working memory.
Offline consolidation runs later. It reads multiple sessions and the current store, removes duplicates, looks for contradictions, raises the level of abstraction, and flags doubtful conclusions. In Anthropic’s materials, this process is called Dreaming: a scheduled pass analyzes sessions and memory, extracts recurring patterns, and updates stored knowledge. Memory and Dreaming description
Why isn’t one process enough? During operation, a locally useful note may be wrong in the general case. For example, an agent once found a workaround for an API error and saved it as a permanent rule. After the API is updated, the rule gets in the way of every subsequent run. An offline process can compare multiple traces, notice that the fix is outdated, and replace the narrow fact with a more durable principle.
Memory should have provenance and a time to live. A minimum record contains:
- the conclusion itself;
- type: fact, preference, hypothesis, or procedure;
- source or session ID;
- creation date and last verification date;
- scope;
- confidence;
- revision history.
Without these fields, false memory looks just as convincing as confirmed memory.
Why you should not define a rigid memory schema upfront
A file system is not the only option. A database, object storage, or a combination can work. What matters more is that the model can perform simple operations: create an entry, read it, search, link, revise, and archive.
An overly prescriptive schema decides in advance which types of experience will matter. That often leads to losing signals the developer did not anticipate. Stronger models are better at extracting transferable abstractions: not only “command X worked,” but “when this class of error appears, first check the schema version, then repeat the request with a compatible format.”
But freedom of structure does not mean no control. The store still needs:
- size and cost limits;
- memory separation by users and projects;
- a prohibition on saving secrets;
- provenance checks;
- quarantine for unverified conclusions;
- a human’s right to delete or correct a record.
Principle 4. The agent becomes a shared organizational layer
A local agent is usually single-user: it has personal settings, local files, and the permissions of a specific employee. An organizational agent has its own identity, allowed channels, shared context, and an action log.
Claude Tag shows one version of this interface. It runs in Slack, but the point is not the chatbot: one agent is available to multiple people, preserves the context of allowed channels, can act asynchronously, and in ambient mode can surface important open issues on its own. Administrators define data sources, tools, spending limits, and memory scope; actions are tied to the person who assigned the task. Official Claude Tag announcement
This layer gives the company three advantages.
- Shared context. A new employee gets more than an empty assistant — they get access to approved procedures, decisions, and the team’s history.
- Deduplication. The agent can find a similar experiment or an already completed study before spending resources again.
- Proactiveness. The system notices an unresolved issue, a metric change, or a recurring failure and alerts the responsible person.
At the same time, a shared agent should not become shared access to everything. Identities for sales, development, and support are better kept separate, and memory and tools should be limited by purpose.
Risks of long autonomous operation
The longer an agent runs, the more actions it can take before human review. So longer runtime amplifies not only value, but also mistakes.
Prompt injection
An external page, ticket, or README may contain instructions that try to change the agent’s goal. Tool data should be treated as untrusted, network destinations should be checked, and text from the source should not be allowed to expand permissions.
Memory poisoning
One malicious or incorrect result can become a permanent rule. New entries should first be saved as candidates, and important conclusions should be confirmed across multiple sessions or by a human.
Correlated verification
An executor and verifier based on the same model can make the same mistakes. Different contexts, different tools, and external criteria help. Simple voting by multiple agents is not proof.
Unlimited loop
An agent may endlessly improve a metric, repeat one failure, or spend budget on a weak hypothesis. You need limits on attempts, time, tokens, money, and an escalation rule.
Irreversible action
Publishing, payments, data deletion, permission grants, and production changes require a separate gate. For significant actions, preview, approval, idempotency key, and rollback capability are useful.
Minimal production architecture
A first launch does not require a complex platform. Eight components are enough.
| Component | Minimum implementation |
|---|---|
| Intake | task queue with owner and priority |
| Goal | measurable outcome and prohibited actions |
| Session store | append-only events and links to artifacts |
| Orchestrator | model step, tool routing, budgets |
| Sandbox | separate container with restricted network |
| Credential proxy | granting the minimum permission per request |
| Verifier | test or separate context with a rubric |
| Human gate | approval of a risky final action |
The flow can be written like this:
TASK → SESSION → PLAN → SANDBOX ACTION → ARTIFACT → VERIFY → MEMORY → DONE
If verification fails, the result goes back to PLANbut only until the limits are exhausted. If the same error repeats, the task is escalated to a human.
For broader processes, this cycle can be built into a graph with multiple parallel branches. This approach is explained in detail in the article Graph Engineering: How to Build AI Agent Graphs.
How to launch your first asynchronous agent
Step 1. Choose a verifiable task
Choose work with a digital input, limited tools, and a clear output: prepare a data report, fix a test suite, classify tickets, or update documentation. Don’t start with a goal like “improve the business.”
Step 2. Define the outcome
State the condition that can be checked without the model self-evaluating. For example: “a CSV with 12 required columns was created, all rows passed validation, and the total matches the source.”
Step 3. Move the session out of the process
Log events before and after each tool call. Store artifacts separately, and keep links and checksums in the log.
Step 4. Restrict the environment
Block unnecessary network access, connect read-only data, and set CPU, memory, time, and disk limits. Pass secrets through a proxy to specific requests.
Step 5. Add a verifier
Start with deterministic checks. Add an LLM verifier only for semantic criteria, and require a quote, test, or another external signal.
Step 6. Add candidate memory
Let the agent propose entries, but do not turn every note into a permanent rule. Run consolidation on a schedule and keep change history.
Step 7. Run a shadow launch
Let the agent prepare the result, but not take the final action. Compare its outputs with a human on at least 20–30 tasks. This is a recommended range, Estimatednot a universal standard.
Step 8. Gradually expand autonomy
First allow safe read-only actions, then reversible changes, and after that limited operations with confirmation. Keep fully automatic only the actions with a verifiable result and a small blast radius.
FAQ
What is an asynchronous AI agent?
It is an agent that is given a task and then continues working without constant back-and-forth with a human. It stores state, calls tools, checks intermediate results, and returns with a final result or a request for help.
How is an asynchronous agent different from a chatbot?
A chatbot usually responds within one interaction and waits for the next message. An asynchronous agent has a persistent session, can work in the background, survive environment restarts, and perform multiple steps based on readiness conditions.
Why separate the control plane from the execution environment?
So that a container crash does not destroy task history, and secrets are not kept next to the code the agent runs. This separation also makes it possible to connect different environments as tools.
Why shouldn’t an agent evaluate its own work?
The executor tends to preserve its own assumptions. An independent verifier gets the criterion and artifact in a separate context and confirms the result with a test, a primary source, or a record from the source system.
What is better for memory: files or a database?
Both options work. What matters more is simple operations, record provenance, access scope, expiration, and the ability to revisit an incorrect conclusion. A rigid schema defined in advance for all future tasks can prevent the model from preserving new useful abstractions.
What does Dreaming mean for AI agents?
It is not model weight training and not human sleep. That is what Anthropic calls scheduled offline consolidation: a process that reads past sessions and memory, identifies repeating patterns, and fixes or merges entries.
Can this kind of agent be left running overnight?
Only after limiting permissions, budget, and time, with an external session, observability, and a ban on irreversible actions without confirmation. Long-running operation without these mechanisms increases the potential damage.
Bottom Line
Asynchronous operation does not begin with a “run longer” button. It begins with an architecture in which state outlives the process, execution is isolated, secrets are issued with minimal privileges, and the result is verified outside the executor’s context.
Memory adds accumulated experience, but it requires a separate correction process. Organizational context makes the agent a shared participant in the work, but it requires its own identity, data boundaries, and full auditability.
The practical sequence is simple: choose a verifiable task, move the session outside, restrict the environment, add a verifier, introduce candidate memory, and expand autonomy only after shadow runs. A strong model raises the ceiling of what’s possible. Reliability comes from the entire system around it.