Back to Zeroclaw

Architecture Overview

docs/book/src/architecture/overview.md

0.7.44.2 KB
Original Source

Architecture Overview

ZeroClaw is a layered Rust workspace. At the top is the agent runtime; below it are pluggable providers, channels, tools, and memory; supporting crates handle config, sandboxing, and hardware.

High-level shape

mermaid
flowchart TB
    subgraph External["External world"]
        UI["CLI / chat platforms / gateway clients / ACP IDEs"]
        LLM["LLM providers
Anthropic · OpenAI · Ollama · ..."]
        FS["Filesystem · shell · network"]
    end

    subgraph Edges["Edge crates — talk to the outside"]
        CH["zeroclaw-channels
30+ messaging integrations"]
        GW["zeroclaw-gateway
REST · WebSocket · dashboard"]
        PR["zeroclaw-providers
LLM clients · fallback · routing"]
        TL["zeroclaw-tools
browser · HTTP · PDF · hardware"]
    end

    subgraph Core["Core"]
        RT["zeroclaw-runtime
agent loop · security · SOP · cron · onboarding"]
        MEM["zeroclaw-memory
SQLite · embeddings · consolidation"]
        CFG["zeroclaw-config
schema · autonomy · secrets"]
    end

    UI --> CH
    UI --> GW
    CH --> RT
    GW --> RT
    RT --> PR
    RT --> TL
    RT --> MEM
    RT --> CFG
    PR --> LLM
    TL --> FS

Crates in scope

CrateRole
zeroclaw-runtimeAgent loop, security policy enforcement, SOP engine, cron scheduler, onboarding wizard, TUI
zeroclaw-configTOML schema, secrets encryption, autonomy levels, workspace resolution
zeroclaw-apiPublic traits — Provider, Channel, Tool. The kernel ABI
zeroclaw-providersAll LLM client impls (Anthropic, OpenAI, Ollama, …) plus the router and fallback wrapper
zeroclaw-channels30+ messaging integrations (Discord, Slack, Telegram, Matrix, email, voice, …)
zeroclaw-gatewayHTTP / WebSocket gateway, web dashboard, webhook ingress
zeroclaw-toolsCallable tool implementations the agent invokes (browser, HTTP, PDF, hardware probes)
zeroclaw-tool-call-parserModel-side tool-call syntax parsing and normalisation
zeroclaw-memoryConversation memory, embeddings, vector retrieval
zeroclaw-pluginsDynamic plugin loading
zeroclaw-hardwareHardware abstraction layer (GPIO, I2C, SPI, USB)
zeroclaw-infraTracing, metrics, structured logging
zeroclaw-macrosDerive macros for config, tool registration
zeroclaw-tuiTerminal UI
aardvark-sys, robot-kitSpecialised hardware support

The microkernel roadmap (RFC #5574) is actively splitting zeroclaw-runtime further — the kernel layer will shrink to the agent loop and policy enforcement, with everything else moving behind feature flags.

Request lifecycle (short)

mermaid
sequenceDiagram
    participant U as User
    participant CH as Channel
    participant RT as Runtime
    participant SEC as Security
    participant PR as Provider
    participant TL as Tool

    U->>CH: message / DM / webhook
    CH->>RT: deliver_message(ctx)
    RT->>PR: chat(messages, tools)
    PR-->>RT: stream: text · tool_call
    RT->>SEC: validate(tool_call)
    SEC-->>RT: approved / blocked
    RT->>TL: invoke(args)
    TL-->>RT: result
    RT->>PR: chat(..., + tool_result)
    PR-->>RT: stream: text (final)
    RT-->>CH: reply (partial / final)
    CH-->>U: message

Full detail: Request lifecycle.

Extension points

Three trait-based extension points live in zeroclaw-api:

  • Provider — implement for a new LLM endpoint. See Custom providers.
  • Channel — implement for a new messaging platform. Inbound and outbound are separate hooks.
  • Tool — implement for a new capability the agent can invoke. See Developing → Plugin protocol.

All three are registered at startup via factory functions; the kernel doesn't know the concrete types. Compile-time feature flags decide which implementations ship in a given binary.