Multi-agent orchestration in OpenClaw: how does it work under the hood?

OpenClaw has generated significant discussion since its launch. It is a prominent entity in the field, though opinions on its current status are mixed. OpenClaw is viewed by some as having already attained Artificial General Intelligence (AGI). On the flip side, others see it as a key, early move toward getting real model intelligence.

For those of us with a technical background, the initial enthusiasm for OpenClaw naturally leads to a desire to understand its inner workings. This urge to "look behind the curtain" is easily satisfied, as OpenClaw is an open-source project built with popular technologies like Node.js. The complete source code is readily accessible on GitHub.

OpenClaw isn't sentient. It doesn't think. It doesn't have any reasoning. It's just inputs, queues, and a loop. But you've seen the videos. Agents calling their owners at 3:00 AM. Agents texting people's wives and having full conversations. Agents that browse Twitter overnight and improve themselves.

In response, people are genuinely asking if this thing's sentient. If we've crossed some kind of threshold, if this is the beginning of something we can't control. But when we started asking how it actually works we confirmed the answer isn't magic. It's a feat of elegant engineering.
 

OpenClaw, the open-source AI assistant, was started by Peter Steinberger, who is also the awesome creator of PSPDFKit. Just the basics to kick things off!

OpenClaw is an agent runtime with a gateway in front of it. This gateway routes inputs to agents. The agents do the actual work. The gateway manages the traffic. The gateway is the key to understanding everything. It's a long-running process that sits on your machine, constantly accepting connections. It connects to your messaging apps, WhatsApp, Telegram, Discord, iMessage, Slack, and it routes messages to AI agents that can actually do things on your computer.

The gateway doesn't think. It doesn't reason. Doesn't decide anything interesting. All it does is accept inputs and route them to the right place. This is the part that matters. OpenClaw treats many different things as input, not just the chat messages.

There are five types of input. When you combine them, you get a system that looks autonomous.
But it's not. It's just reactive.

OpenClaw's operations are fundamentally driven by diverse inputs. These sources include human messages, regular timer heartbeats, scheduled cron jobs, internal state change hooks, and external system webhooks. Additionally, Agents possess the unique capability to communicate with one another.
 

Let's step through each one. Messages are the obvious one. You send a text, whether it's WhatsApp, Telegram, or Slack. The gateway receives it and routes it to an agent, and then you get a response.

The basic conversation flow is standard: you initiate, and it replies. The key feature is how sessions are managed: they are channel-specific. This means contacting the service via WhatsApp and then switching to Slack will create two distinct sessions, each with its own independent context.
 

Now, let’s move to the interesting things: heartbeats. The heartbeat is just a timer. By default, it fires every 30 minutes. When it fires, the gateway schedules an agent turn just like it would a chat message. Every 30 minutes, the timer fires and sends the agent a prompt. That prompt might say, "Check my inbox for anything urgent. Review my calendar. Look for overdue tasks."

The agent operates solely on instructions, like any standard message. It utilizes connected resources – such as email and calendar access – to gather the requested information and provide a report.

If no urgent matter is detected, the agent sends a suppressed "Heartbeat OK" token, meaning you won't see any notification. However, if something requires immediate attention, the system will send you a ping.

You have the flexibility to customize the agent's behavior, including its active hours, the prompt it uses, and the frequency of its checks.

But the core idea is simple: time itself becomes an input. This is the secret sauce. This is why OpenClaw feels so proactive. The agent keeps doing things even when you're not talking to it. But it's not really thinking. It's just responding to these timer events that you've preconfigured.
 

Crons offer more precise control compared to simple heartbeats. Rather than setting a regular interval, you define exact firing times and the instructions to be executed. For instance, you could schedule a cron to check and flag urgent emails every day at 9:00 AM, or to browse Twitter and save interesting posts at midnight.

A cron job functions as a scheduled event, each with a specific prompt. When the scheduled time arrives, the event triggers, sending its prompt to the agent for execution.

Consider the agent that began texting its owner's wife as an example. This was the result of a cron job, not the agent's independent decision-making. The user had programmed events like "Good morning" at 8 AM, "Good night" at 10 PM, and various random check-ins throughout the day. In these instances, a cron event fired, the agent processed the prompt, and the resulting action happened to be "Send a message." This illustrates a simple, programmed sequence.

Finally, there are webhooks. They've been around for a long time. We, as software engineers, are using them a lot. They allow external systems to talk to one another. When an email hits your inbox, a webhook might fire, notifying OpenClaw about it.

A Jira ticket gets created – another webhook. OpenClaw can receive webhooks from basically anything. Slack, Discord, GitHub, they all have webhooks. So now your agent doesn't just respond to you, it responds to your entire digital life. Email comes in, agent processes it. Calendar event approaches, agent reminds you. Jira ticket assigned, agent can start researching.
 

Another input type is messages from other agents, enabling OpenClaw to support multi-agent configurations. This setup allows for separate agents, each with isolated workspaces, to exchange messages.

Agents can be assigned distinct profiles – for instance, one acting as a research agent and another as a writing agent. When an agent completes a task, it can place new work into the queue for a different agent. While this mechanism appears to be collaboration, it fundamentally functions through messages being added to queues.
 

The example of the agent calling its owner at 3:00 AM might look like autonomous behavior – as if the agent decided to find a number, wait, and then make the call. However, the reality under the hood is different.
Here's the mechanism:

Crucially, the owner did not prompt this action in the moment. Instead, this behavior was enabled during the agent's initial setup. No "thinking" or "deciding" took place overnight. The process is simply: Time produced an event -> The event kicked off the agent -> The agent followed its instructions.

Time creates events through heartbeats and crons. Humans create events through messages. External systems create events through webhooks. Internal state changes create events through hooks. And agents create events for other agents. All of them enter a queue. The queue gets processed. Agents execute. State persists. And that's the key.

OpenClaw uses local markdown (.md) files for storage, which hold your preferences, conversation history, and context from prior sessions. This allows the agent to "remember" previous discussions when it reactivates, giving the impression of sentience – a system acting autonomously, making decisions, and appearing alive.

However, OpenClaw is not learning in real-time. Instead, it operates on a continuous cycle: reading these accessible text files for input and queues, and then continuing its loop from the outside.

This deep system access is what enables OpenClaw's capabilities, a topic to be explored in a subsequent post.
 

This system might look like magic, but it's really just a super-smart framework built on four core components that constantly work together:

Any AI agent framework that feels "alive" uses a setup like this – a continuous process, whether it's through simple heartbeats, scheduled cron jobs, external webhooks, or its own internal event loop.

At Intercode, we are actively developing components of this architecture. For instance, an ingestion job processes a review, categorizes it, and may trigger an event if the sentiment falls below a set threshold. Similarly, a user's chatbot message can activate a tool to create a ticket that functions as a reminder.

Furthermore, an agent spotting a negative trend in a report can trigger a smart alert. These simple, interconnected components are the foundation for building complex systems – a task that necessitates the expertise of a software engineer.