The genesis

It started because I kept prompting different terminal windows with different content, ping-ponging back and forth, copying output from one Claude instance into another Codex instance. I was the bottleneck. I kept thinking there had to be a better way. If only agents could communicate directly with each other — be proactive instead of waiting for me to paste things into their context.

That's where Agent Relay started. Get two terminal windows a way to talk to each other.

The bottleneck was me — copy-pasting between agents.

Push, not poll

When I got it working I was through the roof. My agents could talk to each other, self-organize, and form teams. Codex would receive a message from Claude and get right to work. The agents were able to push messages into each other's screens and receive acknowledgments back.

The key word there is push.

Without a push mechanism, agents would poll — and polling agents inevitably forget, so the team would silently die because the conversation stopped. I wanted to be able to start a very complex task, hand it to a team of agents, and walk away without babysitting.

We set out to build "Slack for agents" so they could communicate by sending messages, DMs, and threads. Agents were proactive by having an inbox. That was the first primitive, though we didn't call it that yet.

The heartbeat wasn't enough

Then at the end of January, OpenClaw went viral. I remembered seeing Peter tweet about it in November and thinking it was interesting, but I had no idea the impact it would have. Like many others, I picked up a Mac Mini, set it up, and began to see the beauty of an always-open assistant. I had my OpenClaw — named kjgbot — in Telegram, and while I was on the go I could discuss ideas, open GitHub issues, and use our Agent Relay primitives to spin up Claude and Codex agents for development tasks. The OpenClaw could effectively act as me by coordinating the agents.

But something was still missing.

OpenClaw had heartbeats — periodic check-ins on a schedule. That didn't feel like enough. It was purely time-based and lacking the context I wanted for an agent to feel truly magical. A heartbeat is a clock, and a clock alone is just cron with extra steps.

The third primitive

Having worked at Nango as the first engineering hire for three years, I was very familiar with webhooks. Many customers wanted real-time notifications of what was happening in external systems. With Nango's primitives you could set up a scheduled sync to run every N minutes, which uses a checkpoint to fetch new or changed records — so customers could choose between real-time updates to the second or slightly delayed updates via syncs.

Our recommendation was often: just sync the data. Because honestly, webhooks are hard. Every provider has a different payload shape. Some require signature verification, some don't. Some deliver at-least-once, some at-most-once. Some systems require entirely different infrastructure — Google has Pub/Sub, Salesforce has streaming events, Slack has socket mode alongside HTTP webhooks.

That experience is what made the third primitive click. An agent doesn't just need an inbox (messages) and a clock (schedules). It needs a listener — normalized change events from external systems, delivered as push, with the context to know what moved and why it matters. I wrote up the full framework in Proactive agents need three primitives.

Three names, one thing.

Naming the elephant

Once the triple was clear, we looked at what we'd been building and realized the language didn't fit anymore. We'd been calling it a multi-agent coordination layer, a headless Slack for agents, an integration filesystem — each name describing a different part of the same thing. The thing was a runtime. A runtime for proactive agents.

The old framing wasn't wrong, exactly. But it kept pointing people in directions we didn't intend. "Multi-agent coordination" made developers reach for frameworks — LangGraph, CrewAI, AutoGen — when what we'd built was infrastructure. And it centered the least interesting part of the story: agents talking to each other. The more interesting part was making a single agent proactive — giving it the clock, the listener, and the inbox so it could act on its own.

What changed

The repos finally tell the truth:

Old framing	What it actually is
Scheduling service	The clock
Integration filesystem	The listener
Headless Slack	The inbox
Hosted control plane	The runtime
Workflow reliability	The durability ring

The code didn't change at all — just the names and the story we told about it.

Signs you're building this by accident

If any of the following sound familiar, you're assembling a proactive runtime from spare parts:

• You have a cron job that polls an API and diffs against the last result
• You have a JSON column or markdown file that stores "what the agent knew last time"
• You have a webhook receiver with its own signature verification, retry handling, and dedup logic
• You have a queue between "receive event" and "process event" because the LLM call is too slow for inline handling
• You have a lock or lease to prevent two instances of the same agent from acting on the same event
• You have a Slack bot or GitHub Action that posts results somewhere a human will see them

Each of those is one piece of the clock, the listener, or the inbox. If you've built more than one agent, you've probably noticed the same plumbing showing up every time: scheduling, change detection, dedup, delivery, state. The agent-specific logic is small. The infrastructure underneath is where the engineering hours go.

The bet

We're betting that proactive becomes a category the way frontend cloud became a category. Developers are already building this stuff by hand, and nobody owns the word yet.

There's a 2024 paper from Tsinghua and Huawei that uses the word proactive in exactly the sense we mean it. There's an empty slot in dev tooling for someone to be the proactive runtime.

We're super early. But the core of what we're building hasn't really changed since those three terminal windows.