Follow-up research

WorkCord problems · 10 users

63 reported problems, copied from the per-user source and labeled by status and owner · 70% of cases handled.

Filter findings

Status filters cover user problems and common cases. Owner filters cover assigned user problems.

Case 01 · Common

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.
Case 02 · Common

Unreadable attachments

Fixed

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.
Case 03 · Common

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.

  1. The Shadow accepted and scheduled a workflow it could not execute.
  2. No upstream agent results arrived.
  3. The prompt required an “insufficient data” output.
  4. 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.

Case 04 · Common

漢傑'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.

Case 05 · Common

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.

Case 06 · Common

Michael's prompt leak

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.

Case 07 · Common

Ordinary multi-agent mentions

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.

Report review · data through 2 September 2026

Cross-user cases · 7 findings

Broader cases and verified findings follow the individual user problems.

User 01 · wongkl@tvbs.com.tw

Wongkl

8 fixed · 9 total

Attachments / images unreadable

Fixed

Live test: jpg / png / pdf / two-at-once — the embedded code came back verbatim every time

@-mentioning several agents; only one replies

Fixed

Historical live test: 3 mentioned, 1 replied; one of the silent ones showed 0 Hub activity (never dispatched), with no error shown. The multi-agent routing fix is now deployed to production.

Transcription quality

Fixed

Status update 10 September: fixed. Meeting audio now uses the live-stream transcription pipeline with Traditional Chinese handling, silence and gap detection, finalization, and recovery.

Newsroom cron was configured as a multi-agent discussion instead of 12 independent desk-report jobs

Not fixed

The schedule posts one message mentioning all desk agents, which starts sequential discussion routing. Wongkl expected every desk agent to independently collect news and return a report. Six agents consequently never received any task.

Marina: Better setup: configure the six newsroom jobs separately in each desk agent. RoomAgent probably needs a tool to create and manage these jobs for every agent.

Uploads that get no reply at all

Fixed

Of 250 single-file uploads since 8/12, 51 (20%) got no reply within 15 min

Agent didn't respond in time

Fixed

Status update 10 September: fixed.

All timeout variants are resolved, including stale placeholders, replies correlated to the wrong task, and a later request becoming attached to an earlier in-flight task.

Recording cuts out, or captures nothing

Fixed

4 of her 9 recordings captured only 2.8–20.6 seconds (successful ones run 46–63 min); the 7/17 file is digital silence, RMS 0. Microphone behaviour cannot be reproduced through the API

Agent cannot see content already in the room

Fixed

Status update 10 September: fixed. Stable room and thread conversation contexts now carry existing room history, including text, long text, file references, the agent’s earlier replies, and reply/thread context.

"Gateway shutting down"

Fixed

Last seen 8/05 13:15; none since

User 02 · tsubasa@tvbs.com.tw

Tsubasa

6 fixed · 7 total

No place to store an external API key (VoAI) on a hosted tenant; inconsistent agent policy — one-off test succeeded once, then every route refused

On validationMarina

Status update 7 September: On validation.

17 key-related user messages Aug 8–11 (2 are environment-survey context, 15 direct attempts); success once at Aug 8 15:49 (test voiceover produced), all later routes refused; agent still reported VOAI_API_KEY unset at Aug 11 03:45; no user-facing secrets UI exists today [LIVE-TEST 8/29] Test-room reproduction: the agent stated there is no secret vault for long-term third-party API keys and warned against pasting them in chat or the workspace — still absent today. [LIVE-TEST 8/31] Asked the agent directly whether the platform has anywhere safe to keep an external API key. Verbatim: 'No — this Hosted Hermes Hub does not provide a secret vault for long-term storage of an external TTS API key; do not paste it into chat and do not put it in the workspace.' The dead end he walked into is unchanged

Audio uploads (mp3): agent cannot obtain a download URI, files unreadable

Fixed

All 8 mp3s (two batches, Aug 11) got "cannot obtain download URI"; HEAD on wc-test.mp3 against GCS returns 200 (audio/mpeg, 25,344 bytes, file intact) on Aug 29; the upload fix has positive tests only on jpg/png/pdf [LIVE-TEST 8/29], the mp3 variant untested; [LIVE-TEST 8/31] Uploaded a 2-second mp3 in the test room; the agent correctly reported 'length 2.088 s, sample rate 16 kHz' — mp3 reading is fixed
It was not an MP3 codec problem; it was a Hermes Hub attachment-source access problem.

Meeting recording capture failure: 46-minute meeting captured 44 bytes, blank transcript, no report, no error shown

Fixed

Status update 10 September: fixed. The live-stream meeting pipeline now handles capture, transcription, finalization, recovery, and explicit no-audio failures. An empty capture no longer silently becomes a blank transcript with no report or error.

Multi-@ in one message gets one reply (and that one agent role-plays all three)

Fixed

Historical evidence: on Aug 11, Aug 29, and Aug 31, multi-agent messages produced only one reply. The multi-agent routing fix is now deployed to production.

Discussion feature ignores the user's round script: overruns, robotic repeated "rejected", agents @-ing themselves, premature conclusions

Fixed

Status update 10 September: fixed. Numbered multilingual round scripts now define the authoritative speaker order and turn budget. Failed rounds are bounded and retried once, unanswered turns time out cleanly, and the declared final deliverable is checked before the discussion concludes.

Upstream model failures/timeouts surfaced as raw error strings: "model provider failed" x8, "Agent didn't respond in time" x3

Fixed

Status update 10 September: fixed.

The historical failures occurred Aug 4–28. All timeout variants and raw provider-error presentation paths are now resolved.

Cron times displayed in UTC, 8 hours off Taiwan time, causing confusion

Fixed

Status update 7 September: Fixed.

Aug 10 07:45Z, the user: "the job says 07:42 but it's past 3 PM Taiwan time here — these don't match"; the agent confirmed UTC scheduling; display behavior not re-tested today

User 03 · chang122@tvbs.com.tw

品茲

4 fixed · 7 total

8/17 platform outage: his last three messages each timed out after 30 minutes; plus 3 cron failures and a provider error

Fixed

Status update 10 September: fixed. The Aug 17 outage was historical, and all timeout, provider-error, and recovery variants are now resolved.

Wrong-timezone cron: he specified 9 a.m. Taiwan; the "Daily Global Tech Research" job ran at 09:00 UTC (5 p.m. Taiwan) for 12 days

Fixed

Status update 7 September: Fixed.

On hub tenant wcr_e807850d..., cron_c2b360227b0e ran at 09:00 UTC on all 12 days 8/17–8/28; the 8/28 report itself states "actual run time was 09:00 UTC, not the user-configured 9 a.m. Taiwan"; [RE-CHECKED 8/31] the cron still fired at 17:00 Taipei (09:00 UTC) on 8/28, 8/29 and 8/30 — eight hours off the 09:00 Taiwan time he asked for

One request spawned two daily jobs: Tech Focus | Pin_01 (01:00 UTC) plus Tech Research (09:00 UTC), duplicating digests across two rooms

Not a bug

redundant job stoped

The user submitted the same task to two different agents, so each agent independently created a daily job.
This is expected behavior, like asking two people to do the same work.

Pin_01 was also ambiguous because multiple peers shared the searchable name Pin_01 RoomAgent; the system
deterministically selected one of them. This is naming/configuration ambiguity, not a technical or prompt
failure.

  • Pin_01
  • Pin_01_科技財經

However, this message was sent as a reply quoting the original scheduling request, which contained Pin_01.
Assistant RoomAgent received both:

  • New text: @Assistant RoomAgent 協助回答我問題
  • Quoted/replied-to context: the original request containing Pin_01

8/28 digest silently lost: cron and peer both reported success and the Assistant-room notice claimed delivery, but no message reached Pin_01

Not fixed

Hub activity shows the 8/28 01:05:37 outbound peer request "succeeded" (pmsg_9e54212c...); Pin_01 (5393a1f8) has 0 messages on 8/28; the Assistant-room notice at 8/28 01:05 claims "sent to WorkCord room Pin_01". On 8/29 01:04 UTC the digest landed normally again (peer pmsg_05abdf2f... succeeded) — a one-day loss with no identified mechanism; one instance cannot tell whether it will recur

Long replies truncated by the output-length cap: two consecutive "Response truncated due to output length limit" on 7/17; he had to prod twice to get an answer

Fixed

Two truncation messages in the Newsroom (522b5872) at 15:34:38 and 15:38:57 on 7/17; only after he switched to "Concise answer" did a full reply land at 15:40. No same-path retest (long research replies) exists today and the platform live tests don't cover this mechanism

The 五腦 agent addressed 品茲 as "偉芳" (and had called 偉芳 "Michael" the day before) — speaker-identity misattribution

Not fixed

At 14:38:01 on 7/17 五腦 opened with "偉芳, facing today's US-market plunge...", forcing 品茲 to reply "I am 品茲"; this is custom-agent behavior with no fix or retest evidence either way

Digest quality gutted by search-service timeouts: the first report contained zero news items; many days carried only single-source or 2–3 items

Fixed

Status update 10 September: fixed. Search-service timeout handling and hosted search availability are now fixed; the zero-item and weak historical digests occurred before these changes.

User 04 · ninehole@tvbs.com.tw

Jimmy Liu劉勇志

6 fixed · 7 total

File links in plain-text replies rendered as an empty "Download:" (game deliverable unreachable)

Fixed

The platform defect is fixed, but the two historical messages remain broken.

Two agent messages on Jul 31 at 15:38 and 15:41 read verbatim "檔案在這裡：Download: " with no URL after the colon (raw text, re-read Aug 29). Later replies switched to a2ui file cards and it never recurred — but there is no positive test of the plain-text-link path as of Aug 29

Agent internal work-log leaked into the room ("Need write README.", "iteration 10/90", etc.)

Fixed

The original persistent leak is fixed, but complete suppression of internal-looking progress text is not.

Six consecutive agent messages Jul 31 15:49–15:53 are raw English reasoning fragments plus "🛠 Working — 3 min — iteration 10/90, browser_vision" (raw text, all 6 re-read Aug 29). Never recurred in his rooms, but no reproduction test exists today

Just-uploaded attachment declared "not seen" on the next turn (agent acknowledged the client_secret, then replied "I haven't seen the content of 'this'"; he had to ask twice before it re-confirmed)

Fixed

Status update 7 September: Fixed.

  • Files uploaded to agents were unreadable.
  • Agents lost attachment context on the next turn.

Aug 5 09:01:23 upload → 09:01:24 agent "received this Google OAuth client secret JSON" → 09:01:28 he asks "is this OK?" → 09:01:30 agent "I haven't seen the content of 'this'" → he asks twice → only at 09:02:32 does it confirm "yes, HTTP 200" (verbatim).

"Agent didn't respond in time" timeout errors

Fixed

Status update 10 September: fixed.

Four historical failures occurred in his rooms on Aug 5–6, with later platform recurrences through Aug 28. All timeout variants are now resolved.

Automated Google Drive write-back (JSON next to each track) impossible; the OAuth flow was blocked by Google

WIPMarina

On Aug 5 the agent itself reported "Google Drive not yet authorized"; at 09:09 he posted a screenshot captioned "looks like it got blocked" (attachment on record); at 09:13 he gave up. The platform still ships only a codexAuth slot, no Google credential ever installed), and nothing has changed since

The search UI shipped a "paste cloud folder path" field that could never work in a browser, costing him an evening of manually placed JSONs

Fixed

Aug 5 14:59 he reported "I put the JSONs next to the audio files in Google Drive but the UI can't read them"; Aug 6 14:12 the field was removed at his request in favor of local-folder detection; Aug 6 14:22 he personally confirmed "the local folder JSON detection works now" (verbatim) — a positive confirmation on the same path

Deliverable download links carry a 7-day signature and nobody re-issues them after expiry

Fixed

Status update 7 September: Fixed.

The final Aug 14 zip file-card token decodes to exp=2026-08-21T13:45:54Z; a HEAD probe on Aug 29 returns HTTP 401 (re-probed during this review, still 401). The Jul 31 index.html link had the same 7-day TTL (exp=Aug 7). His room lastReadAt is Aug 25 10:13Z — four days after expiry; [LIVE-TEST 8/31] Asked the agent to produce a file and hand back a link: the delivery mechanism has changed to a Hub-signed URL (web201/v1/files/d/...), but decoding the token shows an exp of exactly 7 days and there is still no re-issue path — the TTL is unchanged

User 05 · peishihchang@tvbs.com.tw

佩詩

5 fixed · 7 total

a2a context conflict error swallowed three consecutive messages (killed her Aug 4 extension-directory request)

Fixed

All three messages 07:52–07:54 on Aug 4 returned "a2a context already belongs to peer"; the string appears 37 times platform-wide Aug 4–9 and zero times since Aug 9 (re-queried Aug 29); on Aug 12 she herself got a full reply in the same room from the same agent (positive same-path test)

'Agent didn't respond in time' false alarm — the real reply landed 7 seconds later

Fixed

Status update 10 September: fixed. The Aug 4 false alarm and every related timeout and reply-correlation variant are now resolved.

Her Aug 17 'I agree' waited the full 30 minutes and got no reply at all

Fixed

Status update 10 September: fixed.

The Aug 17 request historically waited exactly 30 minutes without a response. Dispatch, task correlation, and timeout recovery have since been fixed.

One message @-mentioning two agents got only one reply

Fixed

Historical evidence: her Aug 4 message received only one agent reply, and the failure was reproduced on Aug 29 and Aug 31. The multi-agent routing fix is now deployed to production.

Agent claimed a test message was sent; nothing arrived in the room

Fixed

Status update 7 September: Fixed.

At 08:40 on Aug 4 the agent claimed the send was arranged; at 08:42 she replied 'I didn't receive it'; the actual post landed at 08:44. The send-now path was not re-tested today; settling this requires re-running an immediate-send request and checking room delivery

Music generation quality: cinematic written design vs sine-wave test tones

Not fixed

Tool_calls in session 20260813_092617 show the agent hand-wrote make_audio.py (wave + math.sin + random.seed) to synthesize the track, with no music-generation tool invoked anywhere; the flavor is still wm_sound_music@1.0.0 (tenants.json cached 8/29) with no sign of added capability

She asked for a finished video file; both deliveries were music.wav — the produced mp4 was never handed over

Not fixed

The room log shows music.wav delivered at 09:26 and 09:55 on Aug 13 and nothing else; ffmpeg commands in the same session show 便利打_完成版.mp4 was mixed and produced; agent messages carrying an mp4 file or link in the room = 0 (re-queried Aug 29)

User 06 · hikaru0824@tvbs.com.tw

SNOW

6 fixed · 8 total

Scheduled reports fail room delivery (scheduled runtime can't resolve the room peer)

Fixed

Active week: 8 of 21 slots delivered (38%; room messages vs hub cron sessions, re-run Aug 29); cron's own notes say "404 no peer matched" / "Hub peer search empty"; since Aug 21 20:00Z, 15 of 23 slots landed (65%); cron self-reports Aug 22–28 hand-read: 8 ROOM DELIVERY: FAILED (8/25×3, 8/26×2, 8/27×1, 8/28×2), 9 SUCCESS

[VERIFIED 9/2] All three scheduled reports—06:30, 11:30, and 16:30 Taipei—reached the intended WorkCord room in full.

Cron runs themselves killed by platform errors

Fixed

4 hard failures, 4 literal error strings (hand-read Aug 29): Aug 11 "servers currently overloaded", Aug 13 "HTTP 400: Provider returned error", Aug 17 "Codex stream produced no SSE events for 12s", Aug 24 "Connection error" — latest just 5 days ago

[VERIFIED 9/2] All six scheduled executions across Sep 1–2 completed successfully; the latest three runs ended normally without execution or delivery errors.

Internal routing instructions leak verbatim as the visible room message

Fixed

Status update 10 September: fixed. Scheduled delivery now uses typed routing and validated room delivery instead of publishing internal visible_send or visible_send_delegate instructions as room content.

The solar-term T–10 automation never executed

Not fixed

Of 60 hub sessions on the Shadow tenant, the 59 cron sessions are all the 3 daily-weather jobs — no solar-term job (re-pulled Aug 29); the first Chushu output appears in the Aug 14 02:39 session titled "back-filling the Chushu report", after the user demanded it

Report files not downloadable (private workspace paths + 7-day-expiry signed links)

Fixed for new files

User verbatim Aug 14: "you say the report is here but I can't download it"; the replacement link (exp 2026-08-21T02:58:57Z) returns HTTP 401 on an 8/29 HEAD probe (re-probed in this review, still 401); Aug 28 cron notices still deliver as "PRIVATE WORKSPACE: DAILY_WEATHER_....txt"; [LIVE-TEST 8/31] Same path: files are now delivered via a Hub-signed URL, but the token's exp is still 7 days and nothing re-issues it after expiry

"Agent didn't respond in time" ate their final instruction; the failure was never surfaced

Fixed

Status update 10 September: fixed. The Aug 16 request historically failed after 30 minutes. Dispatch, timeout recovery, and user-facing failure reporting now cover this path.

Facebook page sources unreadable (login wall) — the core sources of their whole product

WIPDmitry

Aug 9: all six designated sources (incl. Cheng Ming-tien himself) came back SEARCH_RESULT_ONLY; one direct share-link read succeeded once, without a date. Not re-tested today; re-running the same 6-source fetch would settle it

Room-context vs DM-context workspace inconsistency (~ path fails, absolute path works)

Resolved by workaround

Aug 9 14:27 the in-room agent "cannot read WEATHER_TOPIC_BANK.txt"; 14:37 the ~ path FAILED; 14:42 the absolute path SUCCEEDED. The issue is resolved operationally by using the full absolute path; the short ~ path itself has not been positively retested.

User 07 · bardsiao@via.com.tw

BardSiao

2 fixed · 5 total

False "Agent didn't respond in time." notice beside every delivered reply

Fixed

Status update 10 September: fixed. Twenty-five historical false notices appeared in his Assistant DM on Aug 4–7. False placeholders, genuine timeout recovery, and reply correlation are now fixed.

Team-room attachments arrived metadata-only; agent could not read the body (both uploads verdicted "FAIL")

Fixed

Both his Aug 10 TightVNC.md uploads (16:32, 16:40 Taipei) got "Result: FAIL — body not obtained"; his Aug 12 re-upload of the same file on the same path was read successfully; the same day at 06:47Z the RoomAgent's hub session shows an attachment source record carrying a storage.googleapis.com downloadable uri and a successful curl download (mechanism layer); the Aug 29 live test passed jpg/png/pdf/two-files, mechanism being source records now carrying a downloadable uri plus fixed tenant read permission [LIVE-TEST 8/29].; [LIVE-TEST 8/31] Uploaded a .md containing a random code in the test room; the agent returned CHURN-6311-SLATE verbatim. The fix actually landed on 8/12 (the hub now writes attachment records group-readable, plus a repair pass for older records) — not 8/29, which was merely the first date I tested it

Cross-addressed reply: his upload request was answered about another user's file

Not fixed

At 16:32 on Aug 10 he uploaded TightVNC and asked for a verdict; the agent's reply discussed melanie's "Skype For Business... file 1 of 5" instead (verbatim in the message record). The RoomAgent tenant has 26 surviving hub sessions (earliest Jul 31), but the entire 08:26–08:56Z stretch of Aug 10 (including both his uploads) is absent from every one of them — the main session's user turns jump from 08:12 straight to 09:04 — so no tool_calls can be read; a live reproduction with two users posting attachments concurrently would settle it.

Silence after upload: a file posted without @-mentioning the agent gets zero response or hint

Not a bug

Working as designed; possible UX discoverability issue only.

At 14:36:31 on Aug 12 his un-mentioned TightVNC.md upload got nothing; 16 seconds later he re-sent with an @ and it worked. His instance may be mention-only gating working as designed — but the UI gave him no hint either way, and the platform-level silent-no-reply problem is not fixed: 51/250 (20%) of single-file uploads since Aug 12 got no reply within 15 minutes [LIVE-TEST 8/29].

Knowledge-base ingestion can never be verified: "list the database" returns a duplicate-laden workspace inventory plus a disclaimer

Not fixed

On Aug 12 his three list requests each returned "296 Markdown files in the workspace (including copies)... formal RAG/Knowledge indexing cannot be confirmed"; on Aug 20 the agent's self-described rules in the room still carry the same hedge (2 messages). No positive evidence exists that this capability gap has been closed.

User 08 · wanrusu@tvbs.com.tw

SWR

4 fixed · 5 total

False "Agent didn't respond in time." before every real Assistant reply

Fixed

Status update 10 September: fixed. All seven historical turns showed the false notice before a real reply. All timeout and reply-correlation variants are now fixed.

.txt attachment to a custom agent — content unreadable by the agent

Fixed

Both her 口白.txt uploads failed: hub session 20260805_075049 (10 tool calls, source json File not found, zero hits searching 口白.txt) and 20260805_075248 (19 tool calls, read_file "File not found" + "Permission denied" on the sources dir). The mechanism (uri on source record + tenant read permission) verified fixed [LIVE-TEST 8/29]; that test set jpg/png/pdf/multi — .txt itself untested, but her failure sat exactly on the now-fixed permission/uri path; [LIVE-TEST 8/31] Uploaded a .md containing a random code in the test room; the agent returned CHURN-6311-SLATE verbatim. The fix actually landed on 8/12 (the hub now writes attachment records group-readable, plus a repair pass for older records) — not 8/29, which was merely the first date I tested it

Cross-turn amnesia: each custom-agent message spawns a fresh session; prior content vanishes

Fixed

Fully fixed.

Her 17 messages in that room = 17 separate hub sessions (plus one agent-setup session at 07:47:48Z, 18 total); session 20260805_080430 contains only the words "correct it" with zero history, forcing 5 pastes of the same 11,604–11,614-char transcript (07:56/08:04/08:04/08:05/08:06 UTC). No 8/29 live test covers this path — settling it requires two consecutive messages (long text, then bare command) to a custom agent today

Correction quality: ignored format rules (merged lines, punctuation, 8300億元→8300億美元) and produced a wrong correction twice (錯詞 changed to 措詞 instead of 措辭)

Not fixed

Her transcript contains 「不管他的錯詞啊」; the 07:56Z first correction fixed it to 措辭 (correct) but rewrote the format and rendered 8300億元 as 8300 億美元 (a form absent from her original); the 08:06Z fifth output changed it to 措詞; her 08:11 "錯詞→措詞 is wrong" and 08:12 "still wrong, it's 措辭" (verbatim); the agent's systemPrompt untouched since 8/05 07:48 (custom_agents.updatedAt) — nothing on this path has changed

Undelivered deliverable: the built sfx-music-finder.html never reached her room; only a README link, now dead

Fixed

Hub session 20260805_072019: write_file 11,217 bytes + Openverse API probe returned 200; the room only ever received the README link (twice), signed token exp 1786519362 = 2026-08-12T07:22:42Z — HEAD today returns 401

User 09 · stanleylo@tvbs.com.tw

Stanley

3 fixed · 4 total

Spurious 'Agent didn't respond in time.' error fired before the real reply on every turn

Fixed

Status update 10 September: fixed. All seventeen historical turns showed the spurious error before a real reply. Task correlation, redirected corrections, mention dispatch, and timeout placeholders are now fixed.

Custom-agent creation channel dead: ShadowHome/private_action peer not found (404)

Fixed

Hub sessions 20260804_021853 and 20260804_024833 both contain the literal 404 "no peer matched the requested query and capabilities" (024833 also has search_peers returning {peers:[]}); his ShadowHome record only appeared at 02:55:28. Later research classifies the agent-creation path as fixed.

RoomAgent falsely reported creating five directors, setting free-meeting mode, and dispatching their conversation

Not fixed

All tool_calls read: the 'created' session (20260804_032659) contains only skill_view (Permission denied) + an ask_peer text post + a failed memory replace; 'free-meeting mode' (20260804_034402) is a single memory write; 'conversation dispatched' (20260804_045210) is another ask_peer text post. custom_agents and room_agents platform-wide contain no agent named after any of the five directors. Whether a RoomAgent would fabricate the same today requires re-running the same prompt and reading its tool_calls; [VERIFIED 8/31] Only 2 agents ever spoke in his rooms (Assistant and 他們來了 RoomAgent). The 'five directors' were one agent role-playing all five inside its own text, never five separate agents

@-mentioning a nonexistent agent → silence: no dispatch, no reply, no error

Fixed

Status update 10 September: fixed. Unresolved mentions now return an explicit error, while valid mentioned agents are dispatched and respond through the corrected routing path.

User 10 · wayne@tvbs.com.tw

WEI

3 fixed · 4 total

In multi-member rooms, silent mode delivers un-mentioned messages to the agent but it never replies, with zero feedback

Fixed · working as designed

Status update 10 September: fixed. Silent mode remains intentional for unmentioned messages, while valid mentions and multi-agent requests now use the corrected dispatch path without silent routing failures.

The music-tag UI showed a 'track array not found' error (his very first message was this bug report)

Not fixed

Reported 2026-08-10 17:53; the hub ran a 19 s run on it but the room got zero acknowledgement and zero follow-up; all later tagging bypassed the UI via chat. Settling it requires loading his JSON batch into the UI and reproducing

'The model provider failed after retries' raw error, twice in a row, self-service retry required

Fixed

Status update 10 September: fixed. The historical provider failures ended after Aug 18, and the related timeout and raw technical-error paths are now resolved.

Tagging deliverables (JSON zips) handed over as FileCards; whether they can still be retrieved from the chat is unknown

Fixed

Status update 7 September: Fixed.

All 4 a2ui FileCards store a workspace-relative url (no external signed URL to probe); a hub listing today (8/29) shows all 4 zips and 49 JSONs still present. Settling it requires clicking the FileCard in his WorkCord client and seeing whether the download succeeds