Architecture

One request, five stages. The stages are separate processes with separate failure modes, which is why a broken part degrades the system rather than taking it down — and, as of October 2026, why several spaces keep working while the central routing service is scaled down.

1. 1

   Intent arrives

   Typed or sent from a messaging channel. Telegram is received by OpenFang, WhatsApp by OpenClaw. Voice is designed as a third entry point but is not working today.

2. 2

   The Brain classifies

   Matched against the capability registry by regex first. Without a hit, a classifier sends the request to a direct model answer or to a planner model that breaks it into steps. There is no space filter in this step.

3. 3

   The Brain dispatches

   The Brain’s plan executor runs each step against an execution target — the database, a direct Python call, an OpenFang agent, an MCP tool, the coding engine and others. Steps for OpenFang agents go through a job queue with a validated handoff.

4. 4

   OpenFang executes

   The runtime hands the job to an agent — today mostly a Claude Code subprocess with a timeout — which calls whichever tools it is bound to. A follow-up loop checks the result before it is marked delivered.

5. 5

   The graph remembers

   The executed plan is logged and decisions are written to the vector store. Whether that makes later routing measurably better is not something we have verified.

Why the layers are separate processes

Routing and background learning ran in one process early on, and that was a mistake. Background learning loops are CPU-bound and they starved the HTTP path that users were waiting on. Splitting them means the request path stays responsive while background work runs.

Earlier versions of this page also said that receiving and sending are split between different components. They are not: each channel is received and answered by the same gateway. See Channels.

What is shared and what is not