Edge AI with Zero Cold Starts: Deploying Globally Distributed MCP and Agents with WebAssembly

Traditional cloud architectures have long struggled with two persistent problems when deploying AI agents and MCP servers: high latency from region-bound deployments, and cold start delays from containers or virtual machines. In a technical talk, Thorsten Hans, Senior Developer Advocate at Akamai, demonstrated a WebAssembly-based, edge-native AI stack — building applications with the CNCF project Spin and deploying them globally via Akamai Functions — claiming to achieve true "zero cold starts."

Why Traditional Architectures Can't Support Global AI Agents

AI agents and MCP are fundamentally no different from other applications: they require extremely fast response times to deliver a good user experience. The problem is that once an agent service targets a global audience, region-bound architectures start showing their weaknesses.

Thorsten highlighted several key pain points. First is latency — depending on where your service is deployed, some users may have a great experience while those on the other side of the planet see significantly higher latency. Second is cold start: containers and VMs can take anywhere from a few seconds to several minutes to start, which is especially painful when you need to scale quickly to handle traffic spikes.

The typical workaround is over-provisioning — keeping large numbers of idle containers or servers on standby. But this directly inflates cloud costs and isn't environmentally sustainable. There are more advanced solutions on the market, but they often lock you into proprietary SDKs or deployment units, making migration to another cloud provider costly and complex.

WebAssembly: A New Option for the Server Side

Thorsten's solution is to bring WebAssembly to the server side. He draws an analogy: WebAssembly is to containers what containers were to virtual machines — it produces extremely small binaries that are easy to distribute, fast to run, and portable.

The stack he calls the "Edge Native AI Stack" consists of two components:

Spin is a vendor-neutral project hosted by CNCF for building server-side WebAssembly applications. It has three pillars: a CLI for developers to handle their daily inner-loop work, a runtime based on wasmtime (runnable locally, on microcontrollers, or in constrained environments), and language-specific SDKs to boost developer productivity. While it offers language-specific SDKs, Spin itself is language-agnostic — any language that can compile to WebAssembly (including the WASI interface) can be used.

Akamai Functions is positioned as the first truly globally distributed, zero-cold-start serverless compute platform. According to Thorsten, every deployed application cold-starts per request, with an average cold start time under 0.5 milliseconds. It is fully managed and developer-centric — no Terraform required, a single command deploys globally at no extra cost. Security is ensured by WebAssembly's sandbox model, where workloads cannot access external resources without explicit authorization. The platform also includes built-in multi-tenant key-value storage that is automatically associated with the application, requiring no manual credential management.

WebAssembly (WASM) was officially standardized by the W3C in 2019, designed to run compiled language code in browsers at near-native speeds. Its core feature is a stack-based virtual machine binary instruction format, with file sizes far smaller than container images (typically tens of KB to a few MB) and extremely fast loading and initialization. WASI (WebAssembly System Interface) is the key interface standard that extends WASM capabilities to the server side, led by the Bytecode Alliance. It defines a standardized way for WASM modules to access system resources like filesystems, networks, and clocks, enabling the same WASM binary to run in browsers, servers, edge nodes, and embedded devices without recompilation. Unlike containers, WASM modules don't bundle an OS layer — the sandbox boundary is enforced at the instruction level by the runtime (e.g., wasmtime), so startup overhead is essentially just memory allocation and module instantiation. This is the technical foundation for sub-millisecond cold starts.

Building MCP Servers Quickly with WasmCP

Rather than hand-writing an MCP server that implements the HTTP protocol from scratch, Thorsten recommends WasmCP — a CLI tool that integrates seamlessly with Spin. Its core value is letting developers focus purely on business logic: implementing tools, resources, and prompts, while non-functional concerns like OAuth2 and OIDC are handled entirely by WasmCP. Developers can compose a complete MCP server from ready-made components.

In the demo, Thorsten creates a project with wasmcp new, choosing from Rust, TypeScript, or Python templates. The generated boilerplate only requires defining an input schema, providing a list of tools (with precise descriptions for both humans and LLMs), and dispatching to the appropriate tool in the call tool function based on the payload. During compilation, make compiles the JavaScript code into a WebAssembly component, then wasmcp compose assembles it into a complete MCP server, and finally spin up runs it locally for verification with MCP Inspector.

Even more interesting is a "decision log" MCP example implemented in Rust. It uses Spin's key-value store — locally, Spin automatically creates a SQLite-backed key-value store, and when deployed to Akamai Functions, it seamlessly switches to the globally distributed key-value store with no configuration required. By updating the application manifest, the entire workflow reduces to spin build followed by spin aka deploy.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic to standardize how large language models interact with external tools and data sources. It abstracts exposed capabilities into three primitives: Tools are functions that LLMs can actively call, typically with an input schema and description; Resources are contextual data that LLMs can read, similar to a read-only filesystem; Prompts are predefined, reusable prompt templates. An MCP server is essentially an HTTP or SSE service that exposes these capabilities following the protocol, and AI clients (like Claude Desktop or Cursor) discover and invoke them via MCP. Because the protocol layer is standardized, LLMs don't need special adapters for each tool, and developers can wrap any business logic as an MCP tool for reuse across AI clients. WasmCP goes further by encapsulating boilerplate like protocol handshakes and OAuth2 authentication, so developers only need to implement the business logic.

One Command, Global Deployment in 60 Seconds

The deployment step is the most compelling part of this solution. After running spin aka deploy, the CLI generates OCI layers from the WASM file and application manifest and uploads them. The server distributes these to all global service regions, each of which must confirm it has received and is capable of running the workload, instantiate it once, and perform an internal health check. Once all regions return HTTP 200, the platform automatically assigns a public subdomain.

The entire process completes global distribution in about 60 seconds. Thorsten live-added the deployed remote MCP server in an MCP-enabled client, immediately seeing five CRUD tools. Through a conversation, he had the IDE call the "track a decision" tool to log a "use OAuth 2.0" decision, then used "list decisions" to read all records back — requests are automatically routed to the service region nearest to the user.

Agents Work the Same Way: Real-World End-to-End Latency

For AI agents, the process is no different in principle, and popular SDKs like the Vercel AI SDK can be used directly. Thorsten demonstrated a simple game agent built with TypeScript that can flip coins and roll dice, calling a large language model deployed on a Linode instance with a dedicated GPU (via Ollama).

Here he revealed an interesting technical detail: for interpreted languages like JavaScript, the compilation step loads the interpreter and user code, evaluates the global scope, and then snapshots the memory state into WASM. This means every WebAssembly application written in JavaScript is actually faster at cold start and runtime than a native JavaScript application. The trade-off is that the JavaScript runtime must be bundled with the user code, but they use an optimized SpiderMonkey runtime that weighs in at about 10 MB.

The measured numbers are impressive: from the response headers, the entry node was in Santa Clara and the nearest service region was LAX. The first X-Envoy-Upstream-Service-Time for pure business logic showed 33–34 ms, while a full coin-flip request going through LLM inference took approximately 820–866 ms — a remarkable end-to-end latency for a globally distributed agent that needs to call a large language model.

The JavaScript snapshot technique mentioned here is known in the WebAssembly community as "AOT snapshot" or "snapshot-based startup," implemented by teams like Fermyon in Spin's JS component. The principle: JavaScript engine initialization and global code evaluation happen at compile time rather than at runtime, and the initialized heap memory state is serialized into the data segment of the WASM binary. At runtime, the system only needs to map this memory into the address space and jump to the entry point, bypassing the V8/SpiderMonkey engine initialization that traditional Node.js or Deno must perform on every startup. The SpiderMonkey used here is Firefox's JavaScript engine — compared to V8, its WASM compilation output is smaller, making it better suited for edge scenarios. While the ~10 MB bundle size is larger than a pure Rust WASM component, it is still far smaller than a typical Node.js container image (usually 100 MB+), and the difference in cold start times is even more dramatic.

Developer Workflow and Core Value

Thorsten summarizes: whether building a regular business application, an MCP server, or an AI agent, the developer workflow is always the same — implement the application in any language that compiles to WebAssembly (Rust, TypeScript, Python, and Go are most common), test locally with the Spin CLI, deploy with a single spin aka deploy, and point your client at the service URL.

Several key values of this approach are worth highlighting:

• Portability: Spin applications run on any WASI-compliant runtime, avoiding vendor lock-in.
• Open standards: Spin is hosted by CNCF; WASI and WebAssembly are governed by the Bytecode Alliance.
• Speed and efficiency: Extremely fast response times and shorter time-to-market — developers don't need to build their own infrastructure or implement non-functional requirements themselves.
• Zero ops: No parameters to tune. Beyond spin aka deploy, the platform provides commands for metrics collection, log retrieval, upgrades, and more.

From a technical trajectory perspective, server-side WebAssembly is carving out a clear path for edge-native AI. It sidesteps the cold start pain of containers while providing a security boundary through the sandbox model. Of course, this solution is deeply tied to Akamai Functions — while Spin itself is open, the actual "zero cold start" experience still depends on a specific runtime. For AI agents and MCP services that genuinely need to serve global users with low-latency requirements, this is undoubtedly a new option worth evaluating.