Zero Cold Starts: Serverless AI Agents on Akamai Functions — Thorsten Hans

Edge-native MCP servers and AI agents with WebAssembly

Thorsten Hans, senior developer advocate at Akamai, starts from the premise that MCP servers and AI agents are ordinary applications with unusually demanding latency requirements. Region-bound infrastructure works against them. Users far from the deployment region see worse latency, and containers or VMs can suffer cold starts ranging from several seconds to minutes when demand spikes. Overprovisioning hides the problem but wastes money and energy. Higher-level managed platforms reduce operational work, yet they usually come with proprietary SDKs, custom deployable units, and platform-specific conventions, which makes migration to another infrastructure complex and expensive. His answer is what he calls the edge-native AI stack: WebAssembly on the server, running on Spin and Akamai Functions.

Why WebAssembly on the server

Hans compares WebAssembly to containers in the way containers relate to virtual machines. Wasm binaries are tiny, easy to distribute, fast to start, and portable. Spin, a vendor-agnostic CNCF project, is the developer-facing side of this approach. It has three pillars: a CLI that covers the inner development loop, a runtime built on Wasmtime that can run locally, on microcontrollers, or in constrained environments, and language-specific SDKs for common tasks such as HTTP and database access. Spin itself is language agnostic, since any language that compiles to WebAssembly System Interface (WASI) can be used.

Akamai Functions is the managed, globally distributed serverless platform where these applications run. Hans claims it is the first truly serverless platform at the edge with zero cold starts. Every incoming request triggers a fresh instantiation, and the average cold start is under half a millisecond. Deployment is a one-liner with no knobs and no Terraform, and the app is distributed globally at no extra cost. Security comes from the WebAssembly sandbox: a workload cannot touch external resources unless the developer explicitly grants that permission. For persistence, the platform offers a built-in multi-tenant key-value store that is automatically associated with the app, so no credentials need to be managed.

Building MCP servers with wasmcp

Rather than hand-rolling the MCP protocol on top of HTTP, Hans uses wasmcp, a CLI that integrates with Spin. Its appeal is that developers only write business logic: tools, resources, and prompts. Non-functional concerns such as OAuth 2 and OIDC authentication are handled by ready-made components that get composed into the final server.

In the first live demo, he scaffolds a server named hello using the wasmcp new command, choosing TypeScript from Rust, TypeScript, and Python, and the default tools-only template. The generated code has three parts: an input schema for each tool, a list of tools whose descriptions must be precise so that both humans and LLMs can use them, and a call-tool dispatcher that routes requests to the right handler after validating arguments. The example tool simply prefixes its input. The build pipeline runs npm install, then make, which compiles the TypeScript into a tools WebAssembly component. That component is not yet a server. The wasmcp compose step combines it with the required components into a full MCP server, which runs locally with spin up on port 3000. Hans verifies it with MCP Inspector, listing the tool and calling it with the input foo, which returns foo with the prefix applied.

A stateful decision-log server and global deployment

The second demo is a more realistic server called decision log, written in Rust. It exposes CRUD-style tools that record and list decisions, backed by Spin’s key-value store. Locally, Spin transparently provisions a SQLite-backed store. On Akamai Functions, the same code uses the globally distributed store with no configuration changes.

Hans moves the compose step into the application manifest so that spin build handles both compilation and composition, keeping the entire workflow inside the Spin developer experience. Deployment with spin aka deploy asks for a name (he uses adr-mcp), packages the artifacts as OCI layers, and uploads them. The platform then distributes the workload to every service region, where each region confirms it can run the workload, instantiates it once, and performs an internal health check. Once every region returns HTTP 200, Akamai issues a generic public subdomain. Hans notes that the endpoint can be shielded behind other Akamai products such as Property Manager. The whole process takes roughly 60 seconds.

For the client side, he connects the server to the Zed editor as a remote MCP server, where five CRUD tools appear. He then asks the editor in natural language to record a decision and to list all decisions. Zed identifies the intent, requests permission, shows the raw input, and calls the remote server. Hans emphasizes that requests are routed to the closest service region regardless of where users are, and that the same process works with any MCP-capable client.

Agents with the Vercel AI SDK

For agents, Hans takes a different route. Instead of a dedicated CLI, he uses the Vercel AI SDK in a TypeScript Spin app. The sample is a simple game agent with two tools: a coin flip and a dice roll with a configurable number of sides. The HTTP handler loads configuration, points the agent at an Ollama instance running a large language model on a Linode GPU node, gives the agent an identity and instructions, registers the tools, sets a limit on the number of steps, and returns the generated response.

He explains the memory snapshot mechanism that keeps these JavaScript apps warm. At build time, the interpreter is loaded, the custom JavaScript is evaluated including its global scope and dependencies, and the resulting memory state is written to disk as a Wasm store. At runtime the application starts from this snapshot, so it is faster than a native JavaScript application in both cold start and runtime performance. The trade-off is that the JavaScript engine has to ship with the user code. Hans uses an optimized engine, roughly 10 MB in size, to keep that cost small.

Measured behavior

After deployment, the response headers show that the request entered the Akamai network at a point of presence in Santa Clara and was served by the closest service region, LAX. The x-envoy-upstream-service-time header reports the total time, which was 33 to 34 milliseconds on the first attempt. That attempt actually failed because of an input mistake on his side. On later calls, with the LLM actually generating responses, round trips took about 820 to 866 milliseconds, which Hans considers a realistic figure for a full loop through the model.

Developer workflow and takeaways

Hans argues that the workflow is the same whether the project is a line-of-business application, an MCP server, or an agent. Developers write code in any language that compiles to WebAssembly, including Rust, TypeScript, Python, and Go. They test locally with the Spin CLI, deploy with a single command, and point their clients at the resulting endpoint. He highlights four takeaways: portability, since Spin apps run on any WASI-compliant runtime and the stack is built on open standards governed by the Bytecode Alliance; speed, both in response times and in time to market, because developers no longer build infrastructure or implement non-functional requirements; operations that reduce to a single command, with other Spin commands available for metrics, logs, and upgrades; and a developer experience that he treats as the highest metric for the project. He also points to the Akamai developer hub for further stories and experiments.

• Tags:
• AI Agents
• Model Context Protocol
• MCP
• Serverless
• Ollama
• TypeScript
• Edge Computing
• Rust
• WebAssembly
• Spin
• Akamai Functions
• Wasmcp
• Cold Starts
• Vercel AI SDK
• Linode