Do AI Agents Still Belong in Serverless? A Lifecycle Model for Agentic Compute
Long-lived agent goals do not always require long-lived compute. This article presents a lifecycle model for choosing among ephemeral execution, durable orchestration, and persistent environments on AWS, with practical boundaries for state, recovery, isolation, observability, and cost.
Serverless made compute disposable. An event arrives, code runs, and the execution environment can disappear. State survives somewhere else: a database, an object store, a queue, a workflow service.
That model still fits most AI agents. It strains when an agent's goal outlives any single execution. The agent completes six tool calls, pauses for an approval that arrives the next morning, revises its plan, waits on a deployment, and reports back two days later. The goal stays open the whole time. Useful compute does not.
That strain is usually read as a serverless limitation, and usually it isn't one. A Step Functions Standard Workflow can run for up to one year , and a callback task can pause until an external process or a human returns a task token with none of your compute running. A Lambda durable execution can also span up to a year , checkpointing progress across many invocations, with waits that suspend the function and stop compute charges. So the first thing to state plainly:
A long-lived goal does not necessarily require long-lived compute.
The harder case sits elsewhere. Some agents depend on a checked-out repository, installed native dependencies, build artifacts, a warm cache, a browser profile, or a GPU context. When rebuilding that environment is slow, expensive, or unsafe, continuity earns its keep — not because the task runs for a long time, but because discarding the environment costs something measurable.
Amazon Bedrock AgentCore Runtime now offers two compute types: serverless microVMs, and Instances (announced as runtime instances), which run agents on AWS-managed EC2 instances inside your own account and VPC. Together with Lambda, Step Functions, and containers, the architectural choice becomes explicit: ephemeral execution, durable orchestration, or a persistent and restorable environment.
The choice depends less on how long the goal stays open than on what has to survive while it is open.
Separate the Lifecycles — and the State
"The agent runs for three days" is an ambiguous requirement. It can mean four different things.
Concept | Question it answers | Example |
|---|---|---|
Goal lifecycle | How long can the objective remain incomplete? | "Migrate this application to AWS" stays open for three days. |
Execution lifecycle | How long does one allocation of compute run? | A reasoning step runs for four minutes. |
Workflow or execution state | How far has this goal progressed, and what is safe to do next? | Architecture review completed; deployment approval pending. |
Agent memory | What retained context may improve future reasoning? | The application team prefers Terraform and deploys on Tuesdays. |
Two statements carry most of the design weight:
text
3-day goal ≠ 3-day compute executionAgent memory ≠ Execution state
AgentCore Memory stores conversational events and, with a configured memory strategy, extracts long-term records such as facts, preferences, and summaries. Those records are useful context. They are not a transaction log for a goal.
An agent can remember that a team prefers Terraform and still lose the fact that it already submitted a change set. Recovery needs explicit execution state: plan version, completed logical actions, artifact versions, approvals, tool operation IDs, retry counts, compensation status.
AgentCore's own session model already separates identity from compute. On the microVM compute type, the compute behind a session stops on inactivity (15 minutes by default), an explicit
StopRuntimeSession call, a failed health check, or the maximum compute lifetime (8 hours by default). The session itself stays valid until the runtime is deleted, and the next invocation with the same runtimeSessionId provisions new compute with a fresh lifecycle allowance. A session ID is a continuity handle. It is not a promise that the same process is still alive.The same split changes observability. Invocation traces remain useful, but an operator investigating a three-day migration needs the goal trajectory. AgentCore Observability emits OpenTelemetry-compatible telemetry into CloudWatch; your application still has to propagate the identifiers that make a goal reconstructable — a stable
goal_id correlated with session and execution IDs, plan and checkpoint versions, tool operation IDs, approvals, delegated identity, and produced artifacts.Durable Workflows Already Separate Waiting from Computing
Step Functions complicates any claim that agents have outgrown serverless merely because their tasks last a long time. Standard Workflows run for up to a year with exactly-once execution of states, which is why AWS positions them for orchestrating non-idempotent actions. Lambda durable functions use checkpoint and replay: waits suspend without compute charges, a durable execution can span many invocations, and each individual invocation still lives inside the ordinary 15-minute Lambda timeout.
So a goal can follow this lifecycle:
text
Goal accepted↓Execution performs useful work↓Checkpoint committed↓Compute disappears↓Wait for approval or external event↓New execution restores progress↓Continue
Queues, events, managed state, and durable workflows already separate waiting from computing. Nothing in that lifecycle requires allocated application compute during a wait.
Agents add difficulty in a different place. The path is partly chosen at runtime by model output rather than encoded in advance. A model may revise the plan, pick a different tool, or delegate a step after seeing new evidence. Durable orchestration can still coordinate that, but the checkpoint boundary needs care.
Lambda durable functions replay deterministic application code and substitute stored results for completed durable operations. Calling a model or a side-effecting tool outside a checkpointed step is therefore unsafe: replay could produce a different plan or repeat an external action. A sound design checkpoints the result of non-deterministic reasoning before acting on it, and wraps side effects in durable operations with stable identities. In Step Functions, the state machine can own coarse progress — reason, act, wait, review — while the agent decides the next action inside a bounded task.
One integration detail is worth knowing before drawing that architecture. In the Step Functions integration table, Amazon Bedrock AgentCore is listed with Request Response support only ; neither
.sync nor .waitForTaskToken is listed for that optimized integration. A state machine can start an agent turn and continue when the call returns, but it cannot hand a long agent turn to that integration and block until the agent calls back. Completion has to arrive another way: a callback task on a resource that does support task tokens, a status poll against your own progress record, or an event the agent publishes when it commits a checkpoint. The practical effect is that the orchestration boundary lands on the agent turn rather than the goal. Authoritative progress still belongs in workflow state or a separate execution ledger that the orchestrator owns; what the agent reports at the end of a turn is an input to that record, not a substitute for it.The workflow does not have to encode every reasoning path. It has to own the recovery contract.
Failure Means Restoring Goal Progress
A failed request is often retried from the beginning. That recovery model is dangerous for an agent that has already changed external systems.
Consider a deployment action:
text
PLANNED → DISPATCHED → SUCCEEDED↘ UNKNOWN
UNKNOWN is the state that matters. The deployment API may have accepted the request even though the response timed out. Repeating the tool call can create a second deployment or apply the same change twice.Every side-effecting action needs a stable logical identity, such as
goal_id + action_id , that survives retries and new compute. Where the target API accepts an idempotency token, the tool adapter should pass that identity through. Where it returns an operation ID, persist the ID before polling. Where neither exists, recovery means querying the target system, reconciling the observed result, or running a defined compensation — not asking the agent to try again. Exactly-once semantics in Step Functions protect the workflow's own state transitions; they say nothing about whether the system your tool called is idempotent.The same rule applies to delegated agents. Persist the assignment, the expected output, the authorization scope, and the completion record. Do not treat a chat transcript as proof that a delegated action committed, and do not persist bearer tokens as workflow state — store references to the identity and authorization context that must be reacquired when execution resumes.
Durability is more than saving a conversation. It is the ability to resume from a known recovery point without repeating completed effects.
The Deciding Variable Is Reconstruction Cost
Disposable compute works when execution can be rebuilt cheaply and reliably from durable inputs:
text
checkpoint + event + durable artifacts + fresh compute
For an API-oriented agent, reconstruction means loading a plan and some context before the next tool call. That is usually trivial.
For an engineering agent, it might mean cloning a large repository, restoring uncommitted changes, installing native dependencies, warming caches, rebuilding artifacts, recreating a browser profile, or re-establishing process state that cooperating agents depend on. The environment is still reconstructable; its recovery time and failure surface may simply dominate the design.
This gives a better question than "how many hours does the agent run?"
If compute disappears now, what must be rebuilt before useful work can continue?
I would not keep an environment alive because a task takes two hours. I would keep it alive when losing it costs fifteen minutes of rebuild plus a real chance the rebuild fails, several times a day. An eight-hour task with 20 minutes of computation and three approval waits does not justify eight hours of allocated compute. A 40-minute task that loses 15 minutes reconstructing a specialized workspace after every interruption might.
Persistence can also be selective. A migration workflow can use ephemeral executions for analysis, attach one persistent workspace for repository changes, and return to ephemeral execution for approval and reporting. The goal stays durable, most executions stay disposable, and exactly one environment stays alive.
What the Instances Compute Type Changes
Runtime instances became generally available in August 2026 . Agents run on Amazon EC2 managed instances that AgentCore provisions and operates in your account and VPC. A capacity provider defines the operating system, allowed instance types, VPC networking, EBS volumes, and IAM roles; AgentCore handles provisioning, patching, scaling, and teardown.
The documented contract has boundaries that matter more than the headline duration.
- A session maps to one instance. A session is the pair of capacity provider and
runtimeSessionId. The first invocation for a new session includes provisioning and is therefore slower; later invocations reuse the running instance.
- Sessions run for up to 14 days. At the maximum lifetime, AgentCore stops the session, terminates the instance, and retains the configured EBS volumes. Invoking the same session again provisions a new instance and reattaches those volumes.
- Filesystem persistence is not process persistence. Data on capacity provider volumes survives a stop. RAM, open network connections, and running subprocesses do not. Anything in memory that matters has to be written down before the instance goes away.
- Co-located agents are not isolated from each other. Multiple agents can share one instance, its filesystem, and its GPUs. AWS states directly that agents on an instance are not isolated and must be mutually trusted: containers and per-runtime execution roles are not a security boundary inside the host, and any code on the instance can read the credentials available to it. Sharing is explicit, not automatic — each runtime must configure the same volume by name and be invoked with the same session ID under the same capacity provider.
- Specialized hardware is provisioned for you. A capacity provider can allow supported NVIDIA G-family GPU or AWS Inferentia2 instance types, and AgentCore installs the drivers, so standard CUDA images work without bundling them.
- These are managed instances, not your instances. Your account, VPC, and CloudTrail controls apply, but you do not launch, patch, or terminate them yourself.
- Storage options differ by compute type. On Instances, durable files come from capacity provider EBS volumes, isolated per session. Managed session storage (preview) and bring-your-own EFS or S3 Files mounts are documented as unsupported on Instances runtimes ; specifying
sessionStorage,efsAccessPoint, ors3FilesAccessPointalongsidecapacityProviderConfigurationfails with aValidationException.
A capacity provider is effectively immutable after creation: only its description can be edited, so changing instance types, OS, networking, or volumes means creating a new one. Deleting one stops and deletes all of its sessions along with their persistent storage. That makes a capacity provider a blast-radius unit, not a configuration convenience.
On microVMs, managed session storage resets when the agent runtime version is updated and expires after 14 days without invocation; capacity provider volumes survive version updates. If you ship agent versions frequently, the workspace your agent depends on may not survive your own release process — another reason goal progress belongs in a store you control rather than a mounted workspace.
There is also a security boundary outside the instance. AgentCore Runtime authorizes invocations against the runtime ARN, not the session. It validates the format of
runtimeSessionId but does not verify that the session belongs to the calling identity. Where one backend IAM principal serves many end users, that binding is your responsibility: derive the session ID server-side from the authenticated user, never accept it from client input, and use distinct IAM principals per user or tenant where the deployment allows it — the control AWS calls the strongest available.A shared filesystem is a communication medium, not a coordination protocol. The launch post demonstrates two agents collaborating through a shared session directory with no messages exchanged between them. That arrangement says nothing about ownership: co-located agents still need write ownership rules, atomic or version-checked updates, conflict handling, and one authority that decides when an artifact is final and a goal is complete. Without those, co-location relocates race conditions onto a faster filesystem.
Instances earn their place where instance-backed compute, hardware selection, co-location, or a restorable EBS workspace measurably lowers reconstruction cost. Many agents have none of those properties. When progress is externalized, waits dominate the timeline, and a fresh environment starts quickly, microVMs or a durable workflow remain the simpler fit.
Three Execution Patterns
These patterns describe workload characteristics, not product tiers. They overlap, and one goal may use all three.
Pattern | Goal and execution relationship | Required state | Typical fit |
|---|---|---|---|
Ephemeral execution | One bounded execution usually completes the goal | Request context and externally stored application data | Q&A, summarization, request-scoped support, lightweight automation |
Durable orchestration | The goal spans executions and waits | Explicit checkpoints, operation identities, approvals, external artifacts | Business processes, research, remediation, human review |
Persistent environment | A workspace or hardware context is costly or unsafe to rebuild often | Durable goal state plus a retained or restorable environment | Coding, migration, simulation, some GPU and trusted multi-agent work |
Ephemeral execution. The execution approximately matches the request:
text
Request → Agent execution → Tool calls → Response
AgentCore Runtime microVMs, Lambda, or container-based serverless compute can all fit, depending on interface, duration, and resource needs.
Durable orchestration. The goal stays alive while compute comes and goes:
text
Goal → Execute → Checkpoint → Wait → Resume → Execute
Step Functions, Lambda durable functions, events, and durable application state coordinate bounded reasoning and action steps. Compute allocation follows active work instead of elapsed time.
Persistent environment. The environment itself is an operational asset:
text
Goal├── durable progress└── managed environment├── repository and artifacts├── dependencies and local tools├── durable workspace├── specialized hardware└── mutually trusted agents
The Instances compute type primarily addresses this pattern. Critical progress still belongs outside process memory: a persistent environment reduces how often you reconstruct, not whether you need recovery.
AWS's own launch example mixes the patterns rather than choosing one — a lightweight orchestrator agent on a microVM dispatching work to specialized workers on Instances , where the orchestrator scales quickly and the workers hold the state-heavy environment. A migration goal can be durable at the goal level, ephemeral for analysis and reporting, and persistent only for the stage that holds a working repository.
Cost Follows the Lifecycle Boundary
The comparison that matters is the cost of retaining an environment against the cost of rebuilding it.
For AgentCore Runtime microVMs , CPU is billed on actual consumption — no CPU charge during I/O wait when nothing else is running — while memory is billed per second on the peak consumed up to that second, across the session from microVM boot to termination, with a 128 MB floor. Long waits avoid CPU charges without making a live session free.
Instances bill the underlying EC2 instance plus an AgentCore management fee calculated as a percentage of the public EC2 On-Demand price; the published worked example uses 12%, with a reduced 7.8% for G-series families. Charging runs per instance-hour from boot until the instance is stopped or terminated, with roughly a one-minute minimum. EC2 Savings Plans, Reserved Instances, and On-Demand Capacity Reservations apply to the compute, not to the management fee. EBS volumes for persistent workspaces bill at standard rates including while a session is stopped, and data transfer bills at standard EC2 rates. Confirm current rates on the pricing page before modeling anything.
That last detail undoes a tempting simplification. Stopping a session removes the instance charge but does not make the workspace free, and resuming still pays for reattachment and warm-up. A goal-level model has more terms than most estimates admit:
text
Goal cost =model inference+ tool and API calls+ active execution+ retained environment+ reconstruction work+ durable state and artifacts+ orchestration and telemetry
A goal that stays open for 14 days should not automatically hold an instance for 14 days; stop compute during long waits once progress and workspace are durable. Then check the other direction, because repeatedly cloning a large repository, reinstalling native dependencies, or re-warming GPU-backed state can cost more than keeping the environment alive. Wall-clock duration decides nothing on its own.
From "How Should This Run?" to "What Must Remain True?"
Traditional compute design asks how one execution should run: memory, timeout, concurrency, retry policy. Agentic design keeps that question and adds a second one — what must remain true until this goal is complete?
The second question produces an artifact rather than a slogan. Write down the invariants: the completion rule, the actions that must never repeat, the artifacts that must survive, the identities allowed to continue the work, the maximum acceptable rebuild time. The runtime choice usually follows from that list. Call it goal-oriented compute if a name helps; it is a design lens, not an AWS term and not a product. Its only job is to stop the goal lifecycle from being silently equated with one execution lifecycle.
A Practical Decision Sequence
- What marks the goal complete? Define the completion rule and the maximum goal lifetime independently of any compute limit.
- Is the agent computing or waiting? Separate model latency, tool calls, human approvals, external jobs, and scheduling delays. Do not allocate compute to hold a wait open.
- What must survive an interruption? Distinguish workflow progress, agent memory, artifacts, credentials, filesystem data, and live process state — then check whether your own deployment process destroys any of them.
- Can the next execution rebuild what it needs? Estimate rebuild time, data transfer, dependency installation, cache warming, and the probability that a rebuild fails.
- Are external actions safe to repeat? Define operation identities, idempotency keys, status lookup, reconciliation, and compensation before enabling automatic retries.
- Does co-location cross a trust boundary? Agents from different tenants or privilege levels should not share an instance because file exchange is convenient.
- Can one stage use a different lifecycle? Keep the goal durable and grant persistence only to the stage that needs it.
This sequence eliminates more options than a feature comparison does.
Conclusion
Do AI agents still belong in serverless? Yes — provided goal durability is not confused with compute continuity.
Some agents finish inside one ephemeral execution. Others need a durable goal whose executions appear only when there is work to perform. A smaller set benefits from a persistent or restorable environment because rebuilding its workspace, dependencies, hardware context, or shared filesystem is expensive or unsafe.
Runtime instances widen the managed options for that last group. They do not make long-lived compute the default, and they do not weaken the case for Step Functions, Lambda durable functions, or disposable microVMs. AgentCore's own design makes the point: a session can outlive the compute behind it.
The durable requirement belongs to the goal and its recovery record. The compute underneath can stay serverless whenever the next execution can rebuild what it needs, reliably and at a cost you are willing to pay.
References
Product capabilities, limits, and billing dimensions below were verified against AWS official sources on August 22, 2026.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article