A serverless environment for agents
This is the argument, and it is the strongest writing in the platform's corpus — 23 briefs and roughly 53,000 words, mostly between 30 April and 16 May 2026. It is also the part with the least code behind it, which is worth saying at the top rather than at the bottom.
The positioning, in its own words
“A serverless environment for agents, with the isolation, observability, and substrate control that agent workloads actually need.”
And the market it is explicitly not in:
“We are not competing for the generic developer-platform market (Vercel, Cloudflare Workers, Lambda)… We are competing for the agent-deployment market.”
That is a sharper position than most infrastructure projects manage, and it is defensible because the workload genuinely differs. Agent runs last seconds to minutes rather than milliseconds. They need a real filesystem and, often, a real browser. They care more about isolation and substrate control than about the last 400 milliseconds of cold start.
The definitional move, made explicitly
The whole argument rests on one definition, and it is worth stating rather than assuming, because it is doing real work:
“Serverless = no servers running when there is no traffic, with a defined cost to start serving traffic and ongoing per-invocation cost while traffic is served.”
Note what that does not say. Nothing about functions. Nothing about managed runtimes. Nothing about a vendor's execution model. That is the move that lets an EC2 instance which terminates itself after an hour count as serverless — and it is a fair move, but it should be made in the open, because a reader who arrives with Lambda's definition in mind will otherwise think a sleight of hand has occurred.
The trade, stated honestly
“The trade-off Lambda makes is ‘less control, smaller startup tax, fully managed.’ Our composition makes a different trade: more control, slightly longer first-call cold-start, broader workload range, and per-substrate optimisation.”
And the sharper version of the same point:
“Lambda's 100ms cold-start is impressive but irrelevant for most agentic workloads (which run for seconds or minutes anyway).”
Then the claim the whole comparison leans on:
“Containers do not have this problem. A single container can serve hundreds of parallel requests trivially. The cold-start is paid once per container, not once per request.” … “the workhorse substrate is a container, not a function.”
That claim is argued and never measured. There are no load tests anywhere in the repository. It is stated here as a design expectation, not a benchmark.
It is also the claim most likely to be wrong in an interesting way, because every browser request launches a fresh Chromium process: the concurrency ceiling here is memory, not the web framework. Q2, published unresolved.
The cold-start ladder, against its own benchmark
The corpus's most useful single table — and the site's chance to check it, because the same repository contains 24 real boot measurements.
| Substrate | Claimed cold start | Status in the tree |
|---|---|---|
| EC2 cold | 30–60 s | implemented |
| EC2 from warm pool | 5–15 s | not implemented |
| Fargate cold | 10–30 s | partial — an experiment |
| Container on a running EC2 | 1–5 s | implemented |
| Cached-image restart | 100–500 ms | — |
| Firecracker snapshot restore | < 50 ms | future |
The measured reality beats the ladder's own top implemented rung. Twenty-four real runs put EC2 cold start at ~16 seconds, not 30–60. The ladder is pessimistic against its own benchmark — and the warm-pool rung it promises 5–15 seconds from does not exist. The measurements, with the seven that failed →
The 50-second number, and what it buys
“The 50-second end-to-end provisioning is the number that matters most. It is not as fast as Lambda (sub-second cold start), not as fast as Fargate (10–30s), but it gives a dedicated EC2 instance per-vault with full control, isolation, and a stable DNS name.” … “the ‘click and you have a dedicated environment’ pattern (where 50s is a fair trade for the isolation).”
That is the product claim in one sentence, and it is honest about what it is trading. The instance itself is up in ~16 seconds; the other 34 are provisioning, DNS and health-checking, which is where anyone wanting the number down would have to look.
The workload classes — and the catalogue is the same argument told twice
The serverless brief names seven: vault apps, agents, AppSec mini-tools, demo environments, CI workloads, multi-region testing, and security scanners in Nitro Enclaves.
Look at that list next to the spec families and the join is obvious — vault specs, browser specs, LLM specs, observability specs. The workload list and the spec list are the same argument told twice. So each class links to the spec that serves it, and the ones with no spec are the roadmap:
| Workload class | Served by |
|---|---|
| Vault apps | vault_app, vault_publish |
| Agents | local_claude, docker |
| AppSec mini-tools | docker, podman, mitmproxy |
| Demo environments | vnc, neko, open_design |
| CI workloads | playwright, firefox |
| Multi-region testing | content_proxy, mitmproxy |
| Security scanners in Nitro Enclaves | no spec — research only |
The best unbuilt idea in the corpus
“We do not need a serverless ‘control plane’ running 24/7. The control plane is one specific role that can spin up itself on demand, do its work, and shut down. The DNS layer is the always-on piece (cheap; effectively free); everything else is on-demand.”
And from the naming brief, four months earlier and in fewer words:
“An interesting property: the Ephemeral Compute control plane should be able to run inside Ephemeral Compute… This is recursion, but it is also practical.”
Nobody has built it. It follows directly from the architecture, and a platform that can host its own control plane is a much stronger claim than one that cannot. Whether it should be built is Q1 — a control plane that must exist in order to start itself has a bootstrap problem, and the honest answer is probably the one the serverless brief already describes: the DNS layer plus one small always-on waker, everything else ephemeral.
Three adjacent bets
Nitro Enclaves — the confidential-compute tier
3,480 words, 15 May 2026. It carries the best customer sentence in the whole corpus:
“Run your security scan against your private repository. The scanner code is open source. The enclave's attestation proves it is the exact code you can inspect. We cannot see your code, even though it ran on our infrastructure.”
That is the zero-knowledge argument the rest of the estate is built on, extended to compute — and it is the thing that would distinguish this from every generic runner. No spec, no code.Firecracker — with a fact that changed the economics
3,222 words plus 2,607 of research, 15 May 2026.
“AWS nested-virt support on C8i/M8i/R8i (Feb 2026) collapsed Firecracker entry cost from $3+/hour to ~$0.09/hour.”
The bottom rung of the cold-start ladder — sub-50ms snapshot restore — stops being theoretical when the entry cost drops 30×. Still research. And fifteen months old, so the market has moved.AgentCore — layering rather than competing
2,980 words, 15 May 2026. Where SG/Compute sits on top of Bedrock rather than against it. Worth publishing as positioning, and worth re-checking before anyone acts on it: this material is fifteen months old and that market in particular has not stood still.
The sentence that belongs with all of it
“The composition is not built yet, but the gap is integration, not new invention.”
Fifteen months later that is still the right sentence, and the audit says exactly why: the pieces are real, and warm pools, multi-node stacks, non-EC2 platforms and the artefact sinks are the integration that has not happened.