In our last post, we announced Hayride, an open-source secure AI runtime for LLMs, sandboxed code execution, and orchestrating agentic workflows.

Hayride leverages the security and portability benefits offered by WebAssembly, making it an ideal platform for developers focused on building composable and reusable AI tooling.

In a series of posts this one kicks off, we will explore building a lightweight command-line (CLI) AI agent using Golang, with a sprinkle of Rust, to demonstrate how quickly AI agents leveraging tools written in multiple languages can be composed together using Hayride.

If you are new to WebAssembly and concepts such as WebAssembly Interface Types, WebAssembly System Interfaces, or the component model, we recommend learning about these topics now. However, this post will guide you through the various concepts as they come up.

Here are some resources to get you up to speed on WebAssembly:

• https://wasi.dev/

• https://component-model.bytecodealliance.org/introduction.html

• https://docs.hayride.dev/platform/concepts/wasm

Let’s dive in!

Prerequisites

Before we can start implementing our application, several tools are required. Of note, Hayride leverages WASI Preview 2, which is gaining support across various languages.

We’ll use the following tools in this post:

• Hayride

• Wit-bindgen-go

• Wit-deps

• Wac

• Go version 1.23.0+

• TinyGo version 0.33.0+

• Rust +nightly

• Cargo component

Please refer to the tools’ installation guides to get started.

Installing Hayride

The easiest way to install Hayride is through our installation script. Linux and macOS users can execute the following:

curl https://raw.githubusercontent.com/hayride-dev/releases/refs/heads/main/install.sh -sSf | bash

This downloads a precompiled version of wasmtime, places it in $HOME/.hayride, and updates your shell configuration to set the right directory in PATH.

Windows users can visit our releases page to download the MSI installer and use it to install Hayride.

After the installation completes, the hayride binary should be located in your path. You can verify the installation by running hayride help from your terminal.

Now that Hayride is installed, we can start developing an agent that can be deployed to Hayride!

Building a CLI Agent

Hayride has defined a set of AI interfaces using WebAssembly Interface Types (WIT).

An interface describes a single-focused, composable contract through which components can interact with each other and with hosts.

Interfaces are directional. When using an interface, you can indicate whether the interface is available for external code to call (i.e., export) or whether external code must fulfill the interface for the component to call (i.e., import).

Interfaces are strictly bound to a component. A component cannot interact with anything outside itself except by having its exports called or by calling its imports. These constraints provide rigorous sandboxing.

Here is an example of how Hayride defines an agent runner interface using WIT:

package hayride:ai@0.0.61;

interface runner {
    use types.{message};
    use agents.{agent};
    use wasi:io/streams@0.2.0.{output-stream};

    enum error-code {
        invoke-error,
        unknown
    }

    resource error {
        code: func() -> error-code;
        data: func() -> string;
    }

    invoke: func(message: message, agent: borrow<agent>) -> result<list<message>, error>;
    invoke-stream: func(message: message, writer: borrow<output-stream>, agent: borrow<agent>) -> result<_,error>;
}

(https://github.com/hayride-dev/coven/blob/main/ai/wit/runner.wit)

The runner interface is responsible for invoking an agent and supplying a prompt or message.

Runners define the agent loop as a function that describes how the agent executes.

Agents are defined as a component that interacts with an AI model, can use tools, and can store the context of any interactions.

Our agent interface in WIT is defined as follows:

package hayride:ai@0.0.61;

interface agents {
    use types.{message};
    use context.{context};
    use model.{format};
    use hayride:mcp/tools@0.0.61.{tools};
    use hayride:mcp/types@0.0.61.{tool, call-tool-params, call-tool-result};
    use graph-stream.{graph-stream};
    use inference-stream.{graph-execution-context-stream};
    use wasi:io/streams@0.2.0.{output-stream};

    enum error-code {
        capabilities-error,
        context-error,
        compute-error,
        execute-error,
        unknown
    }

    resource error {
        code: func() -> error-code;
        data: func() -> string;
    }

    resource agent {
        constructor(name: string, instruction: string, format: format, graph: graph-execution-context-stream, tools: option<tools>, context: option<context>);
        name: func() -> string;
        instruction: func() -> string;
        capabilities: func() -> result<list<tool>, error>;
        context: func() -> result<list<message>, error>;
        compute: func(message: message) -> result<message, error>;
        execute: func(params: call-tool-params) -> result<call-tool-result, error>;
    }
}

(https://github.com/hayride-dev/coven/blob/main/ai/wit/agents.wit)

Following the component model, these interfaces can be implemented externally by outside code and imported by our component.

For this post, we use a default runner and agent implementation packaged with Hayride. This allows us to focus solely on the CLI portion of our agent and uses an externally available runner and agent component that satisfy our interface contracts. The implementations of these components can be found in our morphs repository.

In a future post, we will unpack how each of these components works and how you can implement your own component that satisfies the various AI interfaces Hayride supplies.

Defining Our Morph

Hayride Morphs are the fundamental building blocks of applications. They can import functions to access external capabilities and can also export their capabilities to other morphs.

The term morph simply refers to a WebAssembly component that is designed to be composable and portable across different environments.

Our CLI Agent Morph can be described in WIT using worlds.

A WIT world is a higher-level contract that describes a component’s capabilities and needs. A world is composed of interfaces. For a component to run, its imports must be fulfilled by a host or by other components.

Connecting up some or all of a component’s imports to other components’ matching exports is called composition.

Given this, we can define our component world as follows:

package hayride:example@0.0.1;

world cli {
    include hayride:wasip2/imports@0.0.61;
    include hayride:wasip2/exports@0.0.61;

    import hayride:ai/runner@0.0.61;
    import hayride:ai/model-repository@0.0.61;
}

(https://github.com/hayride-dev/morphs/blob/main/components/examples/agents/wit/world.wit#L3C1-L9C2)

Now that we have a rough idea of what our world and interfaces look like, we can create our project and see how we use the preceding WIT definitions.

Project Setup

First, we create our project’s directory layout:

mkdir hayride-example-agent

Since we are building our agent in Go and compiling to WebAssembly using TinyGo, we can use go mod to initialize our application and dependencies:

go mod init

Next, we create a directory called wit:

mkdir wit

We use the world defined above and copy it to a file in our wit directory:

touch ./wit/world.wit

To use this world, we need to pull down our dependencies. Using Hayride’s WIT repository, we can add two dependencies using wit-deps.

Wit-deps requires a deps.toml to track dependencies. We can add it to our wit directory using the following command:

Touch ./wit/deps.toml

In the deps.toml file, add the following dependencies:

wasip2 = "https://github.com/hayride-dev/coven/releases/download/v0.0.61/hayride_wasip2_v0.0.61.tar.gz"
ai = "https://github.com/hayride-dev/coven/releases/download/v0.0.61/hayride_ai_v0.0.61.tar.gz"
mcp = "https://github.com/hayride-dev/coven/releases/download/v0.0.61/hayride_mcp_v0.0.61.tar.gz"

To pull these dependencies into our project, we use a tool called wit-deps.

From the project’s root, run the following command:

wit-deps update

Next, we create a main.go file and start implementing our CLI application:

touch main.go

Now that we have the basic project layout and dependencies downloaded, we can move on to implementing our CLI.

CLI Application

Our CLI is responsible for reading in a user’s message from STDIN and returning the response from the agent.

First, let’s start by creating the necessary objects using Hayride’s bindings repository.

In the main.go file, add the following lines of code:

package main

import (
    "bufio"
    "fmt"
    "log"
    "os"
    "strings"

    "github.com/hayride-dev/bindings/go/hayride/ai/agents"
    "github.com/hayride-dev/bindings/go/hayride/ai/ctx"
    "github.com/hayride-dev/bindings/go/hayride/ai/graph"
    "github.com/hayride-dev/bindings/go/hayride/ai/models"
    "github.com/hayride-dev/bindings/go/hayride/ai/models/repository"
    "github.com/hayride-dev/bindings/go/hayride/ai/runner"
    "github.com/hayride-dev/bindings/go/hayride/mcp/tools"
    "github.com/hayride-dev/bindings/go/hayride/types"
    "github.com/hayride-dev/bindings/go/wasi/cli"
    "go.bytecodealliance.org/cm"
)

func main() {
    repo := repository.New()
    path, err := repo.DownloadModel("bartowski/Meta-Llama-3.1-8B-Instruct-GGUF/Meta-Llama-3.1-8B-Instruct-Q5_K_M.gguf")
    if err != nil {
        log.Fatal("failed to download model:", err)
    }

    // Initialize the context, tools, and model format
    ctx, err := ctx.New()
    if err != nil {
        log.Fatal("failed to create context:", err)
    }

    tools, err := tools.New()
    if err != nil {
        log.Fatal("failed to create tools:", err)
    }

    format, err := models.New()
    if err != nil {
        log.Fatal("failed to create model format:", err)
    }

    // host provides a graph stream
    inferenceStream, err := graph.LoadByName(path)
    if err != nil {
        log.Fatal("failed to load graph:", err)
    }

    graphExecutionCtxStream, err := inferenceStream.InitExecutionContextStream()
    if err != nil {
        log.Fatal("failed to initialize graph execution context stream:", err)
    }

    a, err := agents.New(
        format, graphExecutionCtxStream,
        agents.WithName("Helpful Agent"),
        agents.WithInstruction("You are a helpful assistant. Answer the user's questions to the best of your ability."),
        agents.WithContext(ctx),
        agents.WithTools(tools),
    )
    if err != nil {
        log.Fatal("failed to create agent:", err)
    }

    runner := runner.New()
}

This code simply creates the various objects that our runner and agent require to execute:

• Repository: The repository package provides the ability to download models from a remote repository. Hayride’s host environment provides a Hugging Face implementation for model repositories.

• Context: The context object is a message store for the agent. The agent determines when to store context and when to pull past messages. We’re using Hayride’s in-memory context store for this example.

• Tools: The tools object is used to expose callable tools to the agent. Since our agent doesn’t require tools, we’ll attach an empty tools component.

• Format: The format object is used to encode the user’s message before sending it to the LLM. We also use the format object to decode the response from the LLM. Each model typically requires some form of custom encoding or decoding.

• GraphExecutionCtxStream: The GraphExecutionCtxStream provides access to our host environment and the LLM loaded. This is an extension of wasi-nn to allow for streaming responses.

Next, we add the code to read from STDIN and create a STDOUT writer.

Since we are working with WebAssembly, we leverage WASI to pipe the terminal’s STDIN/STDOUT in our application.

While TinyGo supports wasip2, a few limitations come up when composing multiple components. One of these limitations is the inability to access the Wasm resource provisioned by the host runtime for an io.Writer when using the Standard library. In short, this means that we are unable to pass this resource to a component that uses this resource.

To avoid this limitation, we have implemented a few WASI helpers in the bindings repository. The main helper to leverage is our implementation of the wasi-cli interface.

Using our bindings, we can create an io.Writer that can be converted into a WASI output stream and passed between components, in our case, passing the writer created in our CLI application to an AI runner:

writer := cli.GetStdout(true)
reader := bufio.NewReader(os.Stdin)

Lastly, we add a basic loop that allows the user to type a prompt, send the prompt to the agent using our runner, and display the result:

fmt.Println("What can I help with?")
for {
    input, _ := reader.ReadString('\n')
    prompt := strings.TrimSpace(input)
    if strings.ToLower(prompt) == "exit" {
        fmt.Println("Goodbye!")
        break
    }

    msg := types.Message{
        Role: types.RoleUser,
        Content: cm.ToList([]types.MessageContent{
            types.NewMessageContent(types.Text(input)),
        }),
    }

    err := runner.InvokeStream(msg, writer, a)
    if err != nil {
        fmt.Println("error invoking agent:", err)
        os.Exit(1)
    }

    fmt.Println("\nWhat else can I help with? (type 'exit' to quit)")
}

The runner’s InvokeStream function is called with the user’s prompt, an output stream, and an agent. The result of the agent is automatically written back to the user. We simply invoke our agent in a loop with the message the user has sent.

There are limitations with WebAssembly’s async capabilities that require us to pass the writer forward to our component in order to start writing the result as fast as possible. However, discussions around async functions are taking place in wasip3. More information can be found on the wasi roadmap.

The full code looks like this:

package main

import (
    "bufio"
    "fmt"
    "log"
    "os"
    "strings"

    "github.com/hayride-dev/bindings/go/hayride/ai/agents"
    "github.com/hayride-dev/bindings/go/hayride/ai/ctx"
    "github.com/hayride-dev/bindings/go/hayride/ai/graph"
    "github.com/hayride-dev/bindings/go/hayride/ai/models"
    "github.com/hayride-dev/bindings/go/hayride/ai/models/repository"
    "github.com/hayride-dev/bindings/go/hayride/ai/runner"
    "github.com/hayride-dev/bindings/go/hayride/mcp/tools"
    "github.com/hayride-dev/bindings/go/hayride/types"
    "github.com/hayride-dev/bindings/go/wasi/cli"
    "go.bytecodealliance.org/cm"
)

func main() {
    repo := repository.New()
    path, err := repo.DownloadModel("bartowski/Meta-Llama-3.1-8B-Instruct-GGUF/Meta-Llama-3.1-8B-Instruct-Q5_K_M.gguf")
    if err != nil {
        log.Fatal("failed to download model:", err)
    }

    // Initialize the context, tools, and model format
    ctx, err := ctx.New()
    if err != nil {
        log.Fatal("failed to create context:", err)
    }

    tools, err := tools.New()
    if err != nil {
        log.Fatal("failed to create tools:", err)
    }

    format, err := models.New()
    if err != nil {
        log.Fatal("failed to create model format:", err)
    }

    // host provides a graph stream
    inferenceStream, err := graph.LoadByName(path)
    if err != nil {
        log.Fatal("failed to load graph:", err)
    }

    graphExecutionCtxStream, err := inferenceStream.InitExecutionContextStream()
    if err != nil {
        log.Fatal("failed to initialize graph execution context stream:", err)
    }

    a, err := agents.New(
        format, graphExecutionCtxStream,
        agents.WithName("Helpful Agent"),
        agents.WithInstruction("You are a helpful assistant. Answer the user's questions to the best of your ability."),
        agents.WithContext(ctx),
        agents.WithTools(tools),
    )
    if err != nil {
        log.Fatal("failed to create agent:", err)
    }

    runner := runner.New()

    writer := cli.GetStdout(true)
    reader := bufio.NewReader(os.Stdin)

    fmt.Println("What can I help with?")
    for {
        input, _ := reader.ReadString('\n')
        prompt := strings.TrimSpace(input)
        if strings.ToLower(prompt) == "exit" {
            fmt.Println("Goodbye!")
            break
        }

        msg := types.Message{
            Role: types.RoleUser,
            Content: cm.ToList([]types.MessageContent{
                types.NewMessageContent(types.Text(input)),
            }),
        }

        err := runner.InvokeStream(msg, writer, a)
        if err != nil {
            fmt.Println("error invoking agent:", err)
            os.Exit(1)
        }

        fmt.Println("\nWhat else can I help with? (type 'exit' to quit)")
    }
}

(https://github.com/hayride-dev/morphs/blob/main/components/examples/agents/cli.go)

All that’s left is to build and deploy our agent onto Hayride!

We’ll compile our application, compose it with Hayride’s existing morphs, and deploy our composed morph to Hayride.

Build Composition and Deployment

To compose our CLI with the existing Wasm components supplied by Hayride, we use WAC, a tool for composing WebAssembly Components together. The source code for these components can be found in our morphs repository.

The full language guide for WAC can be found here.

We start by creating a cli.wac with the following content:

package hayride:example;

let context = new hayride:inmemory@0.0.1 {...}; 
let llama = new hayride:llama31@0.0.1 {...};
let tools = new hayride:default-tools@0.0.1 {...};

let agent = new hayride:default-agent@0.0.1 {
  context: context.context,
  model: llama.model,
  tools: tools.tools,
  ...
};

let runner = new hayride:default-runner@0.0.1 {
  agents: agent.agents,
  ...
};

let cli = new hayride:cli@0.0.1 {
  context: context.context,
  model: llama.model,
  tools: tools.tools,
  agents: agent.agents,
  runner: runner.runner,
  ...
};

export cli...;

This file is responsible for composing the Wasm components that satisfy the interfaces our runner and agent expect.

In the above file, we are using the following Hayride Morphs:

• hayride:inmemory@0.0.1

• hayride:llama31@0.0.1

• hayride:default-tools@0.0.1

• hayride:default-agent@0.0.1

• hayride:default-runner@0.0.1

Using these components, we can compose our CLI. The final result is a single Wasm module that can be deployed on Hayride.

Hayride has built-in support for WAC files, and we can execute our composition with the following command:

hayride wac compose --path ./cli.wac --out ./composed-cli-agent.wasm

Once we have the composed-cli-agent.wasm file, we can register it with Hayride. This makes the morph available for future composition and direct execution.

hayride register --bin ./cli-agent.wasm --package hayride:composed-cli-agent@0.0.1

All that’s left is to execute our morph:
hayride cast --package hayride:composed-cli-agent@0.0.1 -it

This command launches our CLI:

Conclusion

In this post, we have demonstrated how to build a CLI application using Hayride’s existing AI morphs. Using WebAssembly’s Component model and various community tools, we composed multiple components together to build and deploy our CLI application on Hayride.

In our next post, we will delve into the Hayride Agent and Runner, exploring how each of these components works.

To stay informed about future developments, follow us on X and GitHub.

Artificial intelligence (AI) is not just transforming technology—it’s reshaping how the world builds, thinks, and operates. As large language models (LLMs) become more capable and accessible, we’re seeing a profound shift: Developers can now create intelligent, dynamic systems that were previously unimaginable. Barriers are dropping. Innovation is accelerating. The edge of what’s possible is being redrawn daily.

At the heart of this revolution lies software. While AI models can be viewed as the engine, software is the infrastructure enabling them to connect, execute, and deliver value.

As teams race to integrate LLMs into real-world systems, one trend is increasingly clear: building, testing, deploying, and securing AI-driven applications demands a new architecture pattern.

Many of today’s applications weren’t built with AI-native execution in mind. Integrations are often brittle, one-off, and tightly coupled to specific models or runtimes. Furthermore, once AI enters the loop, traditional workflows give way to nondeterministic paths, unpredictable behaviors, and execution contexts that defy conventional security assumptions.

It’s a thrilling time to be a developer. A single prompt can unlock functionality that once took months to build. Rigid APIs dissolve. Interfaces fade. However, with this power comes uncertainty. When AI is part of the execution path, much of the system is no longer deterministic—it’s probabilistic. The black box of inference becomes a black hole of potential outcomes. Even with predictable AI responses, user interaction within your application and its underlying data is drastically changing.

To address this, developers have turned to tool calling and agent frameworks—ways to let LLMs interact with real systems through structured protocols. These efforts are promising, but today’s approaches often sacrifice security, portability, and interoperability for speed. While LLMs are generating more code than ever, few systems are built to execute that code safely, consistently, or at scale.

Today, we’re introducing Hayride, our approach for standardizing AI agent execution using WebAssembly.

At Hayride, we believe the next era of AI development hinges on how we sandbox AI systems. This means rethinking the infrastructure that powers agentic systems and establishing trusted runtimes that are secure, composable, and built for the multimodal future.

This isn’t just about running code. It’s about establishing an execution layer for AI—one that’s open, safe, and built to scale.

In this post, we’ll walk through the limitations of today’s frameworks, examine emerging standards such as model context protocol (MCP), smolagents, and CodeAct, and share how WebAssembly and various WebAssembly proposals unlock a path to portable, secure, and interoperable agent execution.

Let’s dig in!

Protocols/Frameworks

The pace of innovation around AI agents is accelerating. Across the ecosystem, we’re seeing three dominant interaction patterns emerge:

1. LLMs are directly trained for solving end-to-end tasks

2. LLMs selecting from a set of tools and passing arguments for execution

3. LLMs generate code that must be executed in a secure runtime

Despite these advances, one thing remains constant: Language models do not execute anything themselves. Execution still requires a trusted environment—be it a local runtime, server, or secure sandbox.

To bridge the gap between generative reasoning and real-world action, developers have introduced protocols that allow LLMs to invoke structured functions, often referred to as tool calling. These protocols represent a critical layer in AI architecture: the interface between intelligence and execution.

In this section, we’ll explore several influential and emerging open frameworks defining the future of agentic AI, including:

• Meta’s Llama 3.1+ Tool Calling—prompt-based mechanisms that enable code interpretation and limited tool invocation

• Anthropic’s Model Context Protocol (MCP)—a structured, JSON-RPC-based interface between models and tools

• CodeAct—a research-driven extension of ReAct that emphasizes direct code generation and execution

While other agent frameworks like Google’s Agents-to-Agents (A2A) aim to facilitate interagent messaging and coordination, our priority is the execution layer, where LLMs interact with structured tools. In a future post, we’ll unpack how A2A fits within the Hayride runtime.

Meta Llama 3.1+: Code Interpretation and Tool Use

Meta’s latest LLM, Llama 3.3, extends features introduced in Llama 3.1, offering code interpretation and various forms of tool use. While not a formal protocol, Meta uses special prompt tokens to guide behavior such as code execution. For example, setting Environment: ipython in the system prompt enables the model to emit code responses intended for execution in a Jupyter-style environment.

<|begin_of_text|><|start_header_id|>system<|end_header_id|>
Environment: ipython<|eot_id|><|start_header_id|>user<|end_header_id|>

Write code to check if a number is prime...

This causes the model to return code like:

def is_prime(n):

    ...

print(is_prime(7))  # True

However, Meta’s models don’t execute the code themselves—this must be handled by external infrastructure such as llama-stack-apps or iPython runtimes. While convenient, this execution model lacks isolation and security by default, requiring additional sandboxing layers to run arbitrary code safely.

In addition to code interpretation, Llama supports three tool-calling modes:

1. Built-In Tools (e.g., Brave search, Wolfram Alpha)

2. JSON-Based Tool Calling

3. User-Defined Custom Tools via structured prompt instructions

What’s Missing?

Llama’s capabilities are embedded deeply in model weights and token streams, creating a brittle integration surface. There’s no shared protocol or interface for tool execution across runtimes or models. If you switch from Llama to another model, your tool infrastructure often needs to change as well.

Meta’s system is powerful but lacks portability, extensibility, and language-agnostic standards for integrating tools or ensuring secure execution at scale.

Anthropic’s Model Context Protocol (MCP)

Anthropic’s MCP (Model Context Protocol) is an emerging open standard designed to bring structured, contextual, and secure interaction between LLMs and their toolchains.

At its core, MCP is a JSON-RPC 2.0-based protocol for bidirectional communication between:

• Hosts: Apps running the LLM

• Clients: Tool connectors

• Servers: Services that expose tools, resources, and prompts to the model

The protocol formalizes several interaction primitives:

• Prompts: Customizable templates to guide model output

• Resources: Structured external data for richer context

• Tools: Executable functions that the model can call dynamically

Anthropic’s MCP emphasizes authentication, validation, and portability. It supports both local execution via STDIO and remote execution via server-sent events (SSE), with transport layer security (TLS) and access control as recommended practices.

Projects like Docker’s MCP integration and mcp.run show how containers and WebAssembly plugins can be packaged and exposed via MCP-compatible servers. These projects are pushing AI forward in a meaningful way and are fantastic examples of sandboxed environments.

What’s Missing?

MCP excels at interoperability and safety, but often introduces latency and complexity due to its middleware nature. The need to round-trip tool calls over JSON protocols can increase the number of actions required for an agent to solve a task, especially compared to in-process code generation and execution.

This overhead is highlighted in recent work, like Executable Code Actions Elicit Better LLM Agents (CodeAct)

CodeAct: Direct Code Generation and Execution

CodeAct is an extension of the ReAct pattern that allows LLMs to write and execute code inline during reasoning. Instead of describing tools via JSON or expecting the model to reason through text, CodeAct gives the LLM full access to generate, execute, and revise Python code as part of the task-solving loop.

Compared to JSON-based tool calling, CodeAct achieves:

( https://arxiv.org/pdf/2402.01030 - table 1 )

The source code and datasets are available on GitHub.

As shown in CodeAct’s benchmarks, this approach often reduces the number of steps needed to complete a task while improving task success rate.

What’s Missing?

While CodeAct increases performance and flexibility, it introduces significant security risks. Executing arbitrary generated code means trusting both the generation pipeline and its runtime environment.

There are no standardized sandboxing or language-agnostic methods to ensure that this process is secure by default.

Hugging Face Smolagents: Lightweight Code Agents

Smolagents, an open-source library from Hugging Face, implements CodeAct-like behavior in Python. It supports two execution modes:

• ToolCallingAgent: Traditional structured tool invocation

• CodeAgent: Direct generation and execution of Python code

Smolagents focuses on:

• Code consistency between LLM generation and execution

• Seamless tool registration and usage

• Sandboxing through platforms like E2B.dev

To define an agent, developers provide:

agent = CodeAgent(
    tools=[DuckDuckGoSearchTool()],
    model=LLMWrapper()
)

The agent can write Python code, use external tools, and solve tasks by chaining logic and execution without predefined templates.

What’s Missing?

Smolagents excel at agile code agent composition, but it is currently Python-only and leaves runtime trust and security concerns to external systems (e.g., E2B or local VMs).

It's a compelling foundation for CodeAct-style agent systems, but not yet portable, secure, or language-independent—all key criteria for running agents at scale across diverse environments.

Purpose-Built for the Future: Why We Built Hayride

As we’ve explored, modern AI agents rely on a growing constellation of tool-calling frameworks—from JSON-based protocols like MCP to dynamic code-generation libraries like smolagents and CodeAct. Each of these systems brings powerful capabilities to language models, enabling them to interact with tools, generate code, and operate across local and remote environments. However, each also introduces difficult tradeoffs around security, portability, and interoperability.

With Hayride, we asked a foundational question:

What if AI agent execution could be secure by design, portable by default, and interoperable across tools, languages, and runtimes—without sacrificing performance or control?

To answer that, we turned to WebAssembly.

Why WebAssembly?

WebAssembly (Wasm) is a fast, safe, and language-agnostic binary format for executing code across platforms. Originally designed for web browsers, it’s now evolving rapidly into a general-purpose runtime for secure sandboxed execution—ideal for the demands of modern AI workloads.

What makes Wasm uniquely suited for agentic systems?

• Secure by default: Sandboxed execution prevents privilege escalation and system-level access.

• Portable: Wasm modules run consistently across environments—from browsers to edge to cloud.

• Composable: Through the WebAssembly Component Model, modules written in different languages can interoperate seamlessly.

• Language-agnostic: Wasm supports Rust, TinyGo, Python, C/C++, JavaScript, and more.

The power of Wasm is unlocked by WASI (WebAssembly System Interface), a standards-based suite of APIs that make Wasm suitable for real-world applications, from filesystem access to machine learning.

Enter WASI 0.2 and the Component Model

WASI 0.2, released in 2024, introduces the Component Model—a breakthrough architecture that makes WebAssembly truly modular and interoperable. Instead of monolithic binaries, developers can now build reusable components that import and export standardized interfaces.

These interfaces are defined using WIT (WebAssembly Interface Types)—a simple language for specifying data types and function signatures across languages and runtimes.

Example WIT definition:

package docs:adder@0.1.0;

interface add {
  add: func(a: u32, b: u32) -> u32;
}

world adder {
  export add;
}

WIT doesn’t implement behavior; it defines contracts. This creates a shared surface area between independently developed components, much like MCP describes JSON-RPC tools, but closer to the compiled code and inherently cross-language.

Standardizing AI Inference with WebAssembly

The power of the Component Model extends beyond basic function calls. Projects like wasi-nn are defining standardized interfaces for AI inference, allowing Wasm components to serve or consume ML models using backends like TensorFlow, ONNX, PyTorch, and Llama.cpp.

Here’s a brief look at the wasi-nn WIT interface:

• tensor: Typed multidimensional data

• graph: A loaded ML model (e.g., ONNX, TensorFlow)

• Inference: Compute APIs for executing models

• errors: Robust handling and diagnostics

world ml {
  import tensor;
  import graph;
  import inference;
  import errors;
}

This enables any WASI 0.2-compatible language (Rust, TinyGo, Python, C++, etc.) to implement or consume AI workloads in a sandboxed, modular way, free from language bindings, OS dependencies, or container bloat.

Hayride: The Execution Layer for Agentic AI

Building on these principles, Hayride is our proposed execution architecture for next-generation AI agents.

Our thesis is simple: Secure execution is the missing layer of AI agent infrastructure.

Prompting and function calling are not enough. LLMs need a trusted, deterministic environment to execute actions, whether tool invocations, API requests, or AI-generated code.

With Hayride, we combine:

• 🧱 WASI 0.2 components for defining, importing, and composing tools

• 🛡️ Sandboxed WebAssembly runtimes for secure execution of agent actions

• 🔁 Standard interfaces (via WIT) for pluggable, reusable functions

• 🔄 Language interoperability so agents can execute in Rust, Go, Python, and more

• 🔌 Extensibility through protocol adapters and LLM orchestration layers

Much of Hayride builds on the existing WebAssembly ecosystem. Using WebAssembly Interface Types, we are releasing our AI Interfaces, which aim to help compose WebAssembly components for agentic workloads.

Using Hayride, agents can execute code compiled into a WebAssembly component. When an LLM instructs agents to execute code, the component is loaded and launched in a new WebAssembly sandbox.

These interface definitions can be found on our GitHub. In future articles, we will deep dive into each of the AI interfaces.

A New Standard for AI Execution

Hayride isn’t just a runtime. It’s a step toward a formal execution protocol for agentic AI—one where function calls, tool orchestration, and even model inference can be described, sandboxed, and deployed as modular Wasm components.

This unlocks:

• 🔐 Security through isolated execution and memory safety

• 📦 Portability across cloud, edge, and local environments

• 🧩 Composability via reusable, language-agnostic toolchains

• 🚀 Performance through near-native execution speed

• 🤖 Agent readiness for LLM orchestration, simulation, and autonomy

Standards-Compatible, Extensible by Design

Hayride is not a closed system. While the architecture is WebAssembly-first, it is protocol-agnostic. We are actively building adapters and bindings for:

• Anthropic’s Model Context Protocol (MCP)

• Agents2Agents (A2A) collaborative LLM frameworks

This allows Hayride components to be invoked as part of an existing MCP flow, exposed via A2A, or called directly via language models that support structured tool calling.

Call to Action

At Hayride, we’re building a secure AI runtime designed for agentic systems—and we’re betting on WebAssembly. We’re actively exploring:

• Registry support for WASI components

• WIT-based agent orchestration

• LLM code generation alignment with the WebAssembly’s Component Model

• Sandboxed inference and agent code execution

If you’re building agentic AI, secure runtimes, or composable dev tools, we’d love to talk!

Check out our GitHub and Developer Docs to get started today!