Astrid: An OS Built for AI Agents, Not Just Another Framework

Problem with existing AI‑agent frameworks

LangChain, CrewAI and AutoGPT are Python libraries that embed assumptions about LLM providers, orchestration loops and tool sets directly in code. Replacing any component requires forking the whole repository and maintaining a divergent branch.

Capsule abstraction

Astrid treats an AI agent as a native operating system. The fundamental unit is a capsule , an isolated WASM process described by a Capsule.toml manifest that lists required imports and exported capabilities. At kernel start‑up the kernel topologically sorts capsule dependencies and launches them in order.

Traditional plugin system : "shell + hooks" – the framework defines fixed interfaces and developers fill code at predetermined locations.

Astrid capsule : "kernel + micro‑services" – each capsule runs as an independent process, communicates via IPC, while the kernel handles scheduling, isolation and auditing.

Capsules are implemented with three engine types:

WASM – compiled sandbox with access to the full host ABI (49 system calls).

MCP – native subprocess accessed through a JSON‑RPC proxy (supports the MCP 2025‑11‑25 protocol).

Static – declarative context injection (files, prompts).

┌─────────────────────────────────────────┐
│            Provider Capsule            │
│  Anthropic │ Ollama │ vLLM │
│  IPC provides llm.v1.chat            │
└─────────────────────────────────────────┘          ↕ IPC event bus
┌─────────────────────────────────────────┐
│          Orchestrator Capsule           │
│  ReAct │ Debate │ MCTS │
│  Orchestration strategy = replaceable Capsule │
└─────────────────────────────────────────┘          ↕ IPC event bus
┌─────────────────────────────────────────┐
│            Tool Capsule                 │
│  Shell │ Filesystem │ GitHub │
│  tool.v1.execute.* topics               │
└─────────────────────────────────────────┘

Changing behavior only requires swapping the relevant capsule; the rest of the codebase remains unchanged.

Use cases with capsules

Run completely offline

Replace the Provider capsule with one that points to Ollama or vLLM. No code changes are required and the orchestrator remains unaware of the underlying model.

Transparent caching to save LLM costs

Insert a caching capsule between the orchestrator and the provider; identical prompts return cached results without modifying either component.

Autonomous agents that work through the night

Swap the default orchestrator for an autonomous‑worker capsule; the agent iterates code → test → run → fix until all tests pass.

Hybrid multi‑model routing

Run multiple Provider capsules simultaneously and add a routing capsule that selects a model based on task complexity, cost or latency, using the same IPC event protocol.

Self‑modifying agents

An agent can author a new capsule (Rust source, Capsule.toml, tests), compile it with astrid-build, install it via capsule install, and publish it to the IPC topic, thereby extending its own capabilities at runtime.

Capsules isolate individual agent capability units in a manner analogous to Docker containers isolating services, but capsules can be created and deployed by the agent itself.

Security model – five‑layer defense in depth

1. WASM sandbox – no system calls, file descriptors or host‑memory access; all external resources go through host functions.

2. Manifest gate – Capsule.toml declares a whitelist for filesystem, network and process access; prompt injection cannot elevate privileges.

3. IPC ACL – publish/subscribe permissions are granted per manifest, isolating communication by principal.

4. Capability tokens – ed25519‑signed tokens with glob‑set scope; tokens bind to a principal, include expiration checks and can be revoked globally.

5. Budget + approval – per‑operation and per‑session limits with dual budgeting; a human approval gate (allow / deny / always) mediates privileged actions.

All logs are chained with hash‑linked signatures; any tampering breaks the chain and becomes evident.

Security modes

safe – every operation outside the workspace prompts for approval.

guided – reads are auto‑allowed, writes require confirmation.

autonomous – removes safety barriers.

yolo – reckless mode.

Approval granularity

Options are Allow Once, Session, Workspace, Always and Deny. Always issues a capability token; Session creates a temporary permission that expires when the user goes offline.

Getting started

Prerequisites: Rust 1.94+ and an LLM API key (Anthropic is the default distribution).

# Install
cargo install astrid
# Initialize (pull default distribution)
astrid init
# Start a chat session
ANTHROPIC_API_KEY=sk-... astrid chat
# One‑off query
astrid -p "Summarize git commit history"
# Autonomous mode (auto‑approve all tool requests)
astrid -p "Fix all failing tests" --yes

Astrid consists of three binaries: astrid – CLI front‑end. astrid-daemon – kernel process. astrid-build – capsule compiler.

Running astrid chat launches the daemon, connects via a Unix domain socket, and streams events.

Scripted usage examples:

# Pipeline mode
git diff HEAD~1 | astrid -p "Write a commit message for this diff"
# Multi‑turn scripted conversation
SESSION=$(astrid -p "Start a task" --print-session 2>&1 | tail -1)
astrid -p "Continue this task" --session "$SESSION"

Why an operating system instead of a framework?

Traditional software places the human at the center; AI agents invert this relationship—agents act autonomously while humans supervise, approve and guide. Astrid’s kernel enforces hard boundaries so agents can operate freely inside those boundaries. Approval gates intervene only at critical moments, audit trails make every action traceable, and capability tokens let trust grow incrementally as agents demonstrate reliability.