Summary

A new mode: "adaptive" session reset that requires BOTH atHour to have passed AND the session to have been idle for idleMinutes before resetting. Currently when both are configured, whichever fires first wins (OR logic).

Problem to solve

Current reset modes are either time-based (daily — hard reset at atHour) or activity-based (idle — reset after N minutes of silence). When both are configured, the docs state: "whichever expires first wins" — OR logic.

This means an active late-night or early-morning conversation gets cut on the next message after atHour, even if the user was chatting minutes ago. There is no way to say "reset daily, but not if we're mid-conversation."

For users who regularly cross the atHour boundary while active (early birds, night owls, cross-timezone users), the only workaround is bumping atHour later — which shifts the problem rather than solving it.

Proposed solution

A new reset mode that combines daily and idle with AND logic:

{
  session: {
    reset: {
      mode: "adaptive",
      atHour: 4,
      idleMinutes: 120
    }
  }
}

Behavior: session resets on the first inbound message where atHour has passed (same as daily) and the session has been idle for at least idleMinutes. An active conversation crossing atHour survives until the user goes quiet for the configured idle window.

This would also work naturally with resetByType:

{
  session: {
    resetByType: {
      direct: { mode: "adaptive", atHour: 4, idleMinutes: 120 },
      group: { mode: "idle", idleMinutes: 10080 }
    }
  }
}

Optional stretch: a "soft reset" variant that injects a system message ("session continued from yesterday") instead of clearing history — giving the agent awareness that the daily boundary passed without losing context.

Alternatives considered

• mode: "daily" with later atHour: Shifts the cutoff but doesn't solve it — any fixed hour will catch someone mid-conversation eventually.
• mode: "idle" only: Loses the daily cadence entirely. Sessions could persist for weeks if there's regular activity, growing unbounded.
• Current daily+idle (OR): Makes resets more aggressive, not less. Adding idleMinutes to a daily config means the session resets sooner, not later.
• mode: "off" (#29544 / #23505): Disables auto-reset entirely, requiring manual /new. Too much burden on the user.
• before_reset guard hook (#21155): Programmatic cancellation could theoretically implement AND logic, but requires hook infrastructure and shifts the logic to consumers instead of the config layer.

Impact

Affected: Users who regularly cross the atHour boundary while actively chatting (early morning / late night users, cross-timezone setups) Severity: Medium — conversation context is lost mid-workflow, requiring re-establishing context in a new session Frequency: Daily for affected users Consequence: Context loss at the worst possible time — when the user is actively engaged

Evidence/examples

Related but distinct from:

• #32109 / PR #32221 — changes default mode per session type (daily to idle for groups), does not combine conditions
• #29544 / #23505 — mode: "off" (no auto-reset), opposite extreme
• #20633 — mode: "on-demand" (agent-driven), manual not automatic
• #42867 — turn-count TTL with heartbeat-aware staleness, different mechanism
• #21155 — before_reset guard hook, programmatic not config-based

No existing issue or PR proposes AND logic for combining daily and idle conditions.

Additional information

The name "adaptive" reflects that the reset adapts to user activity patterns rather than enforcing a rigid boundary. It reuses both existing config fields (atHour, idleMinutes) with no new parameters — the only new concept is the combination logic.