Controlling Output
It’s not just what goes into the model. It’s where and how it responds.
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?