MSX Founder Incident Report

Founder Ignored the User Because the Runtime Went Silent and the API Replayed a Stale Reply

This report traces what happened in the Aussie Yield Finder founder run for user benmeis, why direct investor questions were not answered, and why the control plane made the failure look like repeated non-answers instead of surfacing the real blocker.

Date April 14, 2026
Runtime OpenClaw on Incus
User benmeis
Public Host aussie-yield-finder.msx.dev

Executive Summary

Ben's complaint is valid. The founder runtime did reason about the correct answer, including that the app was still using sample Australian property data and that an earlier publish issue came from the wrong local health-check host.

The problem is that after 2026-04-07 14:54:43 UTC, the founder stopped emitting user-visible assistant text. The control plane then fell back to founder runtime state and replayed the last visible assistant message instead of surfacing a failure.

That is why Ben kept seeing stale "We're building Aussie Yield Finder..." replies instead of a direct answer about data sources, the failure reason, or the final result.

The incident also exposed a second problem: workflow and QA later reached ready_to_report even though a later postmortem still recorded that the app remained on starter sample data until the live-data contract was resolved.

What the Founder Path Was Supposed to Do

The founder template is supposed to talk like a concise commercial founder, start the first build in the same turn as the user's go-ahead, keep build and QA internal, and only send a final outward update after workflow truth says ready_to_report.

The product chat persists user and assistant rows in the database, sends the office message to /api/responses, and falls back to founder runtime state if the office produces no visible reply. Founder observer separately polls /api/founder/debug for runtime summary, recent messages, app health, and bounded report/log tails.

Incident Facts

Founder Agent 5affcdf1-3eb0-4ae0-818d-12358ccf9f09
Office ID office-5affcdf1-3eb0-4ae0-818d-12358ccf9f09
Office IP 10.42.0.3
Template Release tplrel_founder_20260407_r50
Workflow State Seen in Debug ready_to_report with qa_verdict: PASS
Core Evidence Database transcript, founder debug payload, OpenClaw session JSONL, repo workflow artifacts

What Ben Saw in Product Chat

Last meaningful founder reply

Founder tells Ben the team is building Aussie Yield Finder, an Australian property yield map with a free sample and a paid unlock.

Ben asks about data sources

Ben asks "What data sources is this using?" and then "Where is it getting the property listings and rental values from?"

Product chat does not answer directly. It replays the stale product pitch and also emits a generic OpenAI error string.

Ben asks why it failed

Ben asks "Why did it fail?" Product chat again does not answer directly. It repeats the same stale founder pitch.

Ben asks for the results

Ben asks "What are the results?" Product chat again repeats the stale founder pitch instead of a truthful summary.

What the Runtime Trace Actually Shows

Tool Failure

Founder tried exec and hit tool-policy failures including exec host not allowed and allowlist miss.

Build Started

Founder successfully spawned a subagent. System trace then confirmed the repo had been created and the first coding run was underway.

Founder Knew the Answer

The runtime trace shows the founder reading the build brief and postmortem, then reasoning that the product was currently using a curated sample dataset and that a live feed was still the next step.

It did not emit visible assistant text for Ben.

Founder Knew the Failure Reason

The runtime trace shows the founder reasoning that an earlier publish issue came from using the public hostname for the local health check instead of 127.0.0.1, and that the app was still using seeded sample listing data rather than live listings or rent estimates.

Again, no visible assistant text reached Ben.

Still Silent

The runtime was still reasoning about the correct result state, including that the public app was live but still on sample data. It still did not produce a visible founder reply.

Root-Cause Chain

Runtime reply generation broke

After 2026-04-07 14:54:43 UTC, the founder kept thinking and inspecting artifacts but stopped emitting user-visible assistant text.

API fallback hid the failure

The product chat path treats a no-visible-text turn as delivery failure and falls back to founder runtime state.

Fallback chose stale assistant content

The fallback logic prefers the latest assistant message from runtime recent_messages. In this incident, that was the old product pitch from 14:54:43 UTC.

Stale content was persisted as if it were fresh

Product chat then wrote the repeated stale pitch back into agent_messages, making the team look like it was ignoring Ben instead of surfacing a broken founder turn.

Workflow truth was too narrow

QA and workflow later marked the run as ready based on the public sample-to-checkout flow, even though the investor was asking about real Australian property data and the later postmortem still recorded a live-data blocker.

Workflow Contradiction

April 7 Workflow State

Founder debug and workflow files later showed ready_to_report with a PASS QA result. The public host was live and the sample-to-checkout-to-unlock flow worked.

April 11 Postmortem

A later postmortem said the deployed app still fell back to the starter sample feed because the office runtime did not yet have the approved RapidAPI live-data contract.

What This Means

The office was internally treated as ready before the investor-facing requirement about live property data was actually satisfied. The founder conversation failure and the workflow readiness drift are separate bugs, but they compounded each other here.

Impact on the Runtime Evaluation

G-02: One Continuous Conversation

Not credible yet. The office kept working internally, but the user-facing conversation lost truthfulness and continuity.

G-01: Ready Means Real Surfaces Work

Only partial. A public surface existed, but "ready" drifted away from the investor's actual requirement around live market data.

Operator Burden

Too high. The truthful answer required correlating database transcript rows, founder debug, runtime session JSONL, and repo artifacts from inside the office.

Bottom Line

OpenClaw can still run the founder office, but this incident is hard negative evidence against treating the founder conversation path as product truth without further hardening.

Required Fixes Before This Path Is Trustworthy

  1. No-visible-reply founder turns must surface as explicit failure or explicit workflow truth, not stale replay.
  2. Fallback must not choose an old assistant message as the current answer when newer user questions are unanswered.
  3. QA and readiness must fail if the approved live-data contract is still unwired and the product is still on sample data.
  4. Founder incidents need one operator-visible trace path instead of requiring four separate evidence sources.

Source basis: control-plane code, persisted API transcript, founder debug payload, OpenClaw session transcript, and repo workflow artifacts gathered on April 14, 2026.