Shimmy WASM → Loom — from a safe execution boundary to an LLM-first runtime

How the problem changed

Shimmy began with one question: how can a Lambda-compatible service run untrusted, multilingual code safely and with low latency? That exposed a second problem: how should an LLM plan, schedule, and safely execute several tools and code steps? Loom grew from that boundary.

Shimmy WASM

• A Go and Wazero execution backend with a language-neutral JSON judging protocol.
• Compiler-module and WASM-instance pools, followed by memory snapshot restoration for clean warm starts.
• WASI, a restricted filesystem, and a Lambda interface that limit the host capabilities available to generated code.

Loom

• Incrementally parses streamed model output into a DAG. A step can be scheduled as soon as it closes, without waiting for the full plan.
• Runs independent tool and agent branches in parallel and feeds their results back into the conversation.
• Provides composable primitives for IO, writes, pure computation, shells, agents, function definitions, and calls.
• Reuses the WASM sandbox, safe filesystem, LRU and singleflight controls, and Prometheus metrics.

Design principle

A plan is a declaration. The executor owns dependencies, concurrency, capability boundaries, state, and observability. Separating the two makes model output inspectable, schedulable, and recoverable.

Scope

Sandboxed execution, planning, tool use, parallel scheduling, runtime design, and automated judging.