# Zero Cold Starts: Serverless AI Agents on Akamai Functions

Thorsten Hans, Akamai | AI Engineer | 22:37

Source: https://www.youtube.com/watch?v=Zf_e45GiNCE
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/zero-cold-starts-serverless-ai-agents-on-akamai-functions
Published: 2026-10-10
Tags: deployment, latency, mcp

## TL;DR
- WebAssembly gives AI agents and MCP servers small, portable binaries that run quickly in a sandbox.
- Spin provides the CLI, runtime, and language SDKs for building WebAssembly applications, while Akamai Functions distributes them globally with no cold starts.
- wasmcp lets developers define tools in TypeScript, Rust, or Python, compose a complete MCP server, test it locally, and deploy it worldwide with one command.

## Summary
Thorsten Hans presents an edge-native approach to running MCP servers and AI agents. He describes the problems with regional deployments, including uneven latency, cold starts, overprovisioned infrastructure, and proprietary platform SDKs. His proposed stack uses Spin to build WebAssembly applications and Akamai Functions to run them globally. WebAssembly provides small, portable binaries with sandboxing, while Spin supplies the developer tooling and runtime. In a live demo, Hans scaffolds an MCP server with wasmcp, implements a tool in TypeScript, composes the server, tests it with MCP Inspector, and deploys a Rust-based decision-tracking server to Akamai Functions. He then connects it to the Zed editor. The final demo uses the Vercel AI SDK and a model on a Linode GPU. Hans also explains how memory snapshots preload the JavaScript runtime and dependencies. The talk is practical, though the platform claims come from Akamai's own product description.

## Key ideas
### Regional deployments create latency and scaling problems for global AI applications
[00:56](https://www.youtube.com/watch?v=Zf_e45GiNCE&t=56s)
Hans says MCP servers and agents need fast response times, but a single-region deployment is only fast for users near that region. Containers and virtual machines can also introduce cold starts that take several seconds or even minutes when demand rises quickly. Overprovisioning reduces that delay, but leaves unused infrastructure running and increases cloud spending. Higher-level platforms can remove some operational work while introducing proprietary SDKs and deployment models that make later migration expensive.

### WebAssembly provides a small and portable server-side deployment unit
[02:37](https://www.youtube.com/watch?v=Zf_e45GiNCE&t=157s)
Hans compares WebAssembly to the relationship between containers and virtual machines. He describes WebAssembly binaries as very small, easy to distribute, fast to run, and portable. His edge-native AI stack combines Spin, a Cloud Native Computing Foundation project, with Akamai Functions as the runtime. The approach lets developers build server-side applications that can move between compatible runtimes instead of binding the application to one hyperscaler.

### Spin combines a developer CLI, runtime, and language SDKs
[03:28](https://www.youtube.com/watch?v=Zf_e45GiNCE&t=208s)
Spin has three parts in Hans's explanation. Its CLI handles the everyday developer workflow, its runtime is based on Wasmtime and can run applications locally or in constrained environments, and its language-specific SDKs help with HTTP services, databases, and other common tasks. Spin remains language agnostic. Developers can use languages that compile to WebAssembly and support the WebAssembly System Interface.

### Akamai Functions runs WebAssembly applications globally without request cold starts
[04:37](https://www.youtube.com/watch?v=Zf_e45GiNCE&t=277s)
Hans describes Akamai Functions as a managed, globally distributed serverless platform. He says applications are instantiated ahead of requests and can start in less than half a millisecond on average. Developers deploy with a single command rather than configuring infrastructure with Terraform. WebAssembly provides the sandbox, so applications need explicit permission before interacting with external resources. Akamai Functions also includes a multi-tenant key-value store that is associated with the application.

### wasmcp separates MCP tool code from protocol and platform concerns
[06:32](https://www.youtube.com/watch?v=Zf_e45GiNCE&t=392s)
wasmcp provides a CLI that integrates with Spin. Developers choose a language such as Rust, TypeScript, or Python and start from a template. They implement tools, resources, and prompts while wasmcp supplies the remaining MCP components, including authentication-related pieces such as OAuth and OIDC. Hans's TypeScript example defines input schemas, lists its tools, validates incoming arguments, and returns a result from the selected tool.

### MCP servers can be composed, inspected locally, and deployed globally
[09:27](https://www.youtube.com/watch?v=Zf_e45GiNCE&t=567s)
The demo compiles the TypeScript tool into a WebAssembly component, then uses wasmcp compose to build a complete MCP server. Spin runs it locally on port 3000, and MCP Inspector connects to the endpoint, lists the tool, sends an input, and displays the result. Hans then shows a Rust decision-tracking server that uses Spin's key-value store. Local development uses SQLite, while Akamai Functions provides the globally distributed store after deployment.

### A single deployment command distributes the MCP server across service regions
[12:24](https://www.youtube.com/watch?v=Zf_e45GiNCE&t=744s)
Hans runs Spin's Akamai deployment command, names the application, and grants the terminal access to the service registry. The command creates OCI layers, uploads them, and distributes the application across service regions. Each region confirms that it received and can run the workload, starts it, and performs an internal health check. After the regions return HTTP 200, Akamai provides a public subdomain. Hans says the server is globally distributed in roughly 60 seconds, and an MCP client such as Zed can then call its tools.

### Memory snapshots reduce startup work for JavaScript agents
[18:01](https://www.youtube.com/watch?v=Zf_e45GiNCE&t=1081s)
For the agent demo, Hans uses a Spin TypeScript application with the Vercel AI SDK and a language model running on a Linode instance with a dedicated GPU. The application defines tools, gives the agent an identity and instructions, limits its steps, and generates a response. During compilation, Spin loads the JavaScript interpreter and dependencies, evaluates the global scope, and stores a memory snapshot in a WebAssembly store. The snapshot keeps the runtime and dependencies ready, at the cost of shipping the JavaScript runtime with the application.

## Notable quotes
- "What I refer to as the edge native AI stack is a combination of a CNCF project called Spin and Akamai Functions." (02:37)
- "Security is observed by WebAssembly's sandbox. So there's no way a workload could interact with external resources without us as developers explicitly granting those permissions to our workloads." (05:21)
- "So we are globally distributed in roughly 60 seconds." (13:49)
- "You can test it locally with the Spin CLI. You deploy it using a single command called spin akamai deploy. And finally, you point your clients to your MCP or to your agent." (20:36)

## Tools & references mentioned
- Spin
- Akamai Functions
- WebAssembly
- Wasmtime
- wasmcp
- MCP Inspector
- Zed
- Vercel AI SDK
- Linode
- CNCF
- WebAssembly System Interface
- OAuth
- OIDC
- SQLite
- WebAssembly Component Model
- Bytecode Alliance

## Who should watch
- You are building MCP servers or AI agents and need them to serve users in more than one region.
- You want to compare WebAssembly-based serverless deployment with containers, virtual machines, or proprietary AI platform SDKs.
- You need a concrete example of scaffolding, testing, composing, and deploying an MCP server with TypeScript or Rust.

## Related talks

- [Building Agents at Cloud Scale](https://aietalks.com/talks/building-agents-at-cloud-scale) (Antje Barth, AWS, 19:00)
- [Why Eval++ Is the Next Great Compute Primitive](https://aietalks.com/talks/why-eval-is-the-next-great-compute-primitive) (Sunil Pai & Matt Carey, Cloudflare, 24:51)
- [The Future of MCP](https://aietalks.com/talks/the-future-of-mcp) (David Soria Parra, Anthropic, 18:46)
- [The Demo I Wish I'd Had: OpenAI's Agents SDK... serverless!](https://aietalks.com/talks/the-demo-i-wish-id-had-openais-agents-sdk-serverless) (Brook Riggio, thrive.com, 17:51)
- [A2A & MCP Workshop: Automating Business Processes with LLMs](https://aietalks.com/talks/a2a-mcp-workshop-automating-business-processes-with-llms) (Damien Murphy, Bench, 1:23:14)