Current system

ClawSuite Relay

A delegation and relay layer for Discord-backed OpenClaw systems. Named specialists work in their own persistent sessions, hand off to each other through visible channels, and maintain continuity across turns — without cron gaps or quality-degrading turn stretching.

View repository

Overview

The problem Relay solves

There are two common ways to keep multi-agent work flowing: cron or polling, which introduces gaps that break continuity, or stretching turn duration, which degrades quality as the turn gets overloaded. Hooks solve sequencing but not identity — the next agent starts fresh, with no persistent workspace and no trail of who asked what.

In many cron-driven agent setups, that "fresh" part is literal: each scheduled turn is effectively a cold start that rebuilds continuity only from files on disk. Relay differs because the receiving specialist continues in its own live session rather than reconstructing itself from scratch every fire.

I built Relay so that each specialist works in its own persistent session. Dispatches arrive in the agent's channel, responses route back through a traceable path, and the operator can follow the whole exchange instead of guessing what happened inside a black box.

The current public implementation is specific: an OpenClaw plugin using Discord channels and webhooks as the relay surface.

When you need it

When single-agent setups stop working

You are stretching turn duration to keep work in one agent, and quality is suffering.
You are using cron or polling to sequence agents, and continuity breaks across the gaps.
Specialists need to hand work to each other, not pretend to do everything in one session.
The operator needs to see who acted, on what authority, and what came back.

What it does

In practice

Each specialist works in its own persistent channel session — not spun up and torn down per task.
Dispatches arrive in the agent's workspace; responses route back through a traceable path.
Supports sustained back-and-forth at natural turn length, not one-shot fire-and-forget.
Gives the operator a readable trail of what happened and why.

Use case 01

Continuous work without overloading one turn

One practical pattern is to keep the same workstream moving across two persistent agent channels that share a workspace. The first agent hands off, the second agent continues in its own channel, and the thread keeps going without trying to force the whole exchange through one increasingly overloaded turn.

That second lane does not always need to be a deeply specialized agent. Sometimes it is a true collaborator with its own role and context. Sometimes it is more like a deliberate receiving wall that lets the main agent continue naturally at normal turn length instead of stretching one session until quality drops.

Use case 02

Persistent quality control

Another pattern is to use a second agent as a standing quality-control lane. Instead of a one-shot review subtask, the reviewer has its own persistent channel and can push back, ask for clarification, or send work back for another pass through a traceable exchange.

In simple setups that can be a two-agent ping-pong. In more ambitious ones it can become a round-robin across multiple perspectives. The important point is that review is treated as an ongoing role with continuity, not as a disposable helper call.

Where it clicked

The CFO that held on its own

During a real workstream, the CEO agent had dispatched tasks across several specialists. I stepped in as the human operator and overrode the CEO's authority: stop responding to CEO-routed execution tasks.

The specialists respected the override. Later, I issued a partial resume — intending to unblock only part of the paused work. The agents interpreted the resume as scoped rather than blanket, which was the right call.

Then the interesting part. The CFO agent later received a new request through a different channel. It independently recognized the request as related to the paused workstream and held for explicit clearance rather than proceeding. Nobody told it to do that. The system had preserved enough cross-agent context for the CFO to make a cautious judgment on its own: this might still fall under the original restriction.

That is the kind of behavior Relay is designed to support — not just message routing, but enough persistent context for authority and caution to survive across specialists and turns.

What the operator sees

A real relay trace

A systems agent reports fixes are done and asks for approval to restart the gateway.
An executive agent relays the recommendation and approves the restart.
The restart is announced in-channel, with the expected interruption visible to me.
Stale responses start draining. The system identifies them as stale rather than treating them as new work.
I can follow the whole sequence as legible operations instead of guessing what happened.

What it is not

What Relay does not claim

Not a claim that agents replace human supervision.
Not a black-box orchestrator that hides who delegated what.
Not just parallel spawning with one return payload at the end.
Useful because it preserves a readable chain of responsibility, not because it sounds futuristic.
Not a claim that the agents have human agency. The useful questions are operational: what role did this specialist occupy, what instruction controlled the handoff, what context traveled, and where did human authority remain visible?

Why it matters

Where agent systems usually fall apart

Most agent setups look fine until work has to cross a boundary — between specialists, sessions, or authority contexts. That is where continuity gets lost and the human ends up manually reconstructing what the system was supposed to remember.

Relay does not eliminate coordination problems. It makes delegation more durable by keeping the crossing visible instead of hiding it.

Compared with alternatives

Why hooks, cron, and subagents are not enough

Subagents are good for independent tasks: produce an answer, return it, disappear. Hooks and cron solve sequencing, but many cron-based agent loops are effectively repeated cold starts. Relay is for work that needs persistent identity, readable history, and real back-and-forth between specialists who inhabit their roles across turns.

That matters for legibility too. In many scheduled isolated runs, the operator mainly sees the final surfaced output rather than a specialist visibly working in its own ongoing lane. Relay keeps both the continuity and the handoff easier to inspect.

The difference matters whenever quality depends on continuity rather than parallel throughput or blind sequencing.

Hardening

What broke in real use

Relay was not designed from first principles alone. I pushed it until the weak points showed up, then hardened around them.

Conversation fatigue after long chains — the exchange simply dropped.
Batch-and-blast behavior — agents optimized for completion instead of relay discipline.
Initiation reliability — some models handled the recipient role better than the dispatch role.
Practical safeguards that had to be added: dispatch correlation, stale-response guards, turn limits, kill switches.

After hardening — both in the transport layer and through lightweight workflow discipline on top — I have sustained a 64-turn cross-model relay between Claude Opus 4.6 and GPT 5.4. At that point, the remaining failure modes are more technical than behavioral — context compaction, not agent discipline.

A note on language

What "persistence" and "agent" really mean here

Relay runs on OpenClaw, and OpenClaw's framing is frankly anthropomorphic: agents, persistence, specialists, continuity, memory. Some of that framing is genuinely aspirational — naming the thing you are trying to build into existence — and some of it is a cleaner marketing surface than the underlying mechanism deserves. The honest version, as users are quick to point out once they run the tools for a while, is that a lot of what gets called "persistence" is closer to a task scheduler plus scheduled context loading, and a lot of what gets called an "agent" is a named role with a system prompt, a file workspace, and a history of prior turns.

I think the anthropomorphic framing explained some of OpenClaw's early adoption. It is easier to reach for an assistant-shaped mental model than for a pipeline-shaped one, and human-like language makes the product legible to people who have not yet had to debug it. I am not arguing that the framing was wrong to use. I am arguing that it is worth saying out loud what is under the framing, because the place the framing breaks is also the place users most need to understand the mechanism in order to use the tool well.

Relay's posture, on this page and in the code, is to keep the operational meaning of every framing term visible. A "specialist" here is a named role plus a persistent channel session plus a context file surface. "Continuity" is the visible trail of dispatches and responses across those sessions, not an inner state the agent is holding in its head. "Authority" is whatever the operator granted and whatever the handoff structure passed along — not something the system has on its own. The framing is useful. The mechanism under the framing is what the tool actually is.

What comes next

Active development

Relay patterns and worked examples from real use
Stronger control over long-chain dispatches
Additional case studies
Architecture notes tied to the public codebase