Build Multi-Agent Systems That Don't Wake You Up
WebAssembly isolation. Observable by design. Zero external dependencies. Build distributed, resilient multi-agent systems with < 50μs overhead.
Why Caxton Exists
Current Pain Points
- Debugging distributed agent state is a nightmare
- Agent crashes affect the entire system
- No standard communication protocols
- Network partitions break everything
- Requires external databases for coordination
- Observability is an afterthought
How Caxton Solves Them
- Built-in distributed tracing for every message
- WebAssembly isolation with zero blast radius
- FIPA standard protocols out of the box
- Graceful degradation during network partitions
- No external dependencies - SWIM protocol built-in
- OpenTelemetry from day one
Core Features
WebAssembly Agent Isolation
Each agent runs in its own WebAssembly sandbox. When an agent crashes, the blast radius is zero. Like containers but 100x lighter.
FIPA Protocol Messaging
Industry-standard agent communication protocols at the application layer. Semantic messaging that works across cluster boundaries.
Observable by Design
Built-in OpenTelemetry from day one. Every message traced, every decision logged, every metric captured.
Production Performance
Designed for real workloads, not demos. Microsecond latencies, predictable resource usage, graceful degradation.
Debugging Tools
Purpose-built tools for 3 AM debugging. Trace conversations, replay events, inspect agent state, all without restarts.
Tool Integration
MCP (Model Context Protocol) bridges to external tools. Connect your agents to databases, APIs, and services.
Distributed & Resilient
Built-in clustering with SWIM protocol. No external coordination service needed. Graceful handling of network partitions.
The 3 AM Test
Every feature designed to be debugged in production
Real Debugging Scenario: Agent Conversation Timeout
Alert fires: "Agent conversation timeout"
$ caxton trace --conversation-id abc123 --last 5mSee exactly where conversation stalled
[03:23:45.123] agent="OrderProcessor" message="propose" status="sent"
[03:23:45.567] agent="InventoryChecker" message="propose" status="received"
[03:23:50.568] agent="InventoryChecker" error="tool timeout" tool="database_query"Root cause: Agent had a slow tool call
$ caxton debug agent InventoryChecker --show-metrics
Memory: 45MB/512MB | Queue: 1,523 messages | Tool calls: 15/s (p99: 5.2s)Fix: Adjust circuit breaker configuration
$ caxton config set --agent InventoryChecker \
--circuit-breaker.timeout=10s \
--circuit-breaker.threshold=3Architecture
Built for Production
Caxton follows type-driven development with a functional core and imperative shell architecture. Every architectural decision prioritizes debuggability and operational excellence.
- Agent Runtime - WebAssembly-based isolation and execution
- Message Router - FIPA protocol for semantic agent messaging across clusters
- Coordination Layer - SWIM protocol for membership, failure detection, and partition handling
- Observability Layer - OpenTelemetry integration from the ground up
- Tool Bridge - MCP protocol for external integrations and state management
- No External Dependencies - Everything built-in: SQLite for local state, SWIM for coordination
Three Views of the System
External API
:50051
:8080
Deployed Agents
Processor
Checker
Handler
MCP Tool Bridge
caxton-server (systemd service)
:8080 (REST)
:50051 (gRPC)
tokio runtime
message routing
wasmtime
512MB/instance
Coordination Layer
SQLite (embedded)
SWIM Protocol
TOML files
Observability Exports
:9090
:4317
:8081
WebAssembly Isolation
Recovery Hierarchy
Circuit Breakers
Debug Points
Getting Started
From zero to multi-agent system in 5 minutes
Install Caxton
# Install with observability stack included
curl -sSL https://caxton.dev/install.sh | sh
caxton init my-system --with-observabilityCreate Your First Agent
# Create an agent from template
caxton agent create order-processor \
--template request-handler \
--capability order-processingDeploy and Monitor
# Start with full observability
docker-compose up # Includes Jaeger, Prometheus
caxton deploy
caxton monitor --dashboardSimple Multi-Agent Example
Define Your Agent Configuration
# agent-config.yaml
name: order-processor
version: 1.0.0
runtime: wasm
capabilities:
- order-processing
- inventory-checking
resources:
memory: 128MB
timeout: 30sDeploy to Caxton Server
# Deploy your compiled WebAssembly agent
caxton agent deploy order-processor.wasm \
--config agent-config.yaml \
--replicas 3
# Verify deployment
caxton agent status order-processor
✓ Running (3/3 instances healthy)Invoke Your Agent
// Using any language with the Caxton client
const client = new CaxtonClient('https://caxton.local');
const result = await client.invoke('order-processor', {
order: {
items: ['item-123', 'item-456'],
address: { street: '123 Main St', ... }
}
});
console.log(result.tracking_number);