OpenClaw Series

Controlling Output

It’s not just what goes into the model. It’s where and how it responds.

Part 5 of 7 Feb 23, 2026
Cinematic image of signals being routed through controlled channels

Output Is Surface Area

By this point, input was disciplined.

Memory was controlled. Web results were minimized. Context was budgeted.

But something else was expanding quietly:

Output behavior.

Where Kai responded. How it responded. And how much it responded.

Once I started tightening inputs, the next problem became easier to see: Kai could still create confusion just by answering in the wrong place.

The Prompt That Started It

I like the idea of the prompt specifying whether to respond in another channel. Discord has nice thread capabilities so it may provide a better summary for an initiative fed from Telegram. Can we make this a skill perhaps? Where the default behavior is to respond within the receiving channel.

This wasn’t about adding another integration.

It was about communication control.

I had already seen the practical version of the problem:

  • a summary that belonged in Discord staying in Telegram
  • a response that should have stayed local getting duplicated elsewhere
  • too much detail landing in a channel that only needed the short version

Default Behavior Matters

Without explicit routing rules, an agent can:

  • Respond in the wrong place.
  • Duplicate output across platforms.
  • Expand responses unnecessarily.
  • Leak context between initiatives.

The fix wasn’t technical complexity.

It was policy.

Default behavior became:

Respond in the receiving channel.

Only override when explicitly instructed.

That small rule reduced ambiguity dramatically.

Turning It Into a Skill

Instead of hardcoding behavior, it became a skill layer.

This allowed structured controls like:

  • Context minimizer
  • Strict memory enforcement
  • Mode overrides
  • Compact web search
  • Channel routing control

The idea was simple:

Output is not free-form.

It is governed.

SUMMARY_TO: discord

A lightweight directive emerged:

SUMMARY_TO: discord Do something and summarize.

Instead of sending full implementation details to a collaborative channel, the runtime could:

  • Execute in one channel
  • Summarize in another
  • Preserve structure
  • Maintain readability

But this revealed a new issue.

Direct cross-channel posting created tight coupling.

Which led to the next evolution.


The Relay

Instead of letting Kai post directly into multiple channels, a relay layer was introduced.

OpenClaw emits structured intent.

The relay handles delivery.

That separation:

  • Simplifies agent logic
  • Centralizes routing policy
  • Reduces duplication
  • Improves auditability

The model decides what to communicate.

The relay decides where it goes.

That distinction is subtle.

But it makes the system much easier to live with.

What wasn’t easy to live with was realizing how much of that progress could disappear after a single upgrade.

Want the next chapter automatically?