This is a field note from the assumption that cost us the most: I treated a fast-moving agent runtime as a stable customer substrate because the product surface was real and useful. The hard lesson was that an agent runtime is not just infrastructure. It decides what the customer sees, what the agent can say, when work is dropped, and whether internal operations become user-visible.
In a normal web app, a runtime bug might be latency, an error page, or a failed job. In a customer-facing agent, runtime behavior can become speech. That is why these are agent-safety war stories, not just operations notes.
Five incidents that changed the operating model
Channel health
The service was active, but Telegram was crash-looping
A customer reported that the agent had effectively stopped responding. The host was not simply down; the bad signal was deeper. OpenClaw 2026.4.22 repeatedly failed Telegram polling because the plugin-runtime-deps path could not resolve the openclaw package. Systemd could keep restarting the process, and a shallow health check could still make the situation look operational. The gate we needed was channel-aware: if the customer uses Telegram, the canary and verifier have to confirm Telegram is alive after restart and through soak.
Operations leakage
Internal restart and OAuth chatter reached the customer
In another incident, a Microsoft Graph lookup answered the user and then leaked operational text into Telegram: gateway restart status, token-refresh reasoning, and an operator-style doctor command. The specific bug was less important than the class: runtime maintenance is not user content. Refresh, restart, and diagnostic paths need a private operations channel, fail-fast tool errors, and regression tests that confirm restart sentinels never escape into customer chat.
Runtime defaults
A default flip streamed tool internals into chat
OpenClaw 2026.4.27 introduced a preview-streaming field whose default rendered tool progress into customer-visible channel edits. Existing tenant config did not know the field existed, so it inherited the new default. The result was a short canary exposure where tool names, an exec path, and internal draft artifacts appeared in a real customer chat. The mitigation was rollback, explicit tenant config, a migration for existing tenants, and a smoke test that triggers an exec call and confirms no tool-progress lines appear.
Upgrade discipline
The upgrade spiral grouped unrelated symptoms
The worst operational pattern was not one bug. It was grouping several symptom classes under one broad runtime-upgrade response: cron behavior, OAuth behavior, document authoring, restart slowness, prompt UX, and the runtime leak did not all share one validation path. The durable fix is procedural: before approving a broad runtime upgrade, write the symptom matrix. Tenant, symptom, owning repo, fix hypothesis, validation command, pass criterion, closure bucket.
Release ownership
A remembered patch is not a release process
Restart suppression existed as institutional memory: there had been a legacy fork branch meant to keep gateway restart notices out of user chat. During cleanup, the source of that patch was not where the review expected it to be. That is a stability lesson too. If a production behavior matters, it needs a located source, a test, a release path, and a current owner. Otherwise it is not a control; it is a story people remember until they do not.
The release discipline that came out of it
1 Treat customer channels as first-class health checks
A unit can be active while the channel a customer uses is dead. For this deployment, Telegram polling signatures became release gates: rollout and verify flows fail when crash-loop signatures appear after restart or during soak.
2 Diff defaults as behavior, not metadata
The dangerous change was not a breaking API. It was a default for a new config field. Every candidate runtime needs changelog review, config-schema diffing, and explicit tenant policy for customer-visible surfaces.
3 Keep operations text out of user channels
Restart messages, token-refresh explanations, and doctor commands are operational telemetry. They belong in logs, alerts, and operator tools, not in the same channel where the customer asked for work.
4 Require a symptom matrix before broad upgrades
When three independent symptoms appear at once, a runtime upgrade is tempting because it feels like one move. It is also how you lose causality. Each symptom needs its own owner, fix hypothesis, validation command, and closure evidence.
5 Make stability controls releasable artifacts
Known-bad version tables, restart-suppression patches, tenant config migrations, and channel smoke tests are not incident notes. They have to live in code, CI, runbooks, and release gates.
The real lesson
The hard part is that the platform was capable. That is why the assumption was easy to make. OpenClaw gave us channels, tools, skills, cron, and sessions quickly enough to ship a real product. But capability is not the same as an operating contract. Once customers depend on an agent, the runtime is no longer just a library. It is part of the safety case.
The rule I would use now is blunt: do not put a fast-moving agent runtime under customer reliance until you own the release gates around customer-visible behavior. That means pinned versions, known-bad version policy, changelog and config diffs, real-channel canaries, rollback commands typed before rollout, symptom matrices for incident closure, and tests that confirm internal operations stay internal.
The COGS article covers the economic side of the same lesson. Tokens were measurable. Runtime churn was the expensive part.
Shipping an agent on someone else's runtime?
The question is not whether the runtime is impressive. The question is whether you know what changes before a customer sees it. I help teams turn agent infrastructure into release gates, evidence, and operating discipline before the next incident teaches it the hard way.
Stay Updated
Subscribe for frameworks and engagement briefs on production AI, agents, and governed autonomy.