Talk by Thorsten Hans, a senior developer advocate at Akamai, on building and deploying MCP servers and AI agents with Spin, an open-source WebAssembly framework, on Akamai Functions, a serverless platform. The talk argues that WebAssembly at the edge can avoid cold starts, proprietary SDKs, and single-region deployment limits for AI apps. It covers why WebAssembly is presented as fast, portable, and sandboxed on the server; live-coded MCP servers built with wasmcp in TypeScript and Rust, tested with MCP Inspector; deploying an MCP server and an agent with one command; calling MCP tools from the Zed editor; and an agent built with the Vercel AI SDK backed by a model on a Linode GPU, plus how memory snapshots keep apps warm. Speaker's performance and deployment-speed claims are presented as demonstrations in the talk, not independently verified here. # Video Identity Observations ## Explicit Self-Description - **Creator role stated directly**: The speaker introduces himself as **Thorsten Hans**, "a senior developer advocate with Ecomi [Akamai]" — an explicit employer-affiliation claim made in the talk's opening. > "my name is Tossen. I work as a senior developer advocate with Ecomi" - **Talk format claim**: A conference-style session, self-described as ~20 minutes. > "In the upcoming 20 minutes, I want to give you an introduction on how you can build ultraast agents and MCPs with spin and run them globally distributed." ## Intended Audience - **Developers who have already built AI agents or MCP servers**: The speaker assumes prior hands-on experience. > "I guess all of you have already built either MCPS or agents and they are no different than any other kind of application." - **Backend/cloud engineers concerned with latency, cold starts, and infrastructure cost**: Framed around region-bound architecture pain points, overprovisioning, and "higher cloud spendings." - **Demo-watching practitioners**: The talk includes live terminal walkthroughs (`wmcp new`, `spin deploy`, MCP Inspector, npm install), indicating an audience comfortable following CLI-driven demos. ## Claimed Scope of the Channel/Content - **Topic scope**: Building serverless AI agents and MCP servers using **Spin** (CNCF WebAssembly framework) and **Akamai Functions**, deployed globally at the edge. - **Cross-language positioning**: The content claims coverage across Rust, TypeScript, and Python. > "you can write those tools or prompts or resources using TypeScript, Python or Rust templates." - **Product-adjacent promotional scope**: Directs viewers to Akamai properties — `spinframework.dev`, `developers.akamai.com`, trial signups via QR codes, and an in-person Akamai booth. ## Creator Claims vs. Demonstrated Patterns ### Claims made by the creator (unverified in this material) - **"Zero cold starts"** and sub-half-millisecond cold starts: > "every application that you deploy to Ecomi functions is cold started per request... on average we can cold start in less than half a millisecond." - **Global distribution in ~60 seconds**: > "we are globally distributed in roughly 60 seconds." - **JavaScript WASM apps faster than native**: > "every web assembly application written in JavaScript is faster than a native JavaScript application when it comes to cold starts and runtime performance." ### Observable demonstrations in the video - A **live local MCP demo** ("hello" server built with `wmcp`, tested via MCP Inspector returning "foo") that visibly works. - A **live deployment demo** of a Rust "decision lock / ADR MCP" server, wired into a client ("Z") and executing `insert decision` and `list decisions` tools in real time. - A **live agent demo** (coin-flip/dice game agent using Vercel AI SDK and a Llama LLM on a GPU Linode), showing response headers and ~820–866ms full-loop latency, including one **acknowledged user error** mid-demo. > "Oh, there's an internal server error... the error was staying 30 cmters in front of the screen." ## Presentation Style (Observable) - **Technical, hands-on, vendor-affiliated**: Combines slide-style explanation with live coding, terminal output, and QR codes — consistent with a developer-advocacy conference talk rather than an independent tutorial. - **Transparent about demo friction**: The speaker openly attributes an error to himself, an observable credibility-preserving presentation choice. - **Closing call-to-action**: Points to `developers.akamai.com` and the Akamai booth, indicating the channel context is tied to Akamai's developer ecosystem. # Delivery Observation: Thorsten Hans — "Zero Cold Starts: Serverless AI Agents" ## Overall Delivery Style - **Conversational, talk-through style**: The speaker narrates continuously while demoing, using fillers and connectives ("So", "Um", "right?") at a high rate — e.g., *"So, but there's a solution to that..."*, *"and basically do a spin build to compile compose and compile my MCP server."* - **Tag questions to keep the audience engaged**: *"depending on your distributable unit, right?"*, *"But ultimately you gain speed, right?"*, *"you can see... right, I have to define my tools."* ## Recurring Vocabulary and Phrases - **"Nothing fancy"** — a clear repeated phrase used to downplay demo complexity: > *"Nothing fancy. So let's close the editor..."* and again *"Great. Nothing fancy cool works."* - **"Globally distributed"** — the talk's core selling point, repeated many times: *"a globally distributed MCP server"*, *"your app is globally distributed at no extra cost"*, *"So we are globally distributed in roughly 60 seconds."* - **"Developer experience" / "developer centric" / "developer productivity"** — recurs across sections: *"developer experience is our our highest metric."* - **"Cold start"** — used pervasively, matching the title: *"has zero cold start at all"*, *"cold started per request"*, *"when it comes to cold starts."* - **"So we have to be good citizen over here"** — colloquial teaching framing for best practices. ## Teaching Habits - **Live coding as the backbone**: Extended terminal/editor demos form most of the talk — scaffolding with `wmcp new`, `npm install`, `spin up`, `spin aka deploy`, and client testing. - **QR codes for follow-up resources**: *"So scan this QR code and you will end up on the spin documentation"*, and later *"Again, there is a QR code. Scan that..."* - **Explicit roadmap statements**: *"In the upcoming 20 minutes, I want to give you an introduction on..."* and *"So these are the technical underpinnings that I want to use in order to build first MCP servers."* - **Concrete numbers for credibility**: *"less than half a millisecond"*, *"roughly 60 seconds"*, *"33 34 milliseconds"*, *"roughly 820 milliseconds"*, *"roughly 10 megabytes in size."* - **Analogy to explain new concepts**: *"You can think of web assembly as um as containers relate to virtual machines."* - **Structured takeaways at the end**: *"final or key takeaways from my from my point are portability... Everything is based on open standards... But ultimately you gain speed."* ## Live-Demo Communication Patterns - **Thinking aloud during demo friction, including self-corrections**: > *"let me no this is wrong. I want this and then I want to do that uh decision."* - **Humor when errors occur on stage**: > *"Oh, there's an internal server error. Great. Awesome. Let's try this again. Oh, yeah. That was an user error. Sorry. So, the error was staying 30 cmters in front of the screen."* - **Light celebration of small wins**: *"There we go... Great."*, *"Tails tails tails tails. Oh, there's a hat. Nice."* - **Instructional narration of what the audience sees**: *"So what do we get over here? Uh we get a boiler plate that's uh ready to use..."* ## Isolated Moments (Low Confidence as Patterns) - The humorous recovery after the internal server error appears only once; it shows how he handles live-demo failure, but one instance is not enough to claim it as a stable habit. - The closing invitation (*"find me at the Akcomi booth"*) is a single conference-specific closing routine, not observable as a repeated pattern from this transcript alone. ## Uncertainty Notes - Repetition is well evidenced for "nothing fancy," "globally distributed," and the tag-question habit (multiple exact instances each). - Claims about emotional tone, enthusiasm, or motivations are not made, as they are not directly observable from the transcript. # Video Position Record: Serverless AI Agents on Akamai Functions **Source:** Video `01a15ca6-af55-7bbc-bd32-4c4f062f7313` **Speaker:** Thorsten Hans, identified by the curated title. The transcript renders the name as "Tossen." Affiliation as stated in the talk: senior developer advocate at Akamai (transcribed as "Ecomi"). **Format:** Single-speaker conference talk with a live demonstration (~20 minutes) **Scope:** Positions, reasoning, and claims as expressed. No inference about private motivation. --- ## 1. Core Thesis The speaker argues that AI agents and MCP (Model Context Protocol) servers should be built as **edge-native, globally distributed** workloads using **WebAssembly**, specifically with the **Spin** framework and **Akamai Functions**. > "So there are higher level solutions... but they usually or often come with proprietary SDKs or uh deployable units..." **Reasoning chain as stated:** 1. Agents and MCP servers demand fast response times. 2. Region-bound architectures serve a global audience poorly, so latency varies by user location. 3. Containers and VMs incur cold-start delays, which can range from seconds to minutes under sudden scale-up. 4. Overprovisioning mitigates cold starts but raises cloud spend and is described as "not sustainable from an environmental footprint." 5. Higher-level platforms often impose proprietary SDKs or deployment models, which make migration "rather complex and extremely costly." 6. WebAssembly offers a portable alternative. --- ## 2. Claims About Problems With Current Infrastructure ### 2.1 Latency - **Claim:** Deployment location determines latency, so some users get "way worse user experience." - **Basis:** Stated as an general observation; no data cited. ### 2.2 Cold Starts - **Claim:** Containers and VMs may have cold-start delays "from several seconds up to multiple minutes." - **Basis:** Stated as a general range; no source cited. ### 2.3 Overprovisioning - **Claim:** Overprovisioning is a workaround with costs. - **Qualification:** The speaker describes this as a tradeoff ("we can overcome that obviously... however"), not as a solved problem. ### 2.4 Vendor Lock-in and Migration - **Claim:** Moving workloads between hyperscalers is "often rather complex and extremely costly." - **Basis:** Experiential assertion; not quantified. --- ## 3. Technology Positions ### 3.1 WebAssembly - **Analogy stated:** WebAssembly relates to servers as containers relate to virtual machines. - **Properties claimed:** Binaries that are "super tiny in size, easy to distribute, super fast to run and portable." ### 3.2 Spin (CNCF Project) The speaker describes Spin as having three pillars: - **CLI:** Covers the developer "inner loop." - **Runtime:** Based on Wasmtime; runs locally, on microcontrollers, or in constrained environments. - **Language SDKs:** Support for HTTP, databases, and similar tasks. **Claim:** Spin is "vendor agnostic" and "language agnostic," supporting any language compiling to WebAssembly/WASI. ### 3.3 Akamai Functions Claims made about the platform: | Claim | Speaker's Wording | |---|---| | Serverless and globally distributed | "the first truly serverless computing platform that is globally distributed" | | Zero cold start | "has zero cold start at all" | | Cold start speed | "on average we can cold start in less than half a millisecond" | | Deployment simplicity | "just a simple oneliner" | | Pricing | globally distributed "at no extra cost" | | Security | WebAssembly sandbox; permissions must be explicitly granted | | Persistence | Built-in multi-tenant key-value store, auto-associated with the app | **Tension to note:** The speaker says "zero cold start" and also says every request triggers a cold start (under half a millisecond). These are presented together without reconciling the terms. The speaker's definition of "cold start" is not explicitly stated. --- ## 4. The MCP Argument ### 4.1 Build Approach - **Position:** Rather than hand-rolling MCP over HTTP, use the **wmcp** CLI. - **Division of labor stated:** Developers focus on business logic (tools, resources, prompts). wmcp handles non-functional requirements, such as authentication (OAuth 2 and OIDC), and composes the final component. ### 4.2 Demonstrated Workflow 1. Scaffold a project (`wmcp new`), choosing a language and template. 2. Implement tools in the generated code. 3. Compile and compose (`make`, then MCP compose), or integrate into the Spin manifest via `spin build`. 4. Run locally (`spin up`) and verify with the MCP Inspector. 5. Deploy (`spin aka deploy`), which the speaker says globally distributes the app in "roughly 60 seconds." ### 4.3 Local vs. Platform Behavior - **Stated:** Locally, Spin creates a SQLite-backed key-value store automatically. On Akamai Functions, the same code uses the distributed store "without me having to configure anything." ### 4.4 Demonstration Outcome - The speaker showed a decision-tracking MCP server (Rust) with five CRUD-style tools. - An IDE client invoked the tools, requesting permission before each call. - **Claim:** Requests route "to the closest service region no matter where your users are." **Limitation:** The demo used one client and one server. No multi-region load testing was shown. --- ## 5. The Agent Argument ### 5.1 Approach - Use any popular SDK; the speaker prefers the Vercel AI SDK (TypeScript). - The demo agent is a "simple game agent" with coin-flip and dice-roll tools. - The model is a large language model (LLM) hosted on a Linode instance with a dedicated GPU, accessed via an Ollama endpoint. ### 5.2 Cold-Start Explanation The speaker explains that JavaScript runtime and dependencies are loaded at compile time, and a memory snapshot is written to disk. Consequently: > "every web assembly application written in JavaScript is faster than a native JavaScript application when it comes to cold starts and runtime performance." - **Stated tradeoff:** The JavaScript runtime must ship with user code. The speaker uses **SpiderMonkey**, which he describes as "roughly 10 megabytes." - **Qualification:** The "faster than native" comparison is asserted, not benchmarked in the talk. ### 5.3 Latency Observations (Demo) | Run | Reported Latency | Speaker's Assessment | |---|---|---| | First request | ~33–34 ms | Not valid. The speaker attributes the result to a user error (the request was not an actual LLM round-trip). | | Retry | ~866 ms | "More realistic" because it included the LLM call | | Subsequent tosses | ~820 ms | Speaker's stated figure for a full loop through the LLM | **Headers mentioned:** - Point of presence: Santa Clara - Closest service region for the agent: LAX - `x-envoy-upstream-service-time`: used to read the server-side timing **Qualification:** These numbers come from a single demo environment, one client location, and a sample of about three requests. The speaker presents them as illustrative, not as general performance claims. --- ## 6. Developer Workflow (Speaker's Summary) 1. Implement in any language that compiles to WebAssembly (Rust, TypeScript, Python, Go named as most prominent). 2. Test locally with the Spin CLI. 3. Deploy with `spin aka deploy`. 4. Point clients at the deployed endpoint. --- ## 7. Key Takeaways (Speaker's Stated Conclusions) - **Portability:** Spin apps run on any WASI-compliant runtime. Akamai Functions is described as one such runtime. - **Open standards:** Spin, WASI, and WebAssembly are described as governed by the **Bytecode Alliance**. Spin is described as a CNCF project. - **Speed:** Fast response times, and reduced time to market because infrastructure and non-functional requirements are handled elsewhere. - **Operations:** Described as minimal ("spin aka deploy is all you need"), with additional commands for metrics, logs, and upgrades. - **Priority:** Developer experience is named as "our highest metric." --- ## 8. Unresolved Points and Caveats - **Vendor perspective:** The speaker works for Akamai and presents the platform. Claims such as "zero cold start," "no extra cost," and "less than half a millisecond" are product claims, not independently verified in the talk. - **Cold-start terminology:** "Zero cold start" and "cold start per request" are used together without definition. - **Cost claims:** "At no extra cost" is stated without specifics on pricing tiers or conditions. - **Sustainability:** The environmental argument against overprovisioning is asserted without data. - **Benchmarks:** Latency figures are from a single demo session. The speaker corrected one figure during the demo, so the record should treat the 33–34 ms result as invalid per his own assessment. - **Security:** The WebAssembly sandbox is described as preventing unauthorized external interaction. The talk does not address supply-chain or dependency risks. - **Transcription artifacts:** Several product and tool names are garbled in the transcript (e.g., "Ecomi," "echcomi," "Z" as a client name, "stalling monkey" for SpiderMonkey, "Wii" for WASI, "Verscel" for Vercel). Recorded here in corrected form where the context is unambiguous. --- ## 9. Source Basis Summary | Section | Primary Source | |---|---| | Problem framing | Transcript, opening segment | | Spin and Akamai Functions claims | Transcript, technology segment | | MCP workflow | Transcript, live demo segment | | Agent workflow and latency | Transcript, agent demo segment | | Takeaways | Transcript, closing segment | | Speaker identity and affiliation | Curated title; transcript self-reference | # Speaker Attribution and Provenance Observations **Video ID:** `01a15ca6-af55-7bbc-bd32-4c4f062f7313` **Title:** Zero Cold Starts: Serverless AI Agents on Akamai Functions, Thorsten Hans **Transcript basis:** Auto-style transcript only. No timestamps, speaker labels, or curated metadata were supplied beyond the title. --- ## 1. Speaker Inventory ### Primary Speaker - **Name (per title):** Thorsten Hans - **Name as transcribed:** "Tossen" (transcription variant; the title is the more reliable identifier) - **Stated role:** Senior developer advocate - **Stated affiliation:** Transcribed as "Ecomi" and variants ("Echcomi," "Akcomi"). The title identifies the platform as **Akamai Functions**, so the affiliation is most likely Akamai, but the transcript itself does not spell it correctly. - **Speaking mode:** Single presenter giving a live-demo talk of about 20 minutes, which the speaker frames as an introduction. ### Other Voices - None identified. The transcript contains no second speaker, guest, moderator, or audience Q&A. - A closing `[music]` marker appears, with no attributed speaker. --- ## 2. Referenced Sources and Named Artifacts The speaker names or displays the following. None was independently verified in this record. | Referenced item | How it appears | Speaker's characterization | |---|---|---| | **Spin** | Named throughout | CNCF project, vendor-agnostic, WebAssembly framework | | **spinframework.dev** | Spoken; QR code shown | Spin documentation | | **Akamai Functions** | Title and speech | Globally distributed serverless platform | | **WMCP / wasmcp** | Spoken as "wmcp," shown as `github.com/wmcp/wasmcp` (transcribed as "wmcpwasmcp") | CLI integrating with Spin for MCP servers; URL rendering is uncertain | | **MCP Inspector** | Run via `npx` on screen | Used to test the local MCP server | | **Vercel AI SDK** | Transcribed as "Verscel AI SDK" | Recommended SDK for building agents | | **LLM host** | Transcribed as a Linode ("Lenode") instance with dedicated GPU | Hosts the large language model used by the agent | | **Ollama-style LLM server** | Transcribed as "old lama" | Named as the LLM endpoint; the exact product is unconfirmed by the transcript | | **SpiderMonkey-class JS runtime** | Transcribed as "stalling monkey," described as ~10 MB | Optimized JavaScript runtime used in compilation; the name is a likely transcription error | | **Bytecode Alliance** | Spoken | Governs Spin, WASI, and WebAssembly | | **Property Manager** | Spoken | Akamai-style product mentioned as an optional shield in front of MCP servers | | **Client application** | Transcribed as "Z"; configured as a "remote" MCP server | Client used for the demo; identity unclear from transcript | | **Akamai developer hub** | Spoken as "developers.accomi.com" and "ecomi.com" | Platform's developer site; URL transcribed inconsistently | --- ## 3. Third-Party and Vendor Claims The following are assertions made by the speaker. Each is recorded as a claim, not as verified fact. ### Performance and Infrastructure Claims - Traditional region-bound architectures create latency problems for global audiences. - Containers and VMs can incur cold-start delays from several seconds to multiple minutes. - Akamai Functions has **zero cold starts**, with an average cold start of **under half a millisecond**. - Applications deploy globally in roughly **60 seconds** at no extra cost. - Compiled JavaScript snapshots (global scope pre-evaluated) make WebAssembly-hosted JavaScript faster than native JavaScript for cold starts and runtime. ### Observed Measurements (Speaker-Reported) - An agent request showed `X-Envoy-Upstream-Service-Time` of about **33–34 ms** on the first attempt. The speaker then attributed the resulting internal server error to user error. - A subsequent request measured about **866 ms**, described as more realistic because it included an LLM round trip. - A later loop was described as roughly **820 ms**. - Point of presence: **Santa Clara**. Closest service region for the agent: **LAX**. Both are read from response headers on screen. ### Ecosystem and Standards Claims - Spin is described as a CNCF project and vendor-agnostic. - WebAssembly is described as portable, tiny, and fast, comparable to containers relative to VMs. - Open standards are described as the basis for portability across any WASI-compliant runtime. --- ## 4. Promotional Segments **The entire talk is vendor-delivered by an Akamai developer advocate.** The following segments are explicitly promotional. ### Explicit Promotional Content - **Akamai Functions pitch:** Positioned as "the first truly serverless computing platform that is globally distributed and has zero cold start at all." - **Sign-up call to action:** QR code and spoken instruction to "sign up for a trial or a free account." - **Product feature claims:** "No knobs to turn, no Terraform to write," built-in multi-tenant key-value store, and Property Manager as an optional shield. - **Developer hub and booth:** Viewers are directed to the Akamai developer hub and to "find me at the Akamai booth." - **Documentation QR code:** Directs viewers to the Spin documentation site. ### Integrated Promotional Demonstrations - The MCP and agent demos run exclusively on Akamai Functions, with product-specific features shown as part of the workflow. - Comparisons are between Akamai Functions and unspecified alternatives ("higher-level solutions," "other hyperscalers"). No named competitors are cited. --- ## 5. Provenance and Availability Limits ### Missing or Unverifiable Information - **No curated metadata** beyond the title and video ID was supplied. - **No upload date, channel, or conference name** appears in the record. - **No timestamps** in the transcript, so claims cannot be located precisely in the video. - **No speaker labels** beyond the single presenter inferred from context. - **No slide or screen-share text** is captured. Several demo steps reference on-screen content that the transcript does not reproduce, including the MCP Inspector output, file contents, and the client UI. ### Transcription Reliability - Product and proper names are inconsistent: "Ecomi," "Echcomi," "Akcomi," "Echi," and "Akamai" all appear for the platform. - The speaker's name appears as "Tossen" in the transcript and "Thorsten Hans" in the title. - Several technical names are transcribed phonetically ("Verscel," "Lenode," "old lama," "stalling monkey"). These should be treated as uncertain until checked against the video. - Some passages are garbled or ambiguous, including the client name and the reason for the coin-flip error. ### Comment Availability - **Not supplied.** No comment data, moderation status, or audience feedback is included in this record. ### Evidence Channels Unavailable to This Record - Visual content (slides, terminal output, client UI, QR code destinations). - Audience interaction or Q&A. - Any independent verification of performance figures, product claims, or source URLs. Welcome everybody. Thanks for joining my talk. In the upcoming 20 minutes, I want to give you an introduction on how you can build ultraast agents and MCPs with spin and run them globally distributed. So my name is Tossen. I work as a senior developer advocate with Ecomi and um I guess all of you have already built either MCPS or agents and they are no different than any other kind of application. So they obviously demand super fast response times so that we can deliver the best possible user experience. However, traditional regionbound architectures or infrastructures fall short when you want to address a global audience and they they come with some frictions which lead to the inception of edge native architectures. So obviously latency is one of the biggest concerns depending on where you deploy your MCPs or your agents. It might be fast for a subset of your global audience, but others might experience a way lower latency and resulting in a way worse user experience. Um, depending on your distributable unit, right? Even so, if you even either choose containers or VMs, you may experience a cold start delay that might range from several seconds up to multiple minutes, especially when you have to scale dramatically fast to meet unexpected user demand. However, we can overcome that obviously uh by overprovisioning the infrastructure. However, keeping around many many containers or servers and actually not utilizing them results in obviously higher cloud spendings and is not sustainable from an environmental footprint. So there are higher level solutions uh that we can use to run MCPS or agents but they usually or often come with proprietary SDKs or uh deployable units or have their own way on how you should treat them in order to make them work in a production grade environment. Once you figured out about those constraints, moving away or migrating your workloads, your agents to another hyperscala to another kind of infrastructure, it's often rather complex and extremely costly. So, but there's a solution to that and that solution involves a new way of how we as engineers could build backend or serverside applications and this is done by adopting web assembly on the server side. You can think of web assembly as um as containers relate to virtual machines. So, they are binaries super tiny in size, easy to distribute, super fast to run and portable. What I refer to as the edge native AI stack is a combination of a CNCF project called spin and echcomi functions. One runtime where you can run those web assembly applications. So let's dive into spin for a minute. Uh spin as I said is a CNCF project that is vendor agnostic and it allows you to build web assembly applications that are meant to be executed on the server or in the cloud. Spin itself consists of three major pillars. So it is a CLI that we as developers use to address all our day-to-day concerns. So everything you know in the realm of the inner loop. It is a runtime. So it's based on WM time um that allows us to run these kinds of applications either locally or on microcontrollers or constrained environments. Last but not least, Spin gives us language specific SDKs to boost the developer productivity when it comes to day-to-day jobs like for example interacting with HTTP services, integrate interacting with databases or different kind of things. Although we have language specific SDKs, spin itself is language agnostic and you can choose from all the languages that are able to be compiled down to web assembly including the web assembly system interface or shortwi and you can learn more about spin on spin framework.dev. So scan this QR code and you will end up on the spin documentation. So spin is the developer tool that we use for building these kinds of applications. Echi functions is the first truly serverless computing platform that is globally distributed and has zero cold start at all. So every application that you deploy to Ecomi functions is cold started per request that hits your endpoint and on average we can cold start in less than half a millisecond. It's fully managed and it's again developer centric. Your developers deploy the workload. No knobs to turn, no terraform to write, just a simple oneliner and your app is globally distributed at no extra cost. Security is um is observed by web assembly'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. And to be a full-fledged serverless computing platform at the edge, we need some kind of persistence layer. So Echami functions comes with a built-in key value store that is again multi-tenant. You don't have to roll credentials. It is automatically associated to your app if your intent is to use it. Again, there is a QR code. Scan that and you can find out more about Echo My Functions. Sign up for a trial or a free a free account there and you know explore it. So these are the technical underpinnings that I want to use in order to build first MCP servers. So instead of handrolling a new MCP server, I mean we can implement the HTTP protocol or the uh the specified API on top of HTTP to build an MCP. There is a smarter way of doing that and a smarter way is WMCP. WMCP again is a CLI that integrates seamlessly with spin. So what it what this allows us to do is basically to focus just on the business logic and in in the in the realm of an MCP business logic basically means we implement our tools we implement our resources or prompts and we are good to go everything else all those non-functional requirements that we have to tackle right like for example authenticating users using of 2 and OIDC that's done by WMCP and we then take readyto-use components off the shelf and compose a final MCP server component together and run that on spin or on a myi functions and that's what we are going to do right now. So I have installed wmcp on my machine it's github.com wmcpwasmcp and it gives you a nice little CLI. So we can do womcp new. We can choose a language, Rust, TypeScript, uh, Python. And we can choose from templates. The default template is me only caring about tools for now. And let's call this new MCP server hello. We get instructions. Hey, move into hello. Uh, hello. Then let's open up a new terminal on this side. CD into hello over here as well. And let's run npm install because that takes a few seconds. And let's open this one in the editor and let's do this full screen. So what do we get over here? Uh we get a boiler plate that's uh ready to use and those squirrel lines will go away once mp npm install is done. So all we have to do is we have to express the scheme on which inputs we expect. We have obviously to provide the list of our tools. So again we have to be good citizen over here and have to provide precise descriptions so that humans and LLMs know how to handle these kind of tools. So we list them in a simple array and then there's one ingestion function that's called call tool and depending on uh the the payload that we receive we have to decide which tool we have to execute. If we jump into handle example tool over here, we can see uh all incoming arguments are validated and if everything's fine, then we basically uh concaten concatenate the received input with a prefix and return that back to the user. Nothing fancy. So let's close the editor over here and follow the instructions. Next on list is make. make goes on and takes the JavaScript code, compiles that down to web assembly. So we end up with a tools web assembly component which is not yet a full-fledged uh MCP server. Next in line would be where MCP compose. Let's compose a full-fledged MCP by taking our tools and saying hey please give me an MCP for the sake of this demo. I don't care about authentication. Okay, it pulls all the necessary uh other components and composes together an MCP server and gives me instructions on how to run that. I can do a spin up -f server.wazm and we should see that running on localhost 3000. Okay, let's bring back the other terminal and let's run np npx the uh mcp inspector over here. That should fire up in the browser. There we go. Uh it's already pointing to localhost 3000 right here. So let's connect. Let's list tools. There's our example tool. We provide fu as an input parameter. We run the tool and we should get back foo. Great. Nothing fancy cool works. But that's the local experience. So how can we take that to become a glo or how can we turn that into a globally distributed MCP server? Well, instead of globally distributing uh the hello world MCP server, I have a decision lock MCP server and let me open up this one first. So there is this one is implemented in Rust for the sake of implementing it in Rust. Um so let's go into lip RS over here. There is an equivalent class or structure in Rust. As you can see, we're looking at the call tool function where we branch out and either use one of the CRUD APIs or tools that is provided by my MCP server. If we dive into the actual implementation um let me no this is wrong. I want this and then I want to do that uh decision. RS if we go to the bottom of the file you can see this is slightly different syntax but the same meaning right I have to define my tools and if we go to line 15 or so yes list decisions you can see over here that I use a store so on my local machine spin recognizes hey toen wants to use the key value store so it automatically creates a key value store using SQLite on my machine for development time purposes and on ecom myi functions it's leveraging the globally distributed um key value store without me having to configure anything from here it's actually the same story right I have to use that make file and compose the server however I think it's smarter to update the application manifest and concatenate those tasks so that I can remain in the spin developer experience and basically do a spin build to compile compose and compile my MCP server. However, I can also combine this one with spin ecomi deploy. So this right now composes the server asks me hey how do you want to call that MCP server on a my functions? I call it ADR MCP. I allow um my terminal to interact with the service registry. Now it's taken my Wom file and my application uh manifest generating OCI layers from those files uploading them to Echcomi functions on the server side or on the service side. We receive those two files and we distribute them across the globe through all the service regions. Every region has to confirm a that it received the workload that is capable of running the workload. Then we instantiate the workload once and do a internal health check. And once that came back for all the service regions with an HTTP 200 then we roll a generic subdomain on your behalf so that you that your MCP server will be on the public internet. Obviously you can shield that with other products and services uh like the property manager to shield it behind whatever you want to enforce before uh forwarding users to the MCP server. So we get that URL. So we are globally distributed in roughly 60 seconds. Let's move over to an uh to a client. I use Z over here but that works with any client that basically supports MCP. I add a server. I go to remote over here and let me replace this one with the URL that we received. Add the server. And we can see I have five tools already. I can go here and say view tools. And these are the CRUD tools that my MCP defined. So I can go back and chat with my IDE in the context of my project so that it could leverage uh my MCP server. track a decision to use or of 2.0 Hello for awful. Okay, so it should now identify my intent and ask permission to run the insert decision tool. We can see the raw input. Looks good. We allow it. It now calls out to echo my functions has already has already tracked my decision and I can say give me all the decisions please. Now the intent is to use the list decisions tool and again we are uh yes it might want to read uh details to give me everything that it tracked or and uh with that we have a globally distributed um MCP server that's routing all the requests to the closest service region no matter where your users are and again you can write those tools or prompts or resources using TypeScript, Python or Rust templates. Cool. Uh let's move on with agents. Um so, oops, nope, this one. So, for AI agents, the story is no different. However, instead of using another CLI, uh we can simply pick any kind of SDK that's out there and that's popular. Um I I think the Verscel AI SDK is pretty nice to use. So this allows us basically to create a new spin app using TypeScript. Just bring in the Versal AI dependencies and to build custom agents. Again, let's move back to the terminal to see how that looks like. Uh so let's move one up and let's CD into a simple game agent over here. And what's going on over here? Obviously, I have created a new spin app using a template so that I can get started pretty quickly. I'm leveraging a large language model deployed to a Lenode instance with a dedicated GPU. And all my spin app does it defines the tools. So, this is a simple game agent for the sake of demonstration purposes that can flip co flip coins that can roll a dice where you can specify how many sides that dice should have. And over here in the actual HTTP handler, we load the config and we define our agent, you know, pointing it to the old lama instance running on the node. We give our agent an identity and an instruction on what its intent actually is. We register our tools and we give it some constraints of of how many steps it might take. We generate a response and return it back to the collie. Okay, let's uh go let's do a quit all over here and let's do another spin aka deploy no confirm build and it asks for the name that's the game agent. So while it is uploading let me explain what happens when we compile a lang an interpreted language. So during compilation time we load the interpreter, we load your custom JavaScript and then we evaluate the global scope. This has one advantage that not just the runtime is hot also all the dependencies are loaded and then we take a memory snapshot write that to WM store that on disk meaning that every web assembly application written in JavaScript is faster than a native JavaScript application when it comes to cold starts and runtime performance. The only trade-off though is that we have to ship the JavaScript runtime along with our um with our user code. But we use an optimized JavaScript runtime called stalling monkey which is roughly 10 megabytes in size. So we get back an URL. Let me replace this URL over here. And let's say toss a coin. And we see um we see a response back. And if we look at these headers, we can see uh the point of presence where we enter the Ecomi network is Santa Clara and the closest service region for our AI agent is LAX. Another interesting header is X envoy upstream service time. And this tells me and you right now as well that it took 33 34 milliseconds to receive the request to run through the business logic to reach out to the large language model to generate a response and to go all the way back to the user. Oh, there's an internal server error. Great. Awesome. Let's try this again. Oh, yeah. That was an user error. Sorry. So, the error was staying 30 cmters in front of the screen. Um looking at it now we are 866 milliseconds. Um that is more realistic because we have to go through the LLM to basically see that uh our to our toss resulted in tails. Let's do that again. Tails tails tails tails. Oh, there's a hat. Nice. So roughly 820 milliseconds is what we could achieve with a full loop through the LLM by taking our agent and deploying it to a functions. Okay, so the developer workflow is always the same. No matter if you build any kind of line of business application, if you build an MCP or if you build an agent, you implement your application using any language that you could compile down to web assembly. Rust, TypeScript, Python, Go are the most prominent ones these days. You can test it locally with the spin CLI. You deploy it using a single command called spin a deploy. And finally, your you point your clients to your MCP or to your agent. So final or key takeaways from my from my point are portability. You can take those spin apps and run them on any Wii compliant runtime. Echi functions is one runtime and it's the globally distributed runtime. Everything is based on open standards. So spinners, CNCF, Wesi, Web Assembly are governed by the bite code alliance. But ultimately you gain speed, right? You have fast response times. Even the time to market for your developers to build MCPs and to build agent goes down because you don't have to roll the infrastructure. You don't have to implement non-functional requirements. That's all taken care of. And in terms of infrastructure, there's no ops. It's spin aka deploy is all you need. There are other commands in the box so that you can g gather metrics that you can retrieve logs that you can upgrade and so on and so forth. But developer experience is our our highest metric when we started spin and while we continue in that direction. Um we have a new website that's called the Ecomi developer hub where we share stories and experiments and and experiences like these. So go check out developers.accomi.com. ecomi.com and if you have any further question find me at the Akcomi booth and with that thank you very much. \>\> \[music\]