Build any bot you want. Connect any AI agent — Claude, GPT, a custom LLM, anything — to Telegram, Slack, HTTP, and more. You write the AI logic in any language; anyclaw handles message routing, crash recovery, tool access, and subprocess supervision.
⚠️ Unstable — anyclaw is under active development. APIs, config format, and protocol details may change between releases.
Anyclaw is infrastructure, not an AI assistant. It's a sidecar process that sits between your agent and the outside world:
- Channels deliver messages to and from users (Telegram, HTTP, and more coming)
- Agents are your AI backends — any binary that speaks ACP (JSON-RPC 2.0 over stdio)
- Tools give agents capabilities via MCP servers or WASM sandboxes
All three are standalone binaries spawned as child processes. Write them in Rust, Python, Go, TypeScript — whatever you prefer. Anyclaw manages their lifecycle, restarts them on crash, and routes messages between them.
See anyclaw running in under a minute — no API keys needed:
git clone https://github.com/donbader/anyclaw.git
cd anyclaw/examples/01-fake-agent-telegram-bot
cp .env.example .env
docker compose upIn another terminal, send a message:
curl -X POST http://localhost:8080/message \
-H "Content-Type: application/json" \
-d '{"message": "hello"}'You'll see the mock agent "think" and respond with Echo: hello. That's the full pipeline — channel receives message, routes to agent, agent streams response back.
Want to connect Telegram? Add your bot token to .env and set TELEGRAM_ENABLED=true. See the Getting Started guide for deploying with a real agent.
Anyclaw ships with these extensions in ext/, ready to use:
| Type | Name | Description |
|---|---|---|
| Agent | mock-agent | Echo agent with simulated thinking (for testing) |
| Agent | acp-bridge | ACP↔HTTP bridge — connect REST/SSE agents to anyclaw |
| Channel | telegram | Telegram bot integration |
| Channel | debug-http | HTTP + SSE endpoint for development and testing |
| Tool | system-info | Demo MCP tool returning system information |
We're actively growing this collection. If you build a channel, tool, or agent adapter that others would find useful, consider contributing it.
Extensions are standalone binaries communicating over stdio — no SDK dependency required. The Rust SDK crates handle protocol framing for you, but you can also speak the wire protocol directly from any language.
| Crate | What it does | docs.rs |
|---|---|---|
anyclaw-sdk-channel |
Build channel integrations (Telegram, Slack, etc.) | docs |
anyclaw-sdk-tool |
Build MCP-compatible tool servers | docs |
anyclaw-sdk-types |
Shared wire types used across all SDK crates | docs |
anyclaw-sdk-agent |
Supervisor-side hooks for intercepting agent messages | docs |
For channels and tools, implement a trait and hand it to the SDK harness — it handles all JSON-RPC/MCP framing. Agents speak the ACP wire protocol directly and don't need an SDK crate.
See Building Extensions for the full guide, including how to build extensions in non-Rust languages.
We're working toward a stable v1.0. Here's where things stand:
| Feature | Status | Notes |
|---|---|---|
| Three-manager supervisor (tools → agents → channels) | ✅ | |
| Per-subprocess crash recovery with exponential backoff | ✅ | |
| Crash loop detection and escalation | ✅ | |
| Graceful shutdown with per-manager timeouts | ✅ | |
| Health check loop + admin HTTP server | ✅ | |
YAML config with !env tag resolution and validation |
✅ | |
JSON Schema for anyclaw.yaml (IDE autocomplete) |
✅ | |
| Extension defaults via initialize handshake | ✅ | |
| Agent-initiated messages | planned | Agents can push to channels without user input — unblocks scheduling, webhooks, agent-to-agent |
| Rate limiting | planned | Per-session and per-channel depth caps with backpressure |
| Rich media delivery | planned | Route images, files, audio between agents and channels |
| Supervisor API with authentication | planned | Authenticated HTTP API for session introspection, agent control, and runtime status |
anyclaw doctor |
planned | Config validation, binary probes, channel connectivity checks |
| Feature | Status | Notes |
|---|---|---|
| ACP protocol (JSON-RPC 2.0 over stdio) | ✅ | |
| ACP↔HTTP bridge (connect any REST/SSE agent) | ✅ | |
| Docker workspace (run agents in containers) | ✅ | |
| Session persistence (SQLite-backed) | ✅ | |
| Session recovery after crash | ✅ | |
| Filesystem sandboxing | ✅ | |
| Permission system (agent → user approval flow) | ✅ | |
| Agent-to-agent communication | planned | Handoff, delegation, or direct IPC between agents |
| Feature | Status | Notes |
|---|---|---|
| Telegram | ✅ | |
| Debug HTTP (development + testing) | ✅ | |
| Telegram: reply/thread context | planned | Agent knows which message the user is replying to |
| Telegram: group/user allowlists | planned | Control who can interact with the agent |
| Feature | Status | Notes |
|---|---|---|
| MCP server hosting (external tool binaries) | ✅ | |
| WASM sandboxed tools | ✅ | Implemented, not yet battle-tested |
| Feature | Status | Notes |
|---|---|---|
| Channel, Tool, Types, Agent SDK crates on crates.io | ✅ | |
| Automated releases via release-plz | ✅ | |
| Stable API with semver guarantees | planned |
| Feature | Status | Notes |
|---|---|---|
| Cross-platform binary releases (Linux + macOS) | ✅ | |
| Multi-arch Docker images (amd64 + arm64) | ✅ | |
| PR-only workflow with conventional commit enforcement | ✅ | |
| Security audit + Trivy scanning | ✅ |
Anyclaw is infrastructure — many features are best built as extensions rather than core. Here's what we'd love to see contributed:
| Extension | Type | Status | Notes |
|---|---|---|---|
| Slack | channel | planned | Same pattern as Telegram — use the Channel SDK |
| Discord | channel | planned | |
| Task scheduler | tool | planned | Cron/interval/one-shot task CRUD via MCP (execution trigger depends on agent-initiated messages) |
Some features live entirely in the agent, not in anyclaw — skills, prompt extensions, vector memory, and knowledge graphs are configured in your agent (e.g., CLAUDE.md, AGENTS.md, MCP servers). Anyclaw doesn't need to know about them.
Have an idea? Open a feature request.
cargo build # Build all workspace members
cargo test # Unit tests (all crates)
cargo clippy --workspace # Lint all crates
# Integration tests require the mock binaries first:
cargo build --bin mock-agent --bin debug-http --bin sdk-test-tool --bin sdk-test-channel
cargo test -p anyclaw-integration-testsRust stable toolchain required. Check rust-toolchain.toml for the pinned version.
Deploy anyclaw with your own AI agent:
- Getting started — copy an example, customize, deploy
- Configuration reference — full
anyclaw.yamlschema - Container images — Docker image tags, platforms, usage
- Examples — ready-to-run setups (fake agent, OpenCode, Kiro, Claude Code)
- Changelog — binary release history
Build a custom channel (Slack, Discord, etc.), tool, or agent in any language:
- Building extensions — start here: pattern overview, SDK vs wire protocol, testing
- ext/agents/AGENTS.md — ACP wire format (for building agent binaries in any language)
- ext/channels/AGENTS.md — Channel trait, harness, testing utilities
- ext/tools/AGENTS.md — Tool trait, MCP server, WASM tools
- Architecture overview — system design, protocol details
- Contributing guide — workflow, tests, PR process
- Project structure — workspace layout, where to find things
- Design principles — core invariants, anti-patterns
- Releasing — how releases work
- Support — how to get help
We welcome contributions — especially new channel integrations, tools, and agent variants. See CONTRIBUTING.md for the workflow, and check E-help-wanted issues for a starting point.
Architecture overview
┌─────────────────────────────┐
│ Supervisor │
│ (boot: tools→agents→chans) │
└──────────────┬──────────────┘
│
┌────────────────────────────┼────────────────────────────┐
│ │ │
┌────────▼────────┐ ┌──────────▼───────────┐ ┌──────────▼──────────┐
│ ToolsManager │ │ AgentsManager │ │ ChannelsManager │
│ │ │ │ │ │
│ MCP servers │ │ ACP subprocess │ │ Telegram │
│ WASM sandbox │◄───────│ (JSON-RPC/stdio) │◄────│ debug-http │
└─────────────────┘ └──────────────────────┘ └─────────────────────┘
▲ ▲ │
│ tool URLs │ route messages │ user messages
└───────────────────────────┘◄───────────────────────────┘
Three managers communicate exclusively through typed mpsc channels via ManagerHandle<C>. No shared mutable state crosses manager boundaries. Each subprocess has its own crash recovery loop with exponential backoff.
Boot order is tools → agents → channels because agents need tool URLs during initialization, and channels need agents ready to accept messages. Shutdown is reverse order.
Anyclaw draws inspiration from these projects:
- nanoclaw — lightweight TypeScript personal AI assistant bridging messaging channels to Claude agents in isolated containers
- openclaw — feature-rich TypeScript AI assistant gateway with 20+ channel integrations and an ACP bridge
- ironclaw — Rust personal AI assistant with WASM-sandboxed tools, MCP support, and PostgreSQL-backed memory
Where these projects are complete AI assistants, anyclaw takes their architectural ideas — channel abstraction, tool sandboxing, protocol-driven communication — and applies them as a standalone infrastructure layer that any agent can plug into.
Licensed under either of:
at your option.