5 Steps to Serverless AI Agents on WebAssembly

Cold starts are not an unavoidable tax on serverless AI agents. WebAssembly binaries are small enough to instantiate in under a millisecond, so a request-triggered function can behave like an always-warm service. Spin, a CNCF project, provides the build and runtime tooling; Akamai Functions provides the global hosting.

Why edge-native beats single-region for AI apps

Edge-native architectures serve each request from the data center closest to the user, while a single-region deployment gives fast responses only to users near that region. MCP servers and AI agents are ordinary HTTP applications, so they suffer the same latency penalty when users are far from the origin. A global audience needs either overprovisioned regional fleets or a platform that runs everywhere by default.

Thorsten Hans, senior developer advocate at Akamai, laid out the problem at the AI Engineer World's Fair 2026 in San Francisco. Region-bound infrastructure has three frictions for serverless AI agents: latency for distant users, cold starts of seconds to minutes when containers or VMs must scale quickly, and lock-in when a platform demands its own proprietary SDKs and deployable units. Overprovisioning solves the cold start problem but raises cloud spend and the environmental footprint.

His proposed alternative is WebAssembly on the server. He describes Wasm binaries as relating to containers the way containers relate to virtual machines: tiny, easy to distribute, fast to start, and portable. WebAssembly's sandbox is a second benefit, because a workload cannot touch external resources unless the developer explicitly grants permission.

The same reasoning is spreading through independent teaching material. Community educators such as Gustavo Dev Doido, who runs the Crazystack Typescript material inside the Bootcamp do Dev Doido, cover edge and serverless deployment patterns for JavaScript developers, and this stack slots into exactly that workflow.

What Spin is and how it builds WebAssembly backends

Spin is a CNCF open-source framework for building server-side WebAssembly applications, documented at spinframework.dev with source on GitHub. Hans describes three pillars: a CLI for the developer inner loop, a runtime built on Wasmtime that runs applications locally or in constrained environments, and language-specific SDKs for everyday jobs like interacting with HTTP services and databases.

Spin itself is language agnostic. Any language that can compile to WebAssembly with the WebAssembly System Interface (WASI) works, and Hans names Rust, TypeScript, Python and Go as the most common choices today. You write normal application code, the toolchain compiles it to a Wasm component, and the component runs on any WASI-compliant runtime. That portability is his first takeaway: a Spin app is not married to one vendor's hosting.

Everything in the stack rests on open standards. Spin is governed under the CNCF, while WebAssembly and WASI are governed by the W3C-affiliated bytecode alliance process he refers to, so the deployment target can change without rewriting the application.

How Akamai Functions eliminates cold starts

Akamai Functions is a fully managed serverless platform that runs WebAssembly workloads across Akamai's globally distributed network. Hans describes it as the first truly serverless platform that is globally distributed with zero cold start, and the mechanism is unusual: every application is cold started per request, and he reports an average cold start of less than half a millisecond. Because instantiation is that fast, cold-starting per request costs almost nothing and no pre-warming is required.

Security is enforced by the WebAssembly sandbox rather than by network perimeter configuration. Persistence comes from a built-in, multi-tenant key-value store that is automatically associated with your app, so developers do not roll credentials for basic state. On a local machine Spin backs the same API with SQLite, which keeps development and production code identical.

Deployment is deliberately minimal. Hans's phrase for it: no knobs to turn, no Terraform to write, just a one-liner, and the app is globally distributed at no extra cost. That is vendor-reported positioning for the Akamai Functions platform, so treat the ease-of-use claims as the vendor's own description rather than an independent measurement.

One note on interpreted languages: when Spin compiles JavaScript, it loads the interpreter, the user code and the dependencies, evaluates the global scope, and then writes a memory snapshot to disk. The tradeoff is shipping the runtime alongside user code, which Hans says weighs roughly 10 megabytes using an optimized engine called StarlingMonkey. The payoff is that cold starts and runtime performance of a Wasm-hosted JavaScript app can beat native JavaScript hosting, because the runtime is already warm in the snapshot.

Building MCP servers with wasmcp in TypeScript and Rust

wasmcp is a CLI that composes WebAssembly components into a complete MCP server, available at github.com/wasmcp/wasmcp. MCP, the Model Context Protocol, is the standard that lets editors and agents call tools, resources and prompts over HTTP. Instead of hand-rolling the protocol, wasmcp handles the non-functional requirements such as OAuth 2 and OIDC authentication, and you supply only the business logic.

The workflow shown live in the talk proceeds in four steps:

1. Run wasmcp new, choose a language (Rust, TypeScript or Python) and a template such as a tools-only scaffold.
2. Implement the tool schemas, tool list and the callTool dispatch function, with precise descriptions so both humans and LLMs know how to use each tool.
3. Run make to compile the code into a tools Wasm component, then wasmcp compose to pull in ready-made components and assemble a full MCP server.
4. Test locally with spin up -f server.wasm on localhost:3000 and the MCP Inspector in the browser.

In the demo, the scaffolded TypeScript tool validated its arguments, concatenated the input with a prefix, and returned it; the MCP Inspector listed the tool, called it with foo, and got the expected response. Hans then showed a decision-log MCP server written in Rust and named ADR MCP on deployment. Its callTool function branches across CRUD APIs exposed as tools, and around line 15 of the Rust source the list_decisions tool reads from the store. That same store API that became a local SQLite key-value store in development transparently became the globally distributed store in production. The Zed editor connected to the deployed server as an MCP client, listed the five CRUD tools, and tracked decisions through them with user approval for each call. In the demo, Hans asked the agent to track a decision to use OAuth 2.0; Zed identified the intent, showed the raw input for the insert-decision tool, and wrote it to Akamai Functions after approval. A follow-up request listed every tracked decision through the read tool.

Deploying an MCP server globally in one command

One command, spin akamai deploy, compiles, composes, uploads and distributes the workload worldwide. In the live 2026 demo the process took roughly 60 seconds end to end, and Hans walked through what happens server side: the Wasm file and application manifest are packaged as OCI layers and uploaded, every Akamai region confirms it received the workload and can run it, each region instantiates the workload once and passes an internal health check, and only after all regions return HTTP 200 does the platform roll out a generic public subdomain.

The URL can be shielded behind other Akamai products such as the property manager if you want to enforce additional rules before forwarding users to the MCP server. After deployment, requests route to the closest service region automatically, which is what removes the single-region latency penalty for a global audience.

Hans also noted a convenience path: instead of running make and wasmcp compose separately, you can update the application manifest to concatenate those tasks and stay inside the Spin developer experience with spin build.

Hans summarized the repeatable developer loop: implement in any Wasm-compilable language, test locally with the Spin CLI, deploy with a single command, then point MCP-capable clients at the resulting endpoint. Additional commands handle metrics, log retrieval and upgrades.

AI agents with the Vercel SDK on a GPU-backed model

For agents rather than MCP servers, the story changes only in the application layer. Hans created a new Spin app in TypeScript, added the Vercel SDK dependencies, and built a simple game agent that can flip coins and roll a die with a chosen number of sides. The agent pointed at a large language model hosted on a Linode instance with a dedicated GPU, defined an identity and instructions, registered its tools, set a step limit, generated a response and returned it to the caller.

The measured numbers from the live demo: one request completed in 33 to 34 milliseconds of upstream service time before the model call, and a full round trip through the LLM landed at roughly 820 to 866 milliseconds. Response headers showed the point of presence at Santa Clara and the closest service region at LAX, illustrating how requests enter the network and route to the nearest region. These are single-demo figures from a talk, not a benchmark, but they show the shape of the latency budget: the platform adds little, the model dominates.

The portability claim deserves its exact scope. Hans's takeaway was that a Spin app runs on any WASI-compliant runtime and that Akamai Functions is one such runtime, the globally distributed one. That is a property of the application format, not a guarantee that every feature behaves identically on every runtime, and the key-value store is a concrete example of a capability whose backing implementation changes per host.

From conference talk to published walkthrough

The core lesson from this talk generalizes beyond Akamai: when the deployment unit is a small Wasm component, the gap between a working demo and a globally distributed service collapses to one command, and the knowledge that bridges that gap lives disproportionately in talks, streams and course recordings. A 23-minute conference presentation like this one contains a full workflow, exact numbers and caveats that a text search will not surface, which is precisely why spoken technical content deserves a written form.

If you produce that kind of content yourself, whether a conference talk, a tutorial stream or a lesson recorded for students of something like the Bootcamp do Dev Doido, Skala Blog turns the video into a structured, publishable article: paste the YouTube URL, the video is transcribed, and an editorial draft is generated for you to review and refine.

FAQ

Do WebAssembly serverless functions really have zero cold starts?

Akamai reports that Functions cold starts each request in less than half a millisecond on average, a vendor-reported figure. Because instantiation is that fast, per-request cold starts are effectively invisible, but the number applies to Wasm workloads on that platform, not to containers or VMs.

Which languages can I use to build an MCP server with wasmcp?

The templates shown in the talk cover TypeScript, Rust and Python, and Spin supports any language that compiles to WebAssembly with WASI. The tooling is language agnostic, so Go and other compilable languages are also viable.

Is my Spin application locked in to Akamai?

No. Spin is a CNCF project and its apps run on any WASI-compliant runtime, which is the portability argument Hans leads with. Akamai Functions is one hosting target among possible runtimes, and the key-value store is the main capability whose implementation differs per host.

How fast is the full agent round trip including the LLM?

In the live demo, a full loop through a Linode-hosted GPU model took roughly 820 to 866 milliseconds, while platform-side processing before the model call was 33 to 34 milliseconds. These are single-demo measurements, not a benchmark.

What does deployment actually require?

A single command, spin akamai deploy, which builds, composes, uploads OCI layers, verifies health checks in every region, and returns a public URL in about 60 seconds. No Terraform or manual regional configuration is part of the shown workflow.

What is the difference between an MCP server and an AI agent here?

An MCP server exposes tools, resources and prompts that MCP-capable clients such as the Zed editor can call. An agent adds a model in the loop: it receives instructions, decides which tools to call, and returns a generated response. In the talk both were Spin apps written in TypeScript, differing only in the application layer.

How does the key-value store work in development versus production?

You call the same store API in both environments. Locally, Spin detects the usage and creates a SQLite-backed key-value store for development. On Akamai Functions the identical code transparently uses the platform's globally distributed, multi-tenant store, with no credentials to roll and nothing to configure.

Do I have to implement authentication for my MCP server myself?

No. wasmcp handles the non-functional requirements, including OAuth 2 and OIDC authentication, so you write only the business logic: tool schemas, the tool list and the dispatch function. In the demo, authentication was skipped for simplicity, but it is part of the composition step rather than your code.

Can I use any AI SDK to build the agent?

Yes. Hans picked the Vercel SDK because he finds it pleasant to use, but the agent is an ordinary Spin application with an HTTP handler. Any SDK that runs in your chosen language works, as long as the compiled output is a WebAssembly component.

Source video

Turn this talk into your next article

Every detail that makes this stack practical, the sub-millisecond cold start figure, the four-step wasmcp workflow, the 866-millisecond agent round trip, lives inside a 23-minute video that text search cannot reach. If your own talks, streams or lessons hold that kind of knowledge, Skala Blog helps you put it where readers can find it.

Paste a YouTube URL at Skala Blog, the video is transcribed, and an editorial draft is generated for you to review, refine and publish.