AI Disclosure
AI Tool(s) Used
Claude (Anthropic), for drafting the issue text. The measurements, suite and tests were run and verified by me.
Human Verification
I have personally reviewed this request, verified that it addresses a real use case, and take responsibility for its contents.
Problem statement
In letta 0.16.8 the core memory checkpoint history (block_history, plus block.current_history_entry_id) accepts direct edits in Postgres silently. I measured this with a small open source conformance suite, agmi, that seeds a block through BlockManager.create_or_update_block_async, update_block_async and checkpoint_block_async, edits the rows directly, then walks undo_checkpoint_block back to the first checkpoint and redo_checkpoint_block forward again.
What happens after each edit to the store:
- Change the value of a middle checkpoint: undo lands on the changed value, no error.
- Delete the newest two checkpoints and repoint the block: the agent's core memory rewinds two checkpoints, every call succeeds.
- Delete one checkpoint from the middle: undo and redo skip the hole, no error.
- Swap the value of two checkpoints: loads and walks fine, no error.
- Insert a new checkpoint after the tip and repoint the block: the agent's core memory is now the inserted text, no error.
The undo and redo code says explicitly that it tolerates pruned sequence numbers, so the gap tolerance is deliberate and I am not calling it a bug. The reason it deserves a look is that the feature is presented as a checkpoint history with undo and redo, and users will read that as a record of what the agent's memory was. Today it is a record only as long as nobody with database access edits it. For agents whose memory matters to a regulator or an audit, that is a meaningful difference.
Proposed solution
An optional integrity check on block_history: a per row hash over (block_id, sequence_number, value, previous row hash), verified on undo, redo and checkpoint. Off by default. Every edit in the list above becomes a visible integrity error instead of silent state. Happy to open a PR if the direction is welcome.
Alternatives considered
-
Database level controls only (row level security, append only tables). These stop some writers but leave the application unable to tell a valid history from an altered one, and do nothing on a shared Postgres the agent does not own.
-
A per row hash without the chain link. Catches edits but not deletions or reordering, so the link to the previous row's hash is the part that matters.
Additional context
Reproduce in under a minute, offline, embedded Postgres via pgserver:
git clone https://github.com/tech4biz-yasha/agmi && cd agmi
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev,letta]"
PYTHONPATH=. python3 -m pytest tests/test_letta_block_history.py -q
Adapter: agmi/adapters/letta_block_history.py. The test pins letta 0.16.8, so it fails the day this changes. If tamper evidence on agent state is already on the roadmap somewhere, a pointer would help me align rather than propose in isolation.
AI Disclosure
AI Tool(s) Used
Claude (Anthropic), for drafting the issue text. The measurements, suite and tests were run and verified by me.
Human Verification
I have personally reviewed this request, verified that it addresses a real use case, and take responsibility for its contents.
Problem statement
In letta 0.16.8 the core memory checkpoint history (block_history, plus block.current_history_entry_id) accepts direct edits in Postgres silently. I measured this with a small open source conformance suite, agmi, that seeds a block through BlockManager.create_or_update_block_async, update_block_async and checkpoint_block_async, edits the rows directly, then walks undo_checkpoint_block back to the first checkpoint and redo_checkpoint_block forward again.
What happens after each edit to the store:
The undo and redo code says explicitly that it tolerates pruned sequence numbers, so the gap tolerance is deliberate and I am not calling it a bug. The reason it deserves a look is that the feature is presented as a checkpoint history with undo and redo, and users will read that as a record of what the agent's memory was. Today it is a record only as long as nobody with database access edits it. For agents whose memory matters to a regulator or an audit, that is a meaningful difference.
Proposed solution
An optional integrity check on block_history: a per row hash over (block_id, sequence_number, value, previous row hash), verified on undo, redo and checkpoint. Off by default. Every edit in the list above becomes a visible integrity error instead of silent state. Happy to open a PR if the direction is welcome.
Alternatives considered
Database level controls only (row level security, append only tables). These stop some writers but leave the application unable to tell a valid history from an altered one, and do nothing on a shared Postgres the agent does not own.
A per row hash without the chain link. Catches edits but not deletions or reordering, so the link to the previous row's hash is the part that matters.
Additional context
Reproduce in under a minute, offline, embedded Postgres via pgserver:
git clone https://github.com/tech4biz-yasha/agmi && cd agmi
python3 -m venv .venv && source .venv/bin/activate
pip install -e ".[dev,letta]"
PYTHONPATH=. python3 -m pytest tests/test_letta_block_history.py -q
Adapter: agmi/adapters/letta_block_history.py. The test pins letta 0.16.8, so it fails the day this changes. If tamper evidence on agent state is already on the roadmap somewhere, a pointer would help me align rather than propose in isolation.