This is a guest post by Greg Haskins of Manetu
Write down everything that makes an AI agent hard to run in production: non-deterministic models; long-running executions waiting for human input that must survive crashes and software updates; scaling for throughput or redundancy; tenancy isolation; and meaningful agent identity.
Now write down everything that makes an agent hard to trust: unexpected actions from prompt injections, exfiltration or misappropriating credentials, reaching unintended destinations and tools, or trying to bypass containment, observability, and ultimately, detection. These two lists describe the same underlying problem: what happens at the boundary where an agent reaches outside itself. Whoever owns that boundary can do something about both.
Where durability lives#
Durable execution has to live somewhere: in the application, in the framework, or in the runtime underneath both. AgentVisor™, the secure runtime for AI agents I've been building at Manetu, needed a boundary between the agent and everything it touches to create isolation, enforce policies, and enable observability. Temporal's Workflow model turned out to be the natural place to add another key property to that boundary: durability.
The practical result is that a typical agent’s code doesn't change:
# agent.py: no Temporal import
graph = StateGraph(State)
graph.add_node("llm", call_model)
graph.add_node("tools", tool_node)
app = graph.compile()`The LangGraph-based graph above does not know it's durable. Durability becomes a property of how the agent is run, not how it is written. For instance, a simple configuration of AgentVisor allows you to point it at your Temporal Cloud account:
# agentvisor.yaml
temporal:
target: my-namespace.account-id.tmprl.cloud:7233
namespace: my-namespace.account-id
auth:
type: api_key`What "durable" means here#
The agent application only knows that it has a LangGraph checkpointer, and that the checkpointer reliably returns previous checkpoints. What it doesn’t know is that its entire existence is, under the covers, a Temporal Workflow.
When a user or upstream system creates a new Agent Protocol Thread, a dedicated Workflow is created 1:1 for the Thread’s lifecycle. When a Run is created on that thread, a Temporal Activity is started to manage the lifecycle of the agent’s process. Agent checkpoints update the Workflow state using Temporal’s Update primitive.
Should the underlying worker responsible for the agent crash, Temporal will re-hydrate the Thread’s Workflow elsewhere, including its previous checkpoints. Users who interact with the agent can find its execution in a location-independent manner because Thread maps to a stable Temporal Workflow ID.
Concretely, the mapping looks like this:
| Agent Protocol concept | Temporal implementation |
|---|---|
| Thread | Workflow instance (ThreadWorkflow) |
| Run | Workflow Update + Activity execution |
| Checkpoint | Workflow state, persisted in history |
| Interrupt | Pending Workflow state + signal |
Therefore, “durable” in this context means that an agent’s Threads/Runs/Checkpoints will be dutifully rehydrated, including the ability to restore the agent process and its checkpoint on a new worker, all without the agent process’ involvement or knowledge.
Engineering Challenges#
A thread lives for months. What do you keep?#
A conversational thread has no natural end (someone might resume it next quarter), which turns "how much state do we keep" into a budget question rather than a preference.
LangGraph supports arbitrary checkpoint retention, and some platforms leverage this as a form of historical replay: An agent can be “rewound” to a previous state by pointing it to a specific older checkpoint to continue from. In our model, the LangGraph notion of history is redundant with Temporal’s. Therefore, only the latest LangGraph checkpoint is retained, with the understanding that Temporal’s Workflow replay can restore an agent to any previous state, including the stored unitary checkpoint.
This is also because we store checkpoints as Workflow state and must be mindful of Temporal’s history limits. Culling unneeded state reduces the Temporal history footprint and follows Temporal’s guidance. This pruning occurs at every checkpoint and during any Continue-as-New rollovers.
Two kinds of resume#
Human-in-the-loop resume and crash-recovery resume look identical from outside (both are "continue this thread"), but they aren't the same operation. A person's answer becomes new input, while a worker restarting mid-run has none. For the latter, the graph should resume from its last checkpoint without a stale message forced into an incomplete turn. Same Workflow, two meanings of "resume."
Challenges with Continue as New#
Continue-As-New adds a wrinkle: you can't roll a history over mid-invocation, since the activity drives a real, sandboxed process. The Workflow synchronously shuts down any outstanding Run Activity and continues only after confirming the process has exited. The resumed run keeps its original ID, so a client still polling it finds its answer waiting, unaware that a rollover occurred beneath it.
When Worker Identity Breaks#
The Temporal Go SDK identifies a worker by checksumming its own binary. AgentVisor operates in a hardened environment that aggressively drops privileges. This initially broke our worker since the SDK was unable to obtain the needed metadata. The fix: hand it an explicit build identifier, derived from version-control metadata, before the drop.
Completing the Picture#
Other mechanisms sit at that same interception point, for a different reason: trust. These are not directly related to Temporal, nor is the list exhaustive. What they do is demonstrate that a host/guest-based sandbox offers advantages for agent safety while also making it transparently durable.
Host-Based Identity Management#
Every invocation gets a host-issued identity bound to whoever upstream originally asked for it; every callback the agent makes afterward (a proxied request, a store read, a tool call) is checked against it, so a missing identity fails the call.
Credential Brokering#
The agent's environment never holds a real credential: it sees a placeholder that looks like a key but isn't one, substituted only after that check passes and only for an approved destination; capture the variable, and you've captured nothing.
Transparent Encryption#
We utilize a Temporal Payload Codec to encrypt all state to and from Temporal. Like other host-side mechanisms, this wiring is completely transparent to the agent. More importantly, as with Credential Brokering, agents do not have access to the encryption keys.
Conclusion#
We have demonstrated that it is possible to substantially improve an agent's durability without modification simply by how we run it. We are excited about the potential in this space, and look forward to future contributions. Thanks to the Temporal team and the Constellation Program for the chance to write this up. For more go to agentvisor.dev.