Memory tree LLM recap fails silently — falls back to heuristic summarization

[Al629176]

Summary

The memory tree archivist's LLM-based segment recap fails and silently degrades to a heuristic fallback, producing lower-quality memory summaries without surfacing the failure to the user.

Log Evidence

11:19:32:WRN:recap [archivist] summarize_entries: LLM recap failed (non-fatal) segment=seg-18d3df10e56e3e285a4c5f99: ai.tinyhumans.tinymemory.Error.Other: summarise tree inputs: memory_tree::summarise: provider=inference:chat-v1 — heuristic fallback

Impact

• Memory segments are summarized with heuristics instead of LLM — coarser, less contextually rich recall
• Failure is non-fatal and swallowed, so the user gets degraded memory quality with no indication anything went wrong
• Future recall that depends on these segments will be less accurate

Expected Behavior

Either:

1. The LLM recap should succeed reliably, or
2. On failure, the error should be retried with backoff before falling back, and/or the fallback should be logged at a higher severity so it can be tracked

Root Cause Direction

The error is memory_tree::summarise: provider=inference:chat-v1 — likely an inference call to the summarization provider failed (timeout, quota, or transient). The failure-to-fallback path needs a retry before giving up.

[YellowSnnowmann]

Confirmed as a real failure, but it is a duplicate of #6156 — and the PR that closes #6156 (#6183) does not address what this issue actually asks for. It fixes the damage, not the failure. It also carries Closes #6156 only, so merging it will not close this.

Researched against main @ 537854715 with the current vendor/tinymemory pin.

---

The log line is genuine

It is emitted verbatim at src/openhuman/agent/harness/archivist/recap.rs:288:

tracing::warn!(
    "[archivist] summarize_entries: LLM recap failed (non-fatal) \
     segment={segment_id}: {e} — heuristic fallback"
);

It is the same defect as #6156

	#6156	this issue
reporter	@Al629176	@Al629176
resolved model	inference:summarization-v1	inference:chat-v1
error shape	bare memory_tree::summarise: provider=…	ai.tinyhumans.tinymemory.Error.Other: summarise tree inputs: memory_tree::summarise: provider=…
cause in the log	yes — adjacent [providers][openhuman-backend] … error sending request	no

The extra Error.Other: summarise tree inputs: wrapper is the tinybus/engine boundary, so this report is from a build after the module-driver migration. Same code path, same emitter.

---

What this issue asks for vs. what #6183 does

1. "The LLM recap should succeed reliably." #6183 changes no inference code. Not addressed.

2. "The error should be retried with backoff before falling back." #6183 lists this under Deliberately out of scope. And there is no retry anywhere on this path today:

• InferenceChatProvider::run_with_usage issues a single self.inner.invoke(&(), request).await? (tinymemory-core/src/chat.rs:113) — no retry wrapper.
• create_chat_model_with_model_id_inner (src/openhuman/inference/provider/factory_part_02.rs:1) returns a bare concrete ChatModel: no fallback chain, no resilience middleware at this construction site.
• OpenHumanBackendModel::invoke (openhuman_backend_model.rs:484) has no retry loop. The retryable=true in LLM recap fails silently and falls back to heuristic summarisation when provider is unreachable #6156's log is a classification that nothing acts on here.
• The tinyagents RetryPolicy / RetryMiddleware only wrap graph and subagent nodes. A memory recap is a direct model invoke and never reaches them.

3. "The fallback should be logged at a higher severity so it can be tracked." It already is — the WRN quoted in this issue is that log, and it predates #6183. #6183 adds a second WARN at the new skip site, gated on summariser_available.

What #6183 does fix, from the Impact section here: the heuristic bookend is no longer persisted, embedded, or handed to goals enrichment. The segment is left status='closed' with a NULL summary, which is the latent re-summarisation marker. So the degradation stops being corrupting — but nothing recovers the quality yet. #6186 tracks the missing re-summarisation pass and the fact that a host cannot see the marker over the contract.

---

Two things this issue surfaces that are not covered by #6156, #6183 or #6186

A. The root cause is destroyed before it reaches the log, so this report cannot be diagnosed as filed.

summarise() attaches its context with anyhow, preserving the cause chain:

// tinymemory-core/src/tree/summarise.rs:53
.with_context(|| format!("memory_tree::summarise: provider={}", provider.name()))?;

The engine boundary then flattens it:

// tinymemory-tinycortex/src/engine/mod.rs:364
fn other(context: &'static str, error: impl std::fmt::Display) -> MemoryError {
    MemoryError::Other(anyhow::anyhow!("{context}: {error}"))
}

{error} on an anyhow::Error renders only the outermost context. Everything beneath it — timeout, 401, 429, quota, connection reset — is dropped, and the flattened string is what crosses the wire as ai.tinyhumans.tinymemory.Error.Other. By the time recap.rs:288 prints {e}, the reason is gone.

#6156 was diagnosable only because a separate [providers][openhuman-backend] line happened to sit next to it in the log. This report has no such line, which is exactly the failure mode.

Suggested fix: use {error:#} (or {error:?}) in Self::other. One line, no contract change, no release/re-pin chain.

B. provider=inference:chat-v1 is anomalous, and it makes the stated root-cause direction unverified.

resolve_managed_backend hard-pins the summarization and memory roles to summarization-v1 (factory_part_02.rs:450), with a comment stating that the pin exists precisely so those roles do not "silently collapse to chat-v1". There is no managed path that produces inference:chat-v1 for this call.

So the summariser here did not resolve to the managed backend — it took a BYOK / local / cloud route whose model string is literally chat-v1. If that is a managed tier alias aimed at a non-managed endpoint, it would fail on every call rather than transiently, which is a different bug from the one #6156 describes.

@Al629176 — could you add: the app version, the routing configuration for the memory/summarization role, and the [providers] log line immediately preceding this WARN? That determines whether this is the #6156 connectivity case or a routing misconfiguration.

---

Suggested disposition

Either close as a duplicate of #6156, or re-scope this issue to the two halves #6183 deliberately left open — retry/backoff on the summarise call, and the error-chain truncation in (A) — and link #6186 for the recovery pass.

[YellowSnnowmann]

Closing as a duplicate of #6156 — same reporter, same code path, same emitter (archivist/recap.rs:288). Recording what shipped and what is genuinely still open, because the two halves of this report had different outcomes.

The diagnosability half — fixed and released

This report's real distinguishing feature was that it carried no cause at all, where #6156 had one. That was not the reporter's doing.

TinycortexProvider::other formatted {error}, and on an anyhow::Error that renders only the outermost context. A summariser failure therefore reached the host as summarise tree inputs: memory_tree::summarise: provider=… with the transport error underneath it discarded, and the bus carries a code and a message rather than a chain — so that string was everything anyone would ever see.

Fixed in tinyhumansai/tinymemory#153 ({error:#}), released in v1.16.0, and reaching the product through the re-pin in #6183. Future reports of this failure carry the real reason.

Root cause, established from field logs

Not reproduced from this report — the cause was gone — but confirmed on a developer machine showing the identical status=None … error sending request signature. A sibling call to the same host, ten minutes earlier in the same log, kept its full chain:

error sending request for url (https://api.tinyhumans.ai/agent-integrations/composio/toolkits)
  → client error (Connect) → dns error
  → failed to lookup address information: nodename nor servname provided, or not known

macOS EAI_NONAME: DNS resolution failed outright. No connection was opened, no request sent, nothing reached the backend. The service and the model were both fine.

The distribution says the rest:

Day	DNS failures
2026-09-02	25
09-03 → 09-08	0

All on one day, clustered at 05:41 · 06:11 · 06:43 · 07:46 · 08:03 · 08:13 · 09:31, then 20:34–21:02 — and the failing runs were user_id="cron", morning_briefing. That is scheduled work firing while the machine had no name resolution: a laptop waking with wifi not yet associated. The 08:13 burst is 14 identical failures in 6 seconds because several cron agents woke together and each cold-connected into the same dead resolver.

[observability] agent.run_single skipped expected network-unreachable error shows the codebase already classifies this class and suppresses Sentry for it.

What made a few seconds permanent

Three things, all addressed in #6183 and tinymemory v1.16.0:

1. One attempt only. tree::summarise was single-shot. Now 3 attempts with 250ms·2ⁿ backoff under a 20s ceiling — a DNS gap this short is absorbed. Timeouts are deliberately excluded from the retryable set: reqwest cannot separate a connect timeout from a read timeout on a response that was generated and billed.
2. The fallback was persisted. The heuristic bookend was written as the segment's durable summary, embedded, and fed to goals enrichment — and set_segment_summary also flips the row to 'summarised', which is what removed it from the recovery queue. Nothing is written now.
3. Nothing came back for it. ConversationSegment grows a status field and a new SegmentsPendingSummary member, and the archivist re-runs its own summariser over the queue after a recap that succeeded.

What is still open, and why this is a duplicate rather than fixed

The one thing here that is not explained is the model id: this report logs provider=inference:chat-v1, where the managed path hard-pins the summarization/memory roles to summarization-v1 (factory_part_02.rs:450, with a comment saying the pin exists precisely so they do not "silently collapse to chat-v1").

Ruled out:

• an older build — the pin landed 2026-06-25 in fix(routing): resolve all summarization inference through the summarization role #4083, months before this report;
• the obvious config — a machine with memory_provider = "cloud" and an OpenHuman primary_cloud entry resolves to the managed tier and logs summarization-v1, matching LLM recap fails silently and falls back to heuristic summarisation when provider is unreachable #6156.

So chat-v1 means that workspace's summarization role resolved off the managed backend, and a managed tier alias pointed at a non-managed endpoint would fail on every call rather than transiently — a different bug from the one described here.

@Al629176 — if you still see this, please open a fresh issue with your app version and the routing configuration for the memory/summarization role. That is the one question this report leaves behind, and it needs your config to answer; everything else it described has shipped.

Fix tracked to completion in #6183 (closes #6156, #6186, #6187).