Summary

Add a logical-history mode to chat.history so long-lived chats can retain continuity across daily, idle, or manual session rollovers.

Problem to solve

A stable session key such as agent:main:main can roll over to a new sessionId after daily, idle, or manual reset. That behavior is expected, but chat.history currently reads only the current transcript behind the current sessionId.

For WebChat / Control UI users, this makes one long-lived direct conversation look like it only contains the newest segment, even though older rolled transcript files still exist. From the user's point of view this is one ongoing chat, but from the current API point of view only the latest segment is visible.

Proposed solution

Keep reset behavior unchanged, but extend chat.history with an optional logical-history mode.

Suggested direction:

• chat.history(scope: "current") keeps existing behavior
• chat.history(scope: "logical") returns the current segment plus previous rolled segments for the same logical session key

Logical mode should also return lightweight segment metadata, for example:

• sessionId
• startedAt
• endedAt
• reason

This would let WebChat / Control UI render continuity across rollovers without scanning transcript files directly, and it would work for both local and remote gateway setups.

Alternatives considered

UI-only recovery is weaker because clients cannot reliably scan transcript files directly, especially in remote gateway setups. Increasing the current chat.history limit also does not solve the root problem, because older rolled segments are in previous transcripts, not just outside the current limit window.

Impact

Affected users/systems/channels:

• WebChat / Control UI users
• Any long-lived direct chat using a stable session key
• Local and remote gateway deployments

Severity:

• Medium

Frequency:

• Recurring; especially visible with daily reset defaults or any workflow that relies on long-running direct conversations

Consequence:

• Users think chat history was lost or cleared
• Long-lived conversations appear fragmented in the UI
• Operators must inspect transcript files manually to reconstruct continuity

Evidence/examples

A long-lived direct chat can keep the same logical session key while rotating to a new sessionId. After rollover, chat.history only returns the newest segment, while older rolled transcript files still exist on disk. This creates an API/UI continuity gap rather than actual transcript deletion.

Additional information

No response