Today, we can build our own agent applications using agent frameworks such as Langchain/AgentScope and coding tools such as Codex and Qoder, relying on their Session save-and-restore capabilities to maintain conversational continuity. But for tasks that need to run reliably in the cloud over the long term, restoring session state alone is not enough: a process crash, a network interruption, or a service restart can occur in the middle of a model call, tool execution, or result persistence. After recovery, an Agent must not only remember what was discussed, but also know which work has been completed, which work is still waiting, and which results have not yet been confirmed. Only then can it continue from the right place, avoiding incorrect duplicate execution and unnecessary resource consumption.
This is precisely the problem Durable (persistent, recoverable execution) is intended to solve: reliably persisting task progress, call intent, and execution results, and establishing explicit recovery boundaries at critical points such as model calls and tool execution. Even if the original process exits or the execution instance is replaced, the task can use its saved state to reuse confirmed results, verify unfinished operations, and keep moving forward. Session recovery keeps the conversation continuous; Durable goes further by keeping task execution continuous.
This article uses a concrete user task—"send notification emails to five customers"—to explain why saving chat history is not enough. It then takes an Agent built with AgentScope as an example to lay out the general design of task state, durable commits, and failure recovery. Finally, drawing on Alibaba Cloud AgentCore's existing Harness hosting and node recovery capabilities, it discusses how shared state, reliable scheduling, and Brain / Hands separation can support a more complete long-term managed service.
Suppose a user gives an assistant a task: using the already confirmed recipient list and message body, send notification emails to five customers and summarize the sending results.
The Agent generates a tool call, and the tool starts sending emails one by one. The first three are confirmed complete. The email service has just accepted the fourth, but the local result has not yet been saved when the process crashes. The fifth has not yet started.
Once a new process starts, the truly difficult question is not how to call the model again, but how to determine the status of the fourth email:
Durable must persist the facts on which these judgments depend outside the process, and define recovery rules. The recovery procedure first reads the committed progress, then decides whether to reuse results, keep waiting, verify the original operation, or start work that has not yet been executed.
This does not require a single process to remain online forever. Processes can exit, tasks can wait, and execution resources can be released; as long as the state remains accessible and a compatible executor can be awakened, there is a basis for the work to keep moving forward.
Durable execution generally requires four capabilities:
The recovery position here is a committed logical boundary. It may be a model response, a tool call, a task phase, or a segment of business progress explicitly saved by the developer. It is not a particular machine instruction in the old process, nor is it unfinished internal computation during model inference.
Therefore, Durable does not mean "never fails," nor does it automatically mean that external actions execute exactly once. If a service remains unavailable, credentials become invalid, or tool results cannot be confirmed, a task may still enter a failed state or a state requiring handling. What it does is make failures leave behind facts that can be explained and recovered from.
The value of Durable becomes obvious when a task lasts longer than one connection, one request, or the lifetime of one instance:
| Scenario | Typical Waits or Interruptions | Facts to Preserve |
|---|---|---|
| Resident personal assistant | User goes offline, service restarts, scheduled wake-ups | Accepted input, pending work, and wake-up times |
| Coding and R&D assistant | Long-running builds, tests, CI, and code reviews | Completed changes, the original build's identity, and results |
| Business automation | Email notifications, order operations, external system calls | Operation identity, confirmed results, and uncertain states |
| Multi-stage analysis tasks | Multiple data sources, parallel subtasks, human confirmation | Subtask progress, dependencies, and continuation conditions |
Local interaction usually keeps the user, terminal, working directory, and Agent process together, so the user can observe exceptions and decide how to continue. Cloud background services, by contrast, encounter instance replacement, rolling deployments, connection interruptions, and resource reclamation; the instance that takes over a task may not be the original one. The longer a task runs, the less we can assume that the same process and the same connection will accompany it to the end.
Locally, durable execution can help a task survive an application restart. In the cloud, it also needs accessible persistent storage, execution scheduling, and environment reconstruction. Moving a local program into a VM with a disk only solves where it runs and the retention of some files; task recovery still needs to be designed separately.
A typical Agent's execution flow is straightforward:
Receive input → Request the model → Get a tool call → Execute the tool
→ Get a tool result → Request the model again → Output an answerDuring a normal execution, the program knows where it is because the function call stack, local variables, and Promises are all still there. For an interactive Coding Agent, this approach is also convenient for displaying output in real time, accepting user corrections, and continuing the conversation.
But after the process crashes, that information is gone. The remaining session file may record only:
user: Send this notification to five customers
assistant: send_batch_emails(recipients, body)
tool result: not yet writtenThis record is enough to show what the model proposed, but it cannot prove what the tool completed internally. send_batch_emails is one call; whether it sent three, four, or five emails internally may still be invisible to the outer loop.
An Agent product that supports session recovery is an easy example to understand: it can use JSONL to save session records with identities and parent–child relationships, supporting context recovery and session branching. This capability is useful, but session records do not automatically contain execution checkpoints inside arbitrary business tools.
What is discussed here is an execution style centered on the interactive loop and session persistence; it does not imply that all Agent frameworks lack Durable capabilities. Some frameworks have already introduced durable workflows, task state machines, and checkpoints. What matters is which guarantees the execution path actually in use provides.
For interaction-centered frameworks, the main goal of session recovery is to let the model regain context so the user can keep working. Tools are usually abstracted as functions that accept parameters and return results; how a function internally accesses services or saves intermediate progress is the responsibility of the tool implementation. This interface is easy to extend, but it does not require tools to expose "how to recover from an interruption."
Durable requires a stronger contract: who holds the execution right over a task, at which moment state takes effect, whether a tool permits replay, how a wait crosses a restart, and how old state is interpreted after a code upgrade. It affects scheduling, storage, and tool interfaces at the same time, and cannot be completed merely by adding a switch to save messages on the existing loop. For applications that still use ordinary function tools, recovery boundaries inside the tools must continue to be designed even after adopting a durable framework.
Even if each email is split into a separate tool call, there is still a window that chat history cannot eliminate:
Having a call intent without a result only tells us that the operation "may have been executed." The request may never have been sent at all, it may have been accepted with the response lost, or—as shown in the diagram—a receipt may already have arrived, with only the final save still missing.
A reliable mechanism must therefore handle two things at once: how internal state is committed, and how external actions are confirmed. The former can be solved through transactions and durable tasks; the latter also requires the business system to provide idempotency identifiers, queries for the original operation, or explicit compensation and manual-handling paths.
| Common Approach | What It Solves | What Is Still Missing |
|---|---|---|
| Save chat history | Rebuild model context | Progress inside tools, reliable waits, and recovery strategies |
| Store messages in a database | Better preservation of historical data | Write ordering, atomic commits, and an execution state machine |
| Restart automatically after a crash | Restore a running instance | Where to continue, and which actions must not be repeated |
| Retry the whole Agent after failure | Give the task another chance | Recognition of completed steps and external side effects |
| Tell the model "the last run was interrupted" | Help the model replan | The missing business facts and deterministic continuation rules |
| Add async/await to tools | Keep waits from blocking threads | Wait relationships that exist across processes, and reconnecting the results |
The issue is not that JSONL is inherently unreliable while SQLite is inherently reliable. Both files and databases can carry a durable protocol; the difference lies in what is saved, when it is confirmed to take effect, and how it is interpreted after a crash.
To move from these patches to Durable, execution progress that was hidden in the call stack must become data that can be stored, validated, and rescheduled.
AgentScope's HarnessAgent organizes model inference, context, tools, and session management together, and uses a Durable execution kernel to manage the entire run. Model generation, tool calls, and business workflows are all durable tasks, with task state driving the Agent loop. Context, task phases, and business data change under the same commit protocol, so execution can continue from the saved phase after a process restart.
HarnessAgent manages the collaboration between model and tools, Session manages persistent state and commit ordering, the task scheduler advances runnable phases, and Storage saves execution data. Together these layers ensure that input has an identity, steps have checkpoints, waits have conditions, and completion has a result.
The following uses AgentScope to lay out this mechanism. At its core is a durable execution protocol that is independent of any specific framework and applies equally to other Agent frameworks.
The model and tool calls in the diagram happen outside the commit transaction. The scheduler selects runnable tasks according to committed state, a task handler runs one phase, and then the result and next state are committed. Storage, scheduling, and observation therefore collaborate around the same sequence of state changes.
AgentScope uses Session as the unified scope for state and commits, and one Session can contain multiple Conversations. A Conversation describes one exchange, while Session also manages the input, tasks, business documents, and execution relationships behind it.
| Object | What It Expresses | Example in the Email Task |
|---|---|---|
| Conversation | The conversation record and its context scope | The ongoing conversation between the user and the email assistant |
| Entry | An immutable session record | User requests, model responses, tool results |
| Document | Structured state that can be updated within a transaction | The recipient plan, sending receipts, current execution progress |
| Task | A durable state machine with phases, checkpoints, and a terminal state | Model generation, tool calls, sending emails one by one |
| Submission | An application submission and its processing result | Whether a send request was queued, processed, or answered |
| Commit | An atomic commit of a set of related changes | Saving a receipt while completing the subtask and updating sending progress |
Entry preserves records of what has already happened, Document saves the data that later phases need to read, and Task determines what can be done next. For example, "a receipt has been received for the fourth email" is a business fact, whereas "the receipt has been written into the conversation" and "the parent task may proceed with the summary" are execution states that must advance together.
AgentScope rebuilds context from persistent records: it reads messages, model responses, and their corresponding tool results within the effective session scope, then applies saved compaction or context adjustments. The in-memory messages list is a runtime representation of these states; even after it disappears, the recovery procedure can still rebuild the information needed to continue reasoning.
AgentScope's Document is typed, versioned structured state. Besides business data, it also stores Agent configuration, pending input, running models and tools, and usage information. Document modifications produce incremental operations through commits, with a full baseline saved when needed; recovery rebuilds the effective state from the baseline plus subsequent increments.
Applications can register their own Documents and Tasks, such as an email plan, an approval stage, or data-processing progress. These extension states use the same commit mechanism as built-in tasks, so there is no need to stuff all intermediate data into prompts or tool outputs.
If "tool completed" is written first and the tool result is saved afterward, a crash in between leaves a completion record without a result. Conversely, if the result is saved first and the task advanced afterward, the executor taking over may mistakenly believe the work still needs to be done.
A single Commit in AgentScope supports appending Entries, modifying Documents, creating or advancing Tasks, and updating Submissions at the same time. For the fourth email, the same batch of writes can include:
Append the tool-result Entry
Update the sending receipt in the email-plan Document
Mark the sending Task as complete
Update the tool's running state in the sessionA commit proceeds in the following order:
Acquire the Session's commit order
→ Prepare the related changes in a transaction draft
→ Validate and freeze the write set
→ Storage saves atomically
→ Adopt the newly persisted state
→ Update views, notify waiters, and schedule subsequent tasksAgentScope serializes state commits within the same Session, while model requests and tool execution proceed outside commit transactions. The scheduler can run multiple ready tasks, but their state changes still take effect in order. An external call that lasts ten minutes does not therefore hold a state-commit transaction open for ten minutes.
A normal commit is adopted by in-memory state and observation views only after it has been persisted. Once Storage confirms that the write set has been persisted, the Session adopts the new state in one step and then notifies the scheduler and observers. If preparation fails, the draft is discarded. If a storage exception occurs after persistence has already taken place, the committed changes remain valid, the current Session stops running, and reopening it recovers from the state actually saved.
AgentScope also supports constrained deferred commits, used for progress that may be lost, such as text being generated or output from a running tool. Only modifications to existing progress documents that satisfy the constraints may be saved later. Once a commit contains new messages, task phases, input acceptance, or other critical changes, it is persisted immediately as a normal commit. When later commits read these documents, they also fold the not-yet-saved changes into the durable boundary. This controls high-frequency writes without letting a task continue on facts that have not been confirmed.
This atomicity covers the data managed by the Harness. Sending emails, accessing external databases, and executing shell commands remain external actions that need separately defined confirmation and recovery rules.
An ordinary function decides its next step by which line of code execution has reached. AgentScope's Task stores the task type and version, the input, the owning session or parent task, and the current state and checkpoint. The recovery procedure uses the task type to find the handler code, and the checkpoint to determine which phase to start from.
The Task lifecycle includes the following states:
| State | Meaning | How It Is Scheduled |
|---|---|---|
| pending | Durably created, waiting to run | The scheduler starts the corresponding phase |
| running | Executing a phase | Commit the next checkpoint, wait, or result |
| waiting | Waiting for specified tasks to finish | Save the dependency tasks and join policy; no code runs for now |
| sleeping | Waiting until a point in time | Save the wake-up time and the next phase |
| completing | The result is decided, but not all owned subtasks have finished wrapping up | Wait for the subtasks to settle; no further phases of its own are run |
| terminal | Finished | Keep the final result for other tasks to read |
For example, if the fourth email is waiting for a query to confirm it, its state can be represented as:
{
"kind": "send-notice",
"version": 1,
"input": {
"operationId": "notice-2026-10-customer-4",
"recipient": "customer-4",
"bodyRef": "approved-notice-body"
},
"state": {
"status": "sleeping",
"until": 1793289600000,
"checkpoint": {
"phase": "confirm"
}
}
}This record saves the original operation's identity, the next phase, and the wake-up time together. During the wait there is no function call or Promise that must be kept alive; when the time arrives, the AgentScope scheduler invokes the confirm phase again. Data needed by the next phase goes into the input, the checkpoint, or a Document, and phases hand off work through this persistent data.
Recovery re-enters at the beginning of the saved phase; it does not jump back to the line where the crash happened. If one phase contains several external actions that cannot be repeated, the phase should be split further, or confirmable operation identities should be saved for those actions. Simply adding more await expressions inside a function does not add durable recovery boundaries.
AgentScope's Agent loop consists of model-generation tasks and tool tasks. Once an input is accepted, a Submission is saved first. When the input enters the current run, a user Entry is written and a model-generation task is created. When the model proposes tool calls, the corresponding tool tasks are created and the generation task's wait relationships are saved.
Submit input
→ Save the Submission and the user Entry
→ Create the model-generation Task
prepare: prepare context and model configuration
request: save the request phase, then call the model
tools: save the model response, create the tool Tasks, and wait durably
Tool Task: save call intent → execute → commit the result
Tools finish: read the committed results, create the next generation Task
→ Get the final answer, save the Entry, and finish the SubmissionAfter the model returns a tool call, AgentScope commits the model response, the tool tasks to be created, and the state "next, wait for these tasks" together. Even if the process exits after the commit, on restart it still knows which calls should be executed, without making the model guess its previous plan again.
The model-generation task itself includes phases such as prepare, request, retry, poll, and tools. The prepare phase fixes the context position, the model choice, and the required request options. If the request phase is interrupted, AgentScope treats it as one unfinished attempt. Saved partial text is kept as a record of the interruption and is not used as a complete response to drive tool execution.
Retry counts, backoff times, and the next phase all become part of task state. For models that provide an asynchronous response handle, AgentScope saves the handle and the query time, then continues querying the original request after recovery. Tasks that keep crashing in the same phase are subject to a restart limit; once the limit is reached, the failure reason is recorded and the task ends, so the same error is not triggered again on every start-up.
Once all tool results are ready, the generation task reads the original tool records and results, finishes the current round, and hands off to the next generation round. Here "continuing to reason" is determined by the relationships between durable tasks; the original function call stack is no longer the only basis.
AgentScope keeps the way tools are used—accept parameters, return a result—while a built-in tool Task manages their durable lifecycle. A tool Task distinguishes two phases:
In normal execution the tool is called directly once the intent has been committed in the call phase. When recovery enters the execute phase, AgentScope treats the external action as possibly already having happened. Only when both the policy saved at call time and the tool's policy at recovery time are safe does it re-execute using the already confirmed parameters, without re-running pre-call processing that might change them. Otherwise it saves an interrupted result and the committed partial output, letting the subsequent flow handle the uncertainty.
When the complete result is committed, the result Entry, the tool-run document, and the Task's finished state are saved together. The parent task uses this to determine that the tool has ended and obtains the same result.
Atomically commit the call intent and the execute phase
→ execute the tool outside the transaction
→ atomically commit the tool result and the task's finished stateA tool declaring that it is "safe to replay" is a commitment by the tool author about its business behavior; the framework does not automatically make sending emails idempotent. A tool returning an explicit error and an execution state that cannot be confirmed should also be recorded separately: the former has already obtained a result for one call, while the latter still requires verifying the original action.
If a black-box send_batch_emails() is merely registered as an ordinary tool, the execution kernel can know that this call was interrupted, but not which of the emails were completed inside it. Finer-grained recovery requires turning the tool itself into a multi-phase task.
AgentScope uses custom tasks to bring the business phases inside a tool into the same durable execution mechanism. The email assistant registers a sending task type, uses a Document to store the confirmed recipient plan, creates a subtask for each email, and saves the subtask identities together with the parent task's wait state in the same Commit.
Each subtask handles its own sending intent, original-operation query, wait, and result confirmation. The parent task's wait is not an in-memory Promise.all but a durable relationship: which Tasks to wait for, which join policy to use, and which phase to enter when the wait ends.
AgentScope provides two waiting policies, allSettled and failFast. The former waits for all dependency tasks to finish before aggregating; the latter, when a subtask fails, asks the other owned subtasks to stop and waits for them to wrap up. Even if the parent task has already decided its own result, it stays in completing as long as any owned subtask still needs to wrap up, and reaches a true terminal state only after they finish. After a process restart, the scheduler continues waiting or wrapping up from this persistent tree of task relationships.
To handle the window of "already sent but the receipt was not saved," this example adds an explicit prerequisite: the email service supports idempotent acceptance keyed by a stable operation identifier, and can be queried for the original operation. Each email's operation identifier is saved before the external call and bound to a fixed recipient and message body.
In this task, the Agent is responsible for understanding the user's request, forming the plan, and generating the summary, while AgentScope's task state machine is responsible for the durable continuation of the sending phases. Idempotent acceptance and original-operation queries are provided by the email service; the task handler uses them to confirm external actions and commit results.
Now let us recover the earlier failure:
| Facts at Recovery | How to Continue | |
|---|---|---|
| Emails 1–3 | Terminal states and receipts have been committed | Read them directly; do not send again |
| Email 4 | The operation identity is saved, but there is no confirmed result | Enter the query phase; record the receipt after completion is confirmed |
| Email 5 | The task exists, but no external action has started | Execute from its initial phase |
Committing subtask creation and the parent task's wait together addresses "whether these five pieces of work are still remembered after the process exits"; each email's business operation identifier and query phase address "how to verify an external action once it has happened." Only the two layers working together make it possible to recover down to an individual email.
If the email service supports neither idempotency nor queries, the fourth email must still be kept in an uncertain state and handed over for business-side verification. The durable state machine provides an explicit place to handle it; it cannot conjure up facts that the external system never stored.
When an application uses AgentScope, it first configures models, tools, and task definitions, opens the persistent Storage, and then obtains the existing Conversation in the Session. Submitting input returns a Submission identity; the application may wait for the result or query it again later.
After a process restart, the main flow is:
Reopen the same Storage
→ Restore Conversation, Entry, Document, Task, and Submission
→ Check task types, versions, and phase handlers
→ Start the task scheduler
pending / interrupted running: re-enter from the saved phase
waiting: recheck the dependency tasks
sleeping: keep waiting for the original time; run if it is already due
completing: check whether owned subtasks have finished wrapping up
terminal: provide the saved result directly
→ Every state change still goes through the same atomic commit sequenceAgentScope registers tasks, tools, and extension definitions through a Registry. Storage holds the state, identities, and definition versions, while the Registry supplies the handler code. On reopening, the kernel checks the task type and version and runs the necessary state migrations; if a task definition is missing or cannot be migrated, the original state is preserved and the blocking reason is reported, and scheduling resumes once a compatible definition is ready.
Retries of the same business input use the same requestId, and AgentScope returns the original Submission, avoiding duplicate work. Waiting for a Submission again restores observation only. Closing the current Harness stops this round of driving while preserving the unfinished tasks. Business cancellation first durably records the cancellation intent, then tells active phases to stop, waits for owned subtasks to end, and finally commits the task's terminal state.
Recovery therefore neither requires replaying the whole Agent loop nor amounts to submitting the original prompt again. It looks for unfinished, currently runnable phases in the persistent task graph, reuses confirmed results, and continues the original work.
AgentScope atomically saves and reads execution records through the Storage interface, separating the storage implementation from task semantics. Documents are saved with incremental operations plus periodic full baselines, and task records hold their complete current state; on reopening, the effective state is restored from these without serializing the whole process. Applications can choose local persistent storage or connect a remote backend provided by the platform, according to their deployment needs.
AgentScope's session views, document views, and task graph subscribe to changes after commits, presenting input acceptance, model output, tool progress, dependencies, and final results. On reconnection, the current view is fetched first, followed by subsequent changes. Previews that are allowed to be saved with delay are an explicit exception and are not the sole basis for recovery. A Session opened read-only provides querying and observation without starting task scheduling or acquiring write permission.
AgentScope starts the task scheduler with resume(), and uses wake-up information to tell the host "there is runnable work now" and "when to continue next." A resident host uses local timers to advance due tasks; a cloud host receives changes through onWake, durably schedules the next wake-up, and—after its process has been reclaimed—reopens the Session and calls resume(). The scheduler decides whether a task is runnable; the host provides the actual chance to run it.
Multi-instance execution additionally requires shared storage, execution-right isolation, and compatible environments. A task in sleeping or waiting does not occupy an active phase invocation, but real running processes and external tools still have their own lifecycles. Reconnecting that external work requires the platform hosting and tool execution mechanisms discussed in the next part.
AgentScope's Durable execution kernel lets Entry, Document, and Task jointly describe the facts and the future of a piece of work, kept consistent through atomic Commits. The Agent loop is driven by durable state machines, while the host and platform hand runnable work to actual execution resources. The framework is responsible for "where to continue and how to continue"; the platform is responsible for "where state is kept long-term and which instance continues." They are connected through storage and wake-up contracts.
Alibaba Cloud AgentCore is a cloud hosting platform for AI Agents. It provides Harness hosting, session management, continuation after task interruption, and node recovery, helping developers keep agent applications running stably in the cloud.
AgentCore already provides the ability to host Harnesses, supporting continued execution after a task is interrupted and also recovery from a specified saved execution node. This gives one Agent run a state that can be picked up again, so a business task no longer exists only within one interaction or one running process.
The hosted Harness (OpenHarness) keeps the underlying kernel's way of doing inference, handling context, and using tools, while the platform connects its state-saving and recovery capabilities. A recovery node here is an execution position that the kernel and its adaptation mechanism can save and interpret; node recovery does not automatically undo external business actions that have already happened. The state and control interfaces that different kernels expose also determine how fine-grained recovery can be.
On this foundation, finer-grained Durable can extend further into model generation, tool calls, result application, and long waits. The task state machine in the previous part answers "how this phase continues"; the platform must answer "where the state is kept, when continuation is scheduled, and which instance executes it."
Brain–Hands separation and a more complete Agent as a Service are directions to be built on top of the existing hosting capabilities. The following discusses, from an architectural point of view, how Durable fits into these directions and how they can share one durable foundation with existing Harness hosting.
The diagram shows the existing hosting capabilities, the directions for further evolution, and the state, scheduling, and environment abstractions that both can rely on. What connects them is the durable execution contract: it can accommodate the recovery nodes of native Harnesses as well as the task phases and tool handoff states reached by integrating deeper into the kernel.
What the platform unifies is the contract for saving, committing, and reading state. Agent frameworks and runtimes still manage their own context, messages, and checkpoint formats; the adaptation layer connects this native state with the task identities, tool intents, wait conditions, and result-application positions the platform can understand.
Session Store provides the shared durable basis for this collaboration: it records state versions, keeps checkpoints and result references, returns queryable commit receipts, and provides a consistent set of state during recovery. Together with reliable scheduling and event streams, it allows a task both to be resumed and to be observed again by the business application.
| State Layer | What Is Saved | Who Interprets and Uses It |
|---|---|---|
| Harness-native state | Context, messages, native checkpoints, and the continuation position | The corresponding framework and its adaptation layer |
| Platform execution facts | Input acceptance, execution right, tool authorization, wait conditions, result application, and terminal state | AgentCore's execution coordination and recovery mechanisms |
| Tool execution facts | The original execution identity, physical progress, complete results, and delivery status | The tool provider; in the separated architecture this is handled through Hands |
| Workspace and artifacts | Files, resource bindings, artifacts, and the versions required | Environment and tool environments |
| User-visible views | Messages, progress, tool states, and final results | Business applications and observation interfaces |
These states can be stored separately and linked through identities and versions. Large native states and results can be saved as immutable objects referenced by the commit records, and workspace files are carried by the corresponding environment. The platform does not require everything to go into one chat log.
When integrating different frameworks, the adaptation layer declares the boundaries that can be saved and recovered. Frameworks able to participate in commits for model completion, tool authorization, and result application can offer finer-grained recovery control; frameworks that mainly expose a session recovery interface have their recovery scope determined by their native capabilities. Shared storage can carry different payloads, but recovering an old Session still requires a matching kernel and state format.
A shared Session Store can therefore support both hosted Harnesses and deeper Durable designs. A unified storage contract reduces duplicated work, while each integration path keeps its own recovery semantics and granularity.
Going from recovery at a specified node toward fine-grained Durable depends on defining clearly which facts must be saved together, and which subsequent actions are allowed only after that save succeeds.
Take one tool call: saving only "the model wants to call a tool" is not enough. Recovery also requires the Harness's continuation position, the fixed tool parameters, the association between the native call and the platform task, and the conditions for waiting for the result. Placing this information inside one consistency boundary lets the recovering executor clearly determine whether the call was authorized to execute, which call a result belongs to, and whether the next step is to wait or to continue reasoning.
This design extends the atomic Commit from Part 3 into platform collaboration. The kernel commits its own recoverable state while the platform saves the corresponding execution facts at the same time, and later dispatch is based on confirmed commits. When separate storage and messaging systems are involved, the pending dispatch intent can be durably saved together with the state and then handed over through a retryable delivery mechanism, avoiding a situation where the state has advanced but the follow-up work has no basis to execute.
Three kinds of progress must be expressed separately here: the call has been accepted, the tool has completed, and the result has entered the Harness context. Long intervals may separate them, and a failure may occur at any handoff. Saving the progress separately lets recovery locate the one missing step instead of re-running the whole flow.
For a hosted Harness these boundaries must be established on top of the kernel's existing recovery interfaces; for kernels that allow deep control of the execution process, model completion, tool authorization, and result application can be designed directly as durable phases. The two approaches share the state foundation, but that does not automatically give them the same depth of control.
Brain–Hands separation can be seen as a further unfolding of the durable handoff mechanism described above: Brain manages inference and context, Hands manage the actual execution of tools, and the two collaborate through saved call identities, state, and results.
The core of this separation is making "waiting for a tool" a state that can be expressed durably. Once Brain has committed the call and the wait conditions, it can in principle release the execution resources for this round; the tool keeps being advanced by an independent execution mechanism. When the result meets the conditions to continue, a compatible Brain instance reads the original state and applies the original result. The whole process no longer requires the original inference process to keep waiting.
| Logical Responsibility | Facts to Preserve | Recovery Goal |
|---|---|---|
| Brain progression | Context, checkpoints, results awaiting application, and the application position | Continue reasoning from the original phase without applying a result twice |
| Hands execution | Original operation identity, execution progress, complete results | Query or reconnect to the original operation and establish its scope of completion |
| Result handoff and scheduling | Which call a result belongs to, delivery progress, wait conditions, and recovery arrangements | Existing results can be delivered again, and tasks whose conditions are met can obtain execution again |
The following walks through the state handoffs in this architecture using a long-running tool as an example:
In this design, a tool-completion notification is only a trigger for continued execution; persistent state is what actually decides the next step. Scheduling must be able to rediscover unfinished recovery arrangements and constrain the currently valid executor, preventing an old instance and the instance taking over from advancing the same state at the same time. Only then are tool waits, result delivery, and inference recovery not individually bound to some process or some connection.
Returning to the five-email example, this separation lets the inference instance exit during sending without affecting work that has already been handed off, while the granularity of per-email recovery still comes from the business task design in Part 3. Receipts for the first three emails can be reused, the fourth is verified by its original operation identity, and the fifth continues from the phase that has not yet run. Brain–Hands separation provides the conditions for continuing independently; business checkpoints and the external system's ability to confirm results together determine how fine-grained recovery can be.
If a tool itself cannot query the original operation or recognize duplicate requests, a separated architecture still cannot automatically eliminate the window in which "the action has happened but the result is unconfirmed." This uncertainty must still become part of task state and be handled by the corresponding business rules.
Whether using the existing node recovery or going further with Brain–Hands separation, reading the state again is only part of recovery. A new execution instance also needs a compatible kernel, dependencies, model and tool configuration, and permissions to access the workspace and business resources.
Architecturally, Environment can carry the description and binding of these execution conditions: state says how far the task has progressed, the environment definition says what is needed to keep running, and the scheduling mechanism decides who takes it over. For local Agents moving to the cloud, these three parts together form a migratable execution unit.
In a separated architecture, inference and tools can also use different compute resources and lifecycles. Brain assembles the Harness and model capabilities on demand, while Hands use a Sandbox or an external execution service according to what the tool requires; persistent workspaces and artifacts remain accessible through stable references.
The environment definition provides the basis for reconstruction, but files and artifacts still need appropriate persistent storage. A partially written file cannot by itself be taken as proof that a tool finished; at recovery, progress must also be judged using the operation identity, artifact versions, and confirmed results. Environment and Session Store therefore keep running conditions and execution facts respectively, and together support task continuation.
Existing Harness hosting lets a task continue after an interruption; a more complete Agent as a Service extends that continuity across the whole service lifecycle: users can go offline, connections can break, and compute instances can be replaced, while the task still keeps a clear identity, state, and next arrangement.
Starting from this goal, execution, observation, and business control need to be managed separately. Whether a task continues is decided by saved execution state and scheduling conditions; how progress is shown is decided by queryable message and event views; supplemental input and cancellation must become durable operations whose acceptance can be confirmed and whose results can be tracked. Real-time output helps users understand the process, while confirmed state and results are what support recovery.
Long-lived services also need jointly managed retention scopes for checkpoints, associated results, workspaces, and artifacts. As long as an unfinished task still references some state or artifact, compaction and archiving must preserve its recovery dependencies; and as historical chat data grows, the cost of reloading state must also be controlled. These are all capabilities that need continuous refinement on the way from "a particular run can recover" to "tasks can be hosted long-term."
For AgentCore, the existing hosted Harness, continuation after interruption, and recovery from a specified node provide the starting point; a shared Session Store can connect different kernels and execution styles; and finer-grained commits, Brain–Hands separation, and reliable scheduling provide the architectural foundation for a more complete Agent as a Service. The goal they all point to is: let business tasks persist, and let compute resources participate in execution around the task's actual progress.
AI Gateway Launches FinOps Session Observability to Help Enterprises Optimize Agent Costs
801 posts | 61 followers
FollowData Geek - September 4, 2026
Alibaba Cloud Community - July 17, 2026
Apache Flink Community - April 16, 2026
Alibaba Cloud Native Community - June 8, 2026
Alibaba Cloud Indonesia - July 3, 2026
Apache Flink Community - June 23, 2026
801 posts | 61 followers
Follow
Token Plan
Build more, spend less. One plan, every modality.
Learn More
QwenWork
QwenWork is dedicated to helping employees strengthen their professional competitiveness in the AI era and to enabling enterprises to improve organizational effectiveness.
Learn More
DeepSeek
DeepSeek-V4.1-Flash is the lightweight flagship of DeepSeek's new architecture family, packing 552B total MoE parameters to deliver flagship-surpassing intelligence across key benchmarks.
Learn More
AgentCore
AgentCore unifies agent construction, governance, and execution capabilities so enterprises can deploy diverse agents with confidence.
Learn MoreMore Posts by Alibaba Cloud Native Community