Deployment & runtime

What this looks like in practice

Your agent runs on AWS Lambda. Most invocations land on a warm container and take 1.5 seconds (the LLM call). But once a minute, a request lands on a cold container and the framework has to import: the agent library, three provider SDKs, your observability stack, your tool implementations. With a typical Python agent stack, that import takes 2–4 seconds. With a Mastra agent on a Cloudflare Worker, ~50 ms (V8 isolates start in single-digit milliseconds; the bundle adds the rest). With a Genkit Go or Rig binary, sub-100 ms. The user who lands on a cold container experiences a request two to three times slower than the warm path.

Cold start hurts most under three conditions: (1) low or bursty traffic with idle intervals long enough to scale to zero, (2) edge deployment where workers are evicted aggressively, and (3) deployments with strict end-to-end SLAs where the cold-path outlier blows your p99. Long-running servers behind a load balancer don't really care.

What this means in practice

For a long-running server behind a load balancer, none of this matters — you eat cold start once. For serverless and edge, the ranking lines up: native binaries (Genkit Go, Rig), Quarkus + GraalVM native, and Mastra on edge runtimes all land under 100 ms; .NET AOT sits in the low hundreds; plain Spring Boot JVM is ~1–2 seconds; Python frameworks all sit in the 2–4 second range regardless of which one you pick.

If your deployment target is Cloudflare Workers, Vercel Edge, or AWS Lambda with strict cold-start SLAs, the language choice — not the framework choice within Python — dominates. If you're deploying to Cloud Run or Fargate behind a fronting service that keeps containers warm, framework cold start barely shows up.

What this looks like in practice

You provision a 4 GB memory instance for your agent backend. With a Python framework whose worker is 400 MB, you can fit roughly 8 workers on the box (leaving headroom for OS, cache, etc.). With a Go binary at 30 MB per process, you could fit 100+ — but you'd typically run one process and let goroutines handle concurrency. With a JVM on Spring Boot, one ~500 MB JVM is your worker, but it parallelises CPU work across cores within that one process.

Memory matters most under three conditions: (1) cloud bills where you pay per GB-hour of compute, (2) memory-limited edge or serverless functions, and (3) long-tail workloads where idle workers stack up. For a single team's prototype it's invisible; for a platform team running this at scale it's a real number.

What this means in practice

Rust and Go binaries are an order of magnitude smaller than the alternatives. .NET AOT and Quarkus native are competitive at 80–150 MB. Mastra on Node sits in the middle. Python frameworks all cluster around 250–500 MB, with CrewAI a touch heavier because of its in-memory stateful crew model. Plain JVM (Spring Boot without native compilation) is the heaviest at 300–600 MB, but it parallelises CPU within one process so you typically run fewer workers.

For most agent workloads the LLM call dwarfs the per-request memory cost, so the per-worker number multiplied by how many workers you need is the figure that matters. Python's fixed cost per worker is the operational tax it pays at scale; the others each have their own trade-offs (JVM startup time, .NET ecosystem assumptions, Node's single-threaded model, Rust's compile times) that show up elsewhere.

What this looks like in practice

Your CI pipeline produces a deploy artifact. With a Go or Rust agent, that artifact is one statically linked binary you copy into a scratch container — total image size ~30–80 MB. With a .NET AOT agent, similar story, ~50–120 MB. With a Spring Boot jar, you ship a 50–80 MB jar and you need a JRE on the host (or you ship the JRE too, making it ~250 MB). With a Node project, you ship the source plus node_modules, typically 100–200 MB. With a Python project, you ship the source plus a virtualenv plus a Python interpreter — typically 300–500 MB once you've installed all the dependencies.

Bigger artifacts cost more storage in registries, more bandwidth on every deploy, and more time pulling images on each new node. They also tend to have more vulnerabilities to scan and patch. None of this kills you, but it adds operational drag.

What this means in practice

The simplest deploy story belongs to Genkit Go and Rig — copy one binary into a scratch container, you're done. .NET AOT and Quarkus native are nearly as clean. Mastra's edge-bundled output is similarly compact for edge deployment, though Node-mode is heavier. Python and JVM-jar deployments require a runtime to be installed on the target machine. JVM jars are genuinely portable (same jar runs on any OS with a matching JRE); Python projects with native dependencies often need to be built per target OS. Both ship bigger artifacts than native binaries.

For containerised deployments to Kubernetes / ECS / Cloud Run, image size matters practically: more bandwidth on every deploy, more disk on every node, more time before a pod is ready. For developer-laptop workflows the artifact size barely matters — Python is the most ergonomic to install and iterate on.

What this looks like in practice

For a globally distributed chatbot, you'd ideally run the agent at the edge so users get sub-100 ms first-byte latency from the geographically nearest worker. Most frameworks can't run there — the runtime simply isn't supported by the edge platform, or the cold-start tax is too high to make it worthwhile. Serverless functions (Lambda, Cloud Functions, Azure Functions) sit in between — most frameworks can run there, but cold start affects the user experience. Long-running containers behind a load balancer absorb cold start once at boot and run fine for everything.

What this means in practice

For long-running servers any of the ten frameworks works. For serverless, the ranking lines up with cold-start time — native-binary frameworks (Genkit Go, Rig, .NET AOT, Quarkus native) feel snappy on cold containers; Python feels noticeably slower; Mastra on Vercel sits in between. For edge runtimes, the picture collapses to one realistic option: Mastra. Cloudflare Workers and Vercel Edge run JavaScript / WASM, which rules out Python, JVM jars, and traditional Go / .NET deployments. For edge runtimes (Cloudflare Workers, Vercel Edge), Mastra is the only framework on this list that ships ready-to-deploy edge-compatible bundles.

What this looks like in practice

On day one of a project, a built-in dev command lets you iterate on agent code with file-watching reload, a playground UI for poking at the agent, and basic observability — useful scaffolding that you'd otherwise hand-roll. By production, most teams replace that runner with their company-standard hosting setup (Spring Boot, ASP.NET Core, FastAPI with their auth and observability middleware), so the production-runner column matters mostly for greenfield projects without that opinionation.

What this means in practice

Four frameworks ship genuinely useful dev runners with hot reload and a built-in UI: LangGraph (langgraph dev), ADK (adk web), Mastra (mastra dev), and Genkit Go (genkit start). These cut day-one scaffolding work meaningfully. For production, MS Agent Framework's Microsoft.Agents.AI.Hosting extensions and Mastra's bundled deployers are the most opinionated paths to a deployed agent — they wire ASP.NET Core or your edge platform without you writing a host. Other frameworks expect you to choose a host framework and integrate it yourself.