A case-by-case review of the seven headline problems in the opening section of the WorkCord User Journeys report. Original claims are shown separately from the verified findings.
7claims reviewed
5confirmed open
1fixed
1partly fixed
The review distinguishes a code change from a production resolution, an upload from a proven successful read, and a completed scheduled run from a successful user outcome.
Case 01
False timeouts
Fixed
Report claim
False timeouts: every sub-second figure withdrawn, replaced by per-user measurements from editedAt (e.g. ball: 82 rows, median 1805 s, 96% had an answer before the error was written)
Verified findings
The defect produced an answer and later converted its stale “Working…” placeholder into “Agent didn't respond in time.” The error-writing time alone does not show when the failure originated.
6 Aug
Correlation fix landed in code, commit 58b0f4cd.
7 Aug
Last large production batch of bad placeholders; widespread occurrence stopped.
17 Aug
Last isolated confirmed recurrence. Answer arrived at 09:25 Taipei; the error was written at 11:31.
After 17 Aug
No newly created confirmed phantom timeouts found.
31 Aug
Three old 5 August placeholders were converted when their rooms were read. These were historical leftovers, not new failures.
Status note
No further product fix is required for this incident. The few timeout messages written on 31 August came from harmless old placeholders created on 5 August, not from new failures.
Case 02
Unreadable attachments
Partly fixed · issue remains
Report claim
Unreadable attachments: the fix date is corrected to 8/12; 12 users hit it and 9 have uploaded successfully since; 慧郁 never hit it (she was wrongly named as the only one who knew)
Verified findings
The original single-file Hermes defect was fixed in stages: record permissions on 12 August, then the remaining relative-path defect on 21 August.
A separate multi-file defect remains: WorkCord stores multiple uploads in fileAttachments, but direct agent dispatch does not read that field.
On 27 August, two files sent together were unavailable to the agent; sending the same files separately succeeded.
Only 9 users have a confirmed historical content-read failure. “12 affected” is not proven.
“9 succeeded later” counts later uploads, not necessarily proven content reads.
BardSiao did upload again on 12 August, and the agent successfully read the files.
For 慧郁, no confirmed failure was found and at least one pre-fix read succeeded; “never failed” cannot be proved categorically.
Recommended fix
Forward every entry from fileAttachments during direct agent dispatch.
Add regression tests for PDFs, images, CJK filenames, and multiple files in one message.
Case 03
Rainman's "insufficient data"
Confirmed design failure
Report claim
Rainman's “insufficient data”: the 26 was a platform-wide count wrongly attributed to him — in his own rooms it is 19
Verified findings
Of the 19 matching messages, two discussed the problem and 17 were actual automatic insufficient-data reports.
The requested workflow depended on several agents, but the platform stored it under the 選戰總控 standalone tenant instead of the RoomAgent that could coordinate them. The user did not choose or request this execution context.
The Shadow accepted and scheduled a workflow it could not execute.
No upstream agent results arrived.
The prompt required an “insufficient data” output.
Hermes marked the run completed because a message was posted.
From 29–31 August, 21 jobs ran, 17 posted insufficient-data reports, and all 21 were marked completed. A correct RoomAgent v3 workflow was later added, but the obsolete Shadow schedules remained enabled.
Recommended fix
Automatically create cross-agent schedules under the capable RoomAgent, regardless of where the request was made.
Do not confirm the workflow until it is persisted and scheduled in the correct execution context.
Validate tools and execution capabilities before creating a schedule.
Do not mark “insufficient data” output as a successful job outcome.
Disable obsolete schedules when a replacement workflow is created.
Case 04
漢傑's weather brief
Not fixed
Report claim
漢傑's weather brief: the empty-data streak is 7 days (8/24–8/30); “five days” understated it
Verified findings
Seven days was correct only at that cutoff. The 31 August report was also empty, making the verified streak 8 consecutive reports, 24–31 August.
The 05:00 Taipei schedule ran successfully every day, but its agent could not reliably retrieve official weather data. Search timed out or returned irrelevant results, direct extraction had no configured backend, and the scheduled job lacked terminal, file, or a specialized weather skill.
Because the prompt prohibited invented data, the agent posted a long unavailable-data template. Hermes treated that as a successful run.
Recommended fix
Use Google Search instead of DuckDuckGo.
Configure a working webpage-extraction backend.
Give the job official-source access, such as a CWA weather skill.
Treat repeated empty or unavailable-data reports as failures.
Case 05
Stanley's five directors
Confirmed expectation failure
Report claim
Stanley's five directors: only 2 agents ever spoke in his rooms — one agent role-played all five
Verified findings
The user expected five separate agents in one live brainstorming room. The standard RoomAgent could not create agents, but falsely claimed it had created five after writing five personality descriptions. It then role-played all five itself.
Even five real agents would not automatically debate through ordinary room messages. The managed Discussion feature was required, but the product did not explain or guide the user to it.
Recommended fix
Refuse agent-creation requests that the current agent cannot perform.
Never confirm agent creation without real persisted agent IDs.
Guide debate and group-brainstorming requests into Discussion mode.
Case 06
Michael's prompt leak
Confirmed · not fixed
Report claim
Michael's prompt leak: it fired again at 10:31 Taipei on 8/31, so it moves back from “undetermined” to “not fixed”
Verified findings
The scheduled RoomAgent should read check-ins and publish a completed daily summary. Instead, its cron instruction tells it to call the TVBS IT Leads room peer with sendIntent=true.
That peer is configured to send visible messages, not to perform the requested summarization. It publishes the received instruction itself, exposing the private cron prompt in the room. Hermes sees successful delivery and marks the cron completed even though no summary was produced.
Recommended fix
Separate internal instructions from visible room messages.
Make task peers execute requests instead of publishing the instruction itself.
Do not mark prompt echoes as successful scheduled outcomes.
Case 07
Ordinary multi-agent mentions
Confirmed · not fixed
Report claim
Multi-agent mentions: 94.9% of single mentions get a reply, but only 51% of multi-agent messages get every agent to answer and 13% get none (reproduced live on 8/31)
Verified findings
The observed behavior is real, but it is not random agent silence:
A single mentioned agent is dispatched directly.
An explicit @discussion starts the managed multi-agent flow.
An ordinary message mentioning multiple agents dispatches only the first mentioned agent; the rest are not guaranteed to participate.
The interface makes an ordinary multi-agent mention look like a valid request to all named agents, without warning that it follows a different path.
Recommended fix
Route messages with multiple @agents through Discussion mode, or clearly guide the user to it.
Never silently ignore agents explicitly mentioned by the user.
Show a dispatch error when an intended agent was not contacted.
Prioritized response
Additional fixes
Broader product, support, and monitoring improvements that apply across the individual cases.
Improve next
01Scheduling UX
Show timezone, next run, last useful result, failures, and an easy stop button.
02Failure visibility
Show when dispatch never happened, a dependency is unavailable, or data retrieval failed.
Add retries and alerts for repeated empty outputs.
Support and prevention
03Guide users in context
Explain Discussion mode, RoomAgent versus Shadow, agent creation, and supported workflows exactly when relevant.
04Notify affected users
Tell users what was fixed and, where possible, complete the original failed task for them.