I really like the capability enforcement model, it's a great concept. One thing this discussion is missing though is the ecosystem layer. Sandboxing solves execution safety, but there's a parallel problem: how do agents discover and compose tools portably across frameworks? Right now every framework has its own tool format and registry (or none at all). WASM's component model actually solves this — you get typed interfaces (WIT), language interop, and composability for free. I've been building a registry and runtime (also based on wasmtime!) for this: components written in any language, published to a shared registry, runnable locally or in the cloud. Sandboxes like amla-sandbox could be a consumer of these components. https://asterai.io/why

▲

souvik1997 12 hours ago | parent | next [-]

The ecosystem layer is a hard but very important problem to solve. Right now we define tools in Python on the host side, but I see a clear path to WIT-defined components. The registry of portable tools is very compelling.

Will checkout asterai, thanks for sharing!

▲

skybrian 12 hours ago | parent | prev [-]

Exposing tools to the AI as shell commands works pretty well? There are many standards to choose from for the actual network API.

▲

rellfy 11 hours ago | parent [-]

Shell commands work for individual tools, but you lose composability. If you want to chain components that share a sandboxed environment, say, add a tracing component alongside an OTP confirmation layer that gates sensitive actions, you need a shared runtime and typed interfaces. That's the layer I'm building with asterai: standard substrate so components compose without glue code. Plus, having a central ecosystem lets you add features like the traceability with almost 1 click complexity. Of course, this only wins long term if WASM wins.

▲

skybrian 11 hours ago | parent [-]

How does the AI compose tools? Asking it to write a script in some language that both you and the AI know seems like a pretty natural approach. It helps if there's an ecosystem of common libraries available, and that's not so easy to build.

I'm pretty happy with Typescript.

	▲	rellfy 11 hours ago \| parent [-]
		In my example above I wasn't referring to AI composing the tools, but you as the agent builder composing the tool call workflow. So, I suppose we can call it AI-time composition vs build-time composition. For example, say you have a shell script to make a bank transfer. This just makes an API call to your bank. You can't trust the AI to reliably make a call to your traceability tool, and then to your OTP confirmation gate, and only then to proceed with the bank transfer. This will eventually fail and be compromised. If you're running your agent on a "composable tool runtime", rather than raw shell for tool calls, you can easily make it so the "transfer $500 to Alice" call always goes through the route trace -> confirm OTP -> validate action. This is configured at build time. Your alternative with raw shell would be to program the tool itself to follow this workflow, but then you'd end up with a lot of duplicate source code if you have the same workflow for different tool calls. Of course, any AI agent SDK will let you configure these workflows. But they are locked to their own ecosystems, it's not a global ecosystem like you can achieve with WASM, allowing for interop between components written in any language.