Model session cardinality before choosing persistent agent compute

AWS has made AgentCore Runtime Instances generally available for sustained, resource-intensive, or specialized-hardware agents. AWS documents sessions of up to 14 days, compared with up to eight hours for its serverless microVM runtime, with EC2 costs and an additional compute-management charge (AWS announcement).

That duration is useful, but it is not enough to select the runtime. The sharper planning question is how many distinct sessions the workload creates and how each one ends.

A single independent hands-on test observed one EC2 instance and EBS set for each distinct session ID. Initial or resumed invocations took 44–107 seconds in that test, stopped sessions retained billable EBS, and abandoned sessions needed explicit deletion (DevelopersIO test). Those results describe one test, not a universal performance guarantee. They nevertheless expose lifecycle questions worth resolving before adoption.

Count sessions before instances

The SGL session-cardinality worksheet below is a derived planning tool. Its thresholds are workload-specific decisions, not AWS limits or results established by the test.

Field	Record	Decision it informs
Peak concurrent session IDs	Maximum distinct IDs active at once, by time window	Expected instance and EBS cardinality if the observed one-session-per-instance behavior applies
Session duration	Median, upper percentile, and maximum active duration	Whether multi-day persistence has material value
Invocations per session	Frequency and spacing of work within one ID	Whether retained compute avoids repeated setup or mostly waits idle
Startup tolerance	Maximum acceptable initial and resumed delay	Whether provisioning behavior fits the workflow
Idle-stop behavior	Stop trigger, timeout, and restart path	How inactive sessions move between compute and retained storage
Retained EBS	Storage per stopped session and retention period	Expected storage exposure after compute stops
Deletion owner	Service, job, or operator responsible for deletion	Whether abandoned sessions have a bounded cleanup path
Expected cost unit	Per session-hour, completed workflow, or another denominator	Whether alternatives can be compared on the same basis

Start with peak concurrent session IDs rather than request volume. A workflow can issue many requests through a few durable sessions, or create many short sessions with relatively little work in each. Under the behavior observed in the independent test, those shapes imply different infrastructure cardinality even when aggregate request counts match.

Put lifecycle states on the cost model

Treat each session as a small state machine:

created → running → stopped with storage retained → resumed or deleted

For each transition, assign a trigger, an owner, a maximum residence time, and an observable record. This is an SGL operating prescription derived from the reported lifecycle behavior. It makes two different events explicit: stopping compute and deleting retained resources.

A useful scenario model separates at least four quantities:

1. Running session-hours.
2. Stopped-session storage over time.
3. Starts and resumes that enter the latency budget.
4. Sessions that miss their deletion deadline.

AWS’s announcement identifies EC2 and compute-management charges, but the supplied excerpt does not provide rates or a complete cost formula. Teams will need current pricing and their own storage assumptions before calculating totals.

Decide by workload shape

Persistent instances appear most plausible when a small, bounded set of sessions performs sustained or specialized work, the workflow benefits from a horizon beyond eight hours, and startup delay fits the operating envelope. That is a derived selection rule informed by AWS’s documented duration and positioning, not proof that the runtime will outperform an alternative.

High-cardinality, short-lived sessions deserve a separate comparison with the serverless microVM runtime. The independent tester concluded that Runtime Instances fit a small number of long-lived, heavyweight workloads better than high-volume, short-lived sessions, but that conclusion remains bounded to the reported test (DevelopersIO test).

Before committing, run the worksheet with low, expected, and peak session counts. Then test startup and resume behavior in the intended region and configuration, verify stopped-storage behavior, and exercise deletion through the same automation that will own it in operation. The result is not a generic verdict on persistent compute. It is a workload-specific answer expressed in sessions, time, retained storage, and accountable cleanup.

For teams turning that answer into a production runtime boundary, build with Super Genius Labs.