Autolang FAQ

Autolang is a capability-based runtime and scripting surface designed exclusively for AI-generated orchestration, shipped as a lightweight library you embed in your host. It solves two distinct pain points:

• For Developers (Cost of Failing Late): You are burning money and latency on "self-correction loops" because a dynamic runtime only reports the mistake after several business calls have already run. Autolang validates the whole script before the first capability is invoked, and returns structured compiler diagnostics so the model fixes the call without replaying the broken process.
• For CTOs & Architects (Security & Scale): You cannot run untrusted AI scripts directly in your enterprise backend. Autolang enforces a strict default-deny model. AI only gets access to the exact capabilities the host explicitly grants, ensuring safe execution at scale without hanging your servers or exposing your OS.

Restricting a general-purpose language like JavaScript after the fact is harder and less secure than designing a language with dangerous features omitted from the start.

Autolang achieves two goals simultaneously:

• Intentional Scope (Security): Dangerous features like dynamic evaluation (eval) or implicit type coercion simply do not exist in the grammar.
• Surface Match (Accuracy): It adopts the basic control flow syntax of Kotlin, deeply ingrained in LLM training data, ensuring the model writes correct code naturally.

Tool Calling is for single operations. When an AI needs to execute multi-step workflows (loops, conditions, intermediate state), tool calling requires a network round-trip back to the model for every single step, destroying performance and driving up token costs.

Autolang lets the model generate a single orchestration script that executes locally in the VM, handling all intermediate logic without model network latency.

Autolang validates the whole script before any capability runs. Instead of failing in the middle - after several business calls already executed - the compiler returns structured diagnostics (capability not found, type mismatch, available capabilities) so the model fixes the call without replaying the broken process.

Because Autolang is not a generic programming language, it makes several intentional tradeoffs to keep the attack surface small:

• Single-threaded per VM: A single VM instance executes synchronously on one thread. To process multiple agents concurrently, the host must spawn multiple VM instances.
• No async/await or networking: Autolang lacks built-in I/O capabilities. It relies entirely on the host application (via bindings) to provide network requests or database access.

Note: A “small ecosystem” is not the trade-off here. AI scripts are meant to orchestrate your own backend business logic (TypeScript, Python, Go) - not pull in arbitrary third-party packages. Security tracks how narrowly you scope those host capabilities, not the size of a registry.

Autolang provides language-level isolation and capability control. It replaces the general-purpose runtime that would otherwise execute inside those isolation layers.

It is an execution layer designed to work with your existing infrastructure, not replace it:

• Python / Node.js: Autolang complements your backend. Python handles your host business logic; Autolang acts as the execution layer where AI-generated scripts run.
• KVM / Docker / Firecracker: These provide OS and hardware isolation. Autolang provides language-level isolation and capability control. Run Autolang inside them for true defense-in-depth - infrastructure isolation at the host layer, capability enforcement at the language layer.
• Cloud Sandboxes (E2B, Modal, Daytona): These provide full Linux environments. Run Autolang inside them when you need capability control on top of OS-level isolation.
• LMQL / JSON Schema: These control the generation phase (forcing the LLM to output valid syntax). Autolang handles the execution phase. They are highly symbiotic.

No on both counts. Autolang is not a replacement for Docker, Firecracker, V8 Isolates, or an operating system, and it never provides OS isolation.

Autolang provides language-level isolation and capability control. It replaces the general-purpose runtime that would otherwise execute inside those isolation layers.

Practically: Docker decides which files, devices and network a process can touch. Autolang decides which host capabilities a generated script can call, and how much it may consume. They answer different questions, so you combine them rather than choose.

Starlark and CEL lack surface match. LLMs are heavily trained on mainstream languages like Kotlin and Python. When forced to write CEL or Starlark for multi-step logic, the model is learning a new dialect. Autolang matches Kotlin's control flow surface so a minimal prompt is enough, and the compiler still validates every name, type, and capability before execution.

isolated-vm is a runtime for a dynamic language. Autolang is a language and runtime with strict static typing and compile-time capability validation: it catches invented names and wrong types before any host work is done, which dynamic JavaScript cannot natively do. The trade-off is scope - JavaScript can run arbitrary libraries; Autolang's surface is intentionally smaller.

Autolang provides language-level isolation and capability control, on top of whatever OS isolation you already run.

Security is enforced by design rather than runtime policies. Every function - filesystem, network, business system - is outside the language until the host explicitly grants it (scripts start with zero permissions):

• Restricted Host Access: Scripts cannot reach operating-system capabilities unless the host explicitly registers them.
• No Built-in Networking: Scripts have no built-in networking.
• No Dynamic Evaluation: There is no eval() or Function() that can execute a dynamic string as code.
• Explicit Grant Only: Every callable the script sees comes from registerBuiltInLibrary(). Host-owned objects returned by those capabilities are outside VM memory accounting.

No. Scripts have no built-in HTTP or File clients. While the compiler has an escape hatch for public fetching, the best practice is to wrap all network or file logic into your own custom functions (e.g. fetchWeather()). This forces the AI to orchestrate logic safely, and if they spell the function wrong, the compiler stops it immediately.

Yes. Autolang is designed for incremental adoption. You register a single native library wrapping your existing Node.js or C++ service methods and pass AI scripts to the compiler instance. You do not need to rewrite your database layers.

Here is a complete end-to-end integration example using the autolang-compiler package in TypeScript:

Roughly 0.5MB per native VM instance, and a shared WebAssembly module amortized across every instance in the process. That is small enough to spin up a fresh VM per agent session instead of reusing one.

Autolang does not compete with Python or JavaScript on raw throughput, and this documentation makes no speed claims - numbers move with every model and build. See the benchmarks for measured figures with run provenance.

Each compiler/VM instance is intended to be used from a single thread. For multi-threaded concurrency, spawn independent instances across worker threads.

Autolang is an open-source project hosted on GitHub under the MIT License.