Zgent vs OpenClaw

Zgent and OpenClaw both deal with AI agent orchestration, but they operate at different layers of the stack. This document explains the differences, overlaps, and how they relate.

TL;DR

Architecture comparison

         Zgent                              OpenClaw
    ┌─────────────────┐              ┌─────────────────────┐
    │  Your Application│              │  WhatsApp / Telegram │
    │  (you build this)│              │  Slack / Discord ... │
    └────────┬────────┘              └─────────┬───────────┘
             │                                  │
    ┌────────▼────────┐              ┌─────────▼───────────┐
    │   Zgent SDK      │              │   Gateway            │
    │  Channel → Ctx → │              │   (control plane)    │
    │  Dispatcher →    │              │   Sessions, routing, │
    │  Agent           │              │   security, skills   │
    └────────┬────────┘              └─────────┬───────────┘
             │                                  │
    ┌────────▼────────┐              ┌─────────▼───────────┐
    │  Claude Code SDK │              │   Pi Agent Runtime   │
    │  / Codex / ...   │              │   (from pi-mono)     │
    └─────────────────┘              └─────────────────────┘

Zgent is the middle layer — developers build applications on top of it. OpenClaw is the entire product — Pi is the execution engine embedded inside.

What is Pi?

Pi (pi-mono) is the agent execution engine inside OpenClaw. It handles the core agent loop:

1. Receive user message
2. Build system prompt
3. Call LLM API (Anthropic, OpenAI, Bedrock)
4. Parse response — if tool call, execute built-in tools (read/exec/edit/write)
5. Stream assistant output
6. Repeat until complete

Pi is a full, self-contained runtime. It knows how to call LLMs, execute tools, and manage conversation context — all in one package.

What Zgent does differently

Zgent does not re-implement agent logic. Instead, it delegates execution to existing engines and focuses on the orchestration layer above them.

Responsibility split

Engine philosophy

Pi says: "I am the engine — I run the agent loop, call LLMs, execute tools, stream output."

Zgent says: "I don't run agent loops — I orchestrate engines that do. Tell me when to trigger, who to route to, and what state to maintain."

# Zgent: the engine runs its own loop, Zgent just orchestrates
definition = AgentDefinition(
    system_prompt="You are a DevOps assistant.",
    engine_type=AgentEngine.CLAUDE,  # Could be OPENAI, BEDROCK, or future engines
    dispatcher=Dispatcher(lambda msg: DispatchResult(key=msg.session_id)),
)

ctx = Context(
    id="devops-bot",
    receivers=[CronChannel("0 9 * * *"), WebSocketChannel(port=8080)],
    senders=[output_channel],
    definitions=[definition],
)
await ctx.serve()

Concept mapping

Codex integration: two different approaches

Both projects relate to OpenAI Codex, but in fundamentally different ways.

OpenClaw: model-level integration

OpenClaw uses Codex models as an LLM provider inside Pi's agent loop. Pi still controls tool execution and the agent loop — it just swaps which model it calls.

Pi Runtime (agent loop unchanged)
  └── LLM call (swappable)
       ├── anthropic/claude-opus-4-6
       ├── openai/gpt-5.1-codex       ← API key
       └── openai-codex/gpt-5.3-codex ← Codex subscription

Zgent: engine-level integration

Zgent's design goal is to use Codex CLI as a complete agent runtime — Codex runs its own agent loop with its own sandbox and tool execution. Zgent only orchestrates when and how it runs.

Zgent (orchestration)
  └── Engine (each runs its own loop)
       ├── ClaudeEngine  → Claude Code SDK subprocess
       ├── CodexEngine   → Codex CLI subprocess (planned)
       └── Future engines

This is a fundamentally deeper level of integration. Zgent doesn't extract the model from the engine — it lets each engine run as a complete, autonomous agent runtime.

Proactive vs reactive

Zgent's proactive capability means agents can act on schedules and events without being asked — a key differentiator for infrastructure automation use cases.

Where they complement each other

These projects are not competitors — they solve problems at different layers:

┌───────────────────────────────────────────────┐
│  Application layer                             │
│  OpenClaw, Sheet0, your product, ...          │  ← End products
├───────────────────────────────────────────────┤
│  Orchestration layer                           │
│  Zgent SDK                                    │  ← Middleware
├───────────────────────────────────────────────┤
│  Engine layer                                  │
│  Claude Code SDK, Codex CLI, Pi-mono          │  ← Execution engines
├───────────────────────────────────────────────┤
│  Model layer                                   │
│  Claude, GPT, Gemini                          │  ← LLMs
└───────────────────────────────────────────────┘

• Pi could be a Zgent engine. Pi's agent runtime could be wrapped as an Engine implementation, with Zgent managing scheduling, routing, and state above it.
• OpenClaw validates Zgent's thesis. OpenClaw's success (180k+ stars) proves the market need for multi-channel agent orchestration. Zgent generalizes this into a reusable SDK.
• Zgent's edge is multi-engine + proactive. OpenClaw is locked to Pi as a single engine and primarily responds to messages. Zgent supports engine switching and event-driven triggers.

Summary

Pi answers "how does an agent run" — Zgent answers "how do you manage agents."

Pi is a complete, self-contained agent runtime that knows how to call LLMs, execute tools, and manage conversations. Zgent is an orchestration layer that doesn't care about agent internals — it focuses on when to trigger, who to route to, what state to keep, and where to send results.