Skip to content

Session & Delivery

源码版本v2026.7.20

Responsibility

Two things: (1) Session — attribute "where the message came from" (platform, chat, sender) to a stable key, and persist the conversation to disk so the agent can continue with context across restarts; (2) Delivery Ledger — record a "delivery obligation" for the agent's final reply, so that after a crash undelivered replies can be identified and re-sent, guaranteeing the user ultimately receives them. Both live in the gateway layer, decoupled from the agent.

Key Files

Data Flow

  1. The adapter receives a platform event and carries SessionSource out via MessageEvent:1759.
  2. SessionSource:149 hashes out a stable chat/sender id (gateway/session.py:40).
  3. A SessionContext:299 is constructed, yielding a session key (used as a disk path after the path safety check:109).
  4. The session key decides which file to load history from, fed to the agent to continue context.
  5. After the agent produces its final reply, the gateway records it in record_obligation:155 → sends → mark_delivered.
  6. If a crash happens during send, the next startup's sweep_recoverable (gateway/delivery_ledger.py:203) scans for obligations in attempting state whose owning process is dead, and re-sends or marks them failed.

Summary

The session layer owns "which ongoing conversation this message belongs to", mapping external identities safely to disk files via hashing + path validation. The delivery ledger owns "whether the agent's intended final reply actually reached the user", using a sqlite state machine for crash recovery. Both are best-effort but critical reliability layers.

Unofficial community learning site. Content based on the MIT-licensed NousResearch/hermes-agent source.