An enterprise agent should survive a restart without paying the invoice twice. AWS's durable Go SDK is GA
AWS made its Lambda durable execution SDK for Go generally available: checkpointed steps, approval callbacks and waits of up to a year. Durability is a decision separate from the model.
Listen to this article · 5 min
AI-generated narration of the full article.

An accounts payable agent reads an invoice, matches it to a purchase order, asks a manager to approve an exception and, once approved, triggers the payment. The manager approves on Monday. On Monday night the process hosting the agent restarts. When it comes back, what does the agent remember? If the answer is “nothing,” it starts again from the invoice. If the payment step had already run, the supplier gets paid twice.
That failure has nothing to do with how intelligent the model is. It is a property of the execution environment, and it is the reason AWS’s October 15 announcement matters to anyone putting agents into business processes: the Lambda durable execution SDK for Go is now generally available.
What durable execution provides
Durable functions let a workflow keep its progress across interruptions. The Go SDK, now GA, offers:
- Steps with automatic checkpoints, so completed work is recorded and not repeated after a restart;
- Callbacks for human-in-the-loop and agent-in-the-loop workflows, so a process can wait for an approval without holding compute;
- Durable invocation for reliable chaining of functions;
- Waits that suspend execution for up to a year while waiting on an external event.
AWS also ships a durabletest package to test complete workflows locally, without network access or credentials, and a durablelint analyzer that flags code which could misbehave when a workflow resumes. Regional availability and pricing follow Lambda’s own pages. This GA applies to the Go SDK specifically, and a suspended wait of up to a year does not mean compute running for a year.
Why agents need it more than ordinary workflows
Classic workflow engines have offered durability for years. Agents make it more urgent for three reasons:
- They run long. Agent tasks span minutes to days, which is long enough for deployments, restarts and timeouts to happen in the middle. We wrote about testing what happens in hour three of a long agent run; durability decides whether hour three can resume.
- They wait for people. Approval gates are where enterprise agents spend most of their wall-clock time. A design that keeps a process alive while a manager is on vacation is fragile and expensive. A callback that resumes the workflow when the approval arrives is neither.
- Their steps are not deterministic. Replaying a model call after a restart can produce a different answer from the one that was approved. Durable execution checkpoints the result of the step, so the workflow continues from what was actually decided, not from a fresh guess.
What the SDK does not do for you
Durability is necessary and not sufficient. Three design duties remain with the team:
- Idempotent actions. A checkpoint records that a step finished. If the process dies after the payment API accepted the request but before the checkpoint was saved, the step can run again. Use idempotency keys on every consequential call, so a repeat is recognized and ignored by the system of record.
- Authorization at resume time. An approval granted on Monday may not be valid on Friday: the approver may have left, the amount may have changed, the agent’s permissions may have been revoked. Recheck authority when a long wait ends. This is the temporal authorization problem in another form.
- Compensation. Some steps cannot be undone, only reversed by another action. Define the compensating step for each consequential action before the workflow ships, which is also what turns an emergency brake into an incident plan.
Where it fits in an agent architecture
The pattern worth adopting is a split: the model decides inside a step, and the durable workflow decides what happens between steps. Model calls are wrapped as checkpointed steps; approvals are callbacks; consequential actions are idempotent calls to the system of record; and the workflow, not the model, holds the state of the process.
AWS’s SDK is one implementation, and it is not a general agent platform. Temporal, Step Functions and other workflow engines offer similar guarantees. The choice of engine matters less than the decision to have one. An agent that keeps its progress in the model’s context window will, sooner or later, pay the invoice twice.