What reached users, operators or an upstream project — the outcome, not just the code.
- Agentbot public platform and developer-facing surfaces are available at agentbot.sh
TECHNICAL CASE STUDY / AI INFRASTRUCTURE · AGENT SYSTEMS
Agentbot
An operating layer for deploying, connecting and supervising AI workers.
A multi-surface AI agent platform built around the OpenClaw runtime. The product combines a Next.js operator console, backend identity and state services, a communications gateway, model routing, developer tooling and creator-focused agent workflows.
Platform artwork
DELIVERY EVIDENCE / ENGINEERING MATURITY
What reached the real world.
Delivered outcomes come first. The remaining categories show what is implemented, what has test evidence, what is deployed and what is still staged or planned.
Capabilities evidenced in source code or project documentation.
- Public mirror contains web, backend and gateway packages with documented Express services
- OpenClaw runtime connectivity, model-routing integrations and operator surfaces are described in source and architecture documents
- Security controls are documented in the repository; this is not independent security certification
Automated test coverage or documented test evidence; not a blanket passing-build guarantee.
- Repository manifests and public documentation provide implementation evidence; no current passing test run or independent security assessment is claimed here
Live product surfaces or historically operated deployments, with scope stated.
- Agentbot platform is available at agentbot.sh
- Repository documentation describes Railway-managed OpenClaw runtimes and Vercel AI Gateway inference
Known release boundaries, future work or areas not claimed as complete.
- P2P networking and the trust-score system are explicitly identified as future work in the architecture documentation
THE PROBLEM
Why this needed
to be engineered.
Running useful agents in production is an infrastructure problem, not simply a chat UI problem. Operators need to provision and supervise runtimes, connect messaging and tools, route inference, preserve state, enforce identity and permissions, and understand what each worker is doing.
Organise the platform into distinct product and service boundaries: a Next.js control surface, backend APIs for identity and state, a gateway for runtime and channel connectivity, and OpenClaw as the agent execution layer. Keep mutable operational data in the application database while using Git-backed mirroring for independently inspectable state history.
SYSTEM ARCHITECTURE
How the pieces fit together.
01
Next.js 16 App Router application for the public site, Creator Console, operator dashboards and platform APIs
02
Node.js / Express backend package for agent identity, state management and platform integrations
03
Gateway service using Express, HTTP proxying and WebSockets to manage OpenClaw gateway connectivity
04
OpenClaw 2026.4.26 as the agent runtime, with managed runtime provisioning documented against Railway
05
PostgreSQL with Prisma for application records, plus Upstash Redis for caching and coordination
06
Vercel AI SDK and Vercel AI Gateway for provider abstraction and model routing; MiMo V2 Pro is documented as the Factory Master model
07
GitLawb integration for signed, content-addressed mirroring of agent configuration and state changes
08
Monorepo managed with npm workspaces and Turborepo across web, backend and gateway packages
09
Supporting surfaces include Fleet Control, Ops Command Center, Agentbot Coach, Bitcoin dashboard and Creator Toolkit
TECHNOLOGY CHOICES
Tools chosen for the job.
Separate the control plane from the runtime
The web application and backend manage identity, configuration and operator workflows; OpenClaw provides the agent runtime. A dedicated gateway package handles proxy and WebSocket connectivity instead of coupling runtime traffic to dashboard components.
Use a provider abstraction for inference
The web package includes Vercel AI SDK and AI Gateway dependencies. Repository documentation identifies Xiaomi MiMo V2 Pro as the default Factory Master model, while the gateway provides a provider-routing boundary.
Keep operational state and verifiable history distinct
The architecture describes PostgreSQL as hot application storage and GitLawb as a warm, content-addressed mirror for signed configuration history. The mirror is an audit and portability layer, not a replacement for transactional application storage.
Make security a backend responsibility
The security documentation describes hashed API-key storage, constant-time bearer-token comparison, PostgreSQL row-level security, atomic invite-code consumption, webhook signature verification and fail-closed handling.
Treat runtime isolation as an infrastructure boundary
The security policy documents per-agent Docker containers with resource limits and restricted host access. The case study describes this as the documented isolation model, not as an independently audited security certification.
Publish source without publishing production secrets
The public repository README explicitly identifies the repository as a code mirror synced from a private production repository. Production credentials and private configuration are kept out of the public source.
ENGINEERING CHALLENGES
Problems solved along the way.
Multiple execution and integration boundaries
The platform has to coordinate the dashboard, backend APIs, gateway, OpenClaw runtime, model providers and external messaging or tool integrations without treating them as one monolithic process.
Identity, authorisation and tenant isolation
The published security policy documents hashed API keys, constant-time token checks, PostgreSQL RLS and fail-closed access checks. The architecture documentation separately describes DID-native signed requests; these are documented as distinct identity mechanisms rather than collapsed into one claim.
Webhook and network attack surface
The security policy describes Stripe HMAC-SHA256 and Discord Ed25519 verification, fail-closed handling for other webhook sources, and SSRF controls for private, local, IPv6 and carrier-grade NAT address ranges.
Agent runtime containment
The documented Docker model limits filesystem access, CPU and memory and restricts access to the host and other containers. This creates a defined boundary between agent execution and the platform host.
Operational breadth
The codebase spans fleet operations, training, Bitcoin tooling, creator workflows and public developer surfaces. The monorepo separates web, backend and gateway packages so these capabilities can evolve without collapsing their service boundaries.
SOURCE & VERIFICATION
Inspect the work.
Public source mirror and project overview↗Published architecture document↗Security policy and documented controls↗Monorepo workspace and dependency manifest↗Web application dependencies and build scripts↗Backend service dependencies↗Gateway service dependencies↗Feature and codebase inventory (April 2026)↗Developer documentation↗Platform documentation↗
This case study is based on the public source mirror and its published documentation; the README says production code is synced from a private repository and that production secrets remain private. The repository describes Railway-managed OpenClaw runtimes and Vercel AI Gateway inference. Architecture documents contain both DID/signature-based identity patterns and bearer/API-key controls; these are presented as separate documented mechanisms, not as proof that every route uses both. The Docker isolation and security controls are repository-documented design claims, not the result of an independent penetration test. The April 2026 feature inventory includes both implemented features and explicitly marked placeholders; a listed route or dashboard surface is not by itself proof of production readiness. P2P networking and the trust-score system are identified as future work in the architecture document.
NEXT / START A PROJECT
Have a similar challenge?
Tell me what you are trying to build. We can scope the right next step.