Why asterai?

The Pivot

asterai started as an AI agent framework. We built the whole stack: LLM orchestration, vector databases, plugin systems, deployment infrastructure. It worked, but we kept running into the same problem our users had: tools were the bottleneck.

Everyone was rebuilding the same tools. HTTP clients, email senders, web scrapers, database connectors. Each framework had its own plugin format. Each language had its own ecosystem. Nothing was portable.

So we pivoted. We're now focused purely on the tool layer: an open registry and runtime for portable, sandboxed components that work with any AI agent framework.

The WASM Bet

We're betting on WebAssembly (WASM) with the WASI component model. Here's why:

Language Interoperability

A component written in Rust can call a component written in Python. A Go library can be used from JavaScript. This isn't FFI or language bindings - it's true interoperability through typed interfaces (WIT).

The best HTTP client might be in Rust. The best PDF parser might be in Python. Why should you have to choose? With WASM components, you don't.

True Portability

The same WASM binary runs locally on your laptop and in our cloud. No "works on my machine" problems. No Docker. No dependency hell. The component is the artifact.

Want to run everything locally for development? Use the open-source CLI. Want to deploy to the cloud? Push to the registry. Same code, same behavior.

Sandboxed by Default

AI agents need to run untrusted code safely. WASI provides capability-based security out of the box. Components can only access what you explicitly grant them. No network access unless permitted. No filesystem unless permitted.

This is critical for agents that execute tools from a public registry. You need guarantees that a component won't exfiltrate data or compromise your system.

Near-Native Performance

WASM isn't interpreted - it's compiled. With ahead-of-time compilation (which we do), execution is near-native speed. We're using Wasmtime, the most mature WASM runtime, with full WASI preview 2 support.

Why Not...

...Docker/Containers?

Containers are great for packaging applications, but they're heavyweight for tools. A simple HTTP request doesn't need a full Linux userspace. WASM components are measured in kilobytes, not megabytes. Cold starts are milliseconds, not seconds.

...Cloudflare Workers?

Cloudflare Workers run browser-style WASM, not WASI components. You can't use the component model. You can't compose components from different languages. We needed full WASI p2 support, which meant self-hosting our runtime.

...Native Plugins (like Composio)?

Native plugin systems lock you into a specific language and framework. They're not portable. They're not sandboxed. And they're closed ecosystems - you use what the vendor provides.

We wanted an open ecosystem where anyone can publish tools in any language, and anyone can use them in any framework. That requires a neutral interchange format. WASM is that format.

The Architecture

Components

Everything is a component. An AI tool is a component. An LLM wrapper is a component. A webhook handler is a component. Components have typed interfaces defined in WIT (WebAssembly Interface Types), enabling cross-language composition.

Environments

Components are bundled into Environments with configuration (environment variables, secrets). Think of it like LEGO - you snap components together to build what you need. Environments are versioned and immutable.

Registry

Components are stored as OCI artifacts (the same format as Docker images) in our registry. Public components are discoverable. Private components require authentication. We follow the OCI 1.1 referrer pattern for storing WIT interfaces.

Runtime

The runtime is open source. You can run components locally with our CLI or deploy to our cloud. Cloud execution includes resource limits (CPU, memory, timeout), usage metering, and automatic scaling.

What's Open

• Runtime: Open source, built on Wasmtime. Run locally or self-host.
• CLI: Open source. Develop, test, and deploy components.
• Registry: Anyone can publish public components.
• Interfaces: WIT interfaces are public and inspectable.

We're not trying to lock you in. If you want to run everything yourself, you can. The cloud is there for convenience, not dependency.

Get Started

The code is on GitHub. The docs explain how to build and publish components. The registry is live.