Retention, rolling history, and checkpoints
Know which State evidence an AgentCore task can still read later.
Guide context
Plan evidence availability for AgentCore workloads. Kam History, retained inspection evidence and AgentCore Memory use separate clocks and controls.
Choose which evidence your AgentCore application must be able to inspect later. Kam's rolling History window and retained evidence have their own limits; Memory has separate retention settings. A processing checkpoint is not a permanent copy of everything the agent has seen.
On this page · 8 sections
Choose the evidence each owner retains
Working History
Plan the bounded UTC-date reads your AgentCore application needs.
Retained State evidence
Inspect only versions still available under retention and authority.
Memory recall
AgentCore Memory policies are separate; automatic Kam archival is not built.
A rolling window. A maintained state.#
Kam advances working state as outcomes arrive and time moves forward. A recovery checkpoint keeps processing continuous; it is not a permanent summary of everything the system has seen.
Rolling operational history
The working window contains today and the previous 364 UTC dates. It advances each day, not through annual resets.
Checkpointed rolling state
Processing resumes from the persisted checkpoint and applies accepted transitions. Exact reads use published views rather than rebuilding the full history.
Versioned supporting evidence
Revisions and references support inspection until their deadlines. Supporting evidence may be retained for up to 730 days, with correction-related extensions.
Kam working history#
365 UTC dates
Today and the preceding 364 UTC dates. The window advances daily; out-of-window contributions are removed from rolling state, not consolidated into a permanent baseline.
Kam supporting evidence#
Separate inspection limits
Supporting revisions and references may remain for up to 730 days, with direct-prior-revision extensions for corrections. Inspection ends when its evidence expires; this is not automatic cold-tier archival.
AgentCore raw events#
Configurable, up to 365 days
AWS applies this retention to raw short-term events. It is separate from Kam’s window and AgentCore long-term records.
AgentCore long-term records#
Strategy or batch-request policy
AWS supports optional record TTL of at least 31 days and explicit deletion. With no TTL configured, those records do not expire. Raw-event expiry is a separate policy.
Carry-forward consolidation#
Preserve selected historical meaning in a versioned summary baseline while older evidence follows a separate archive policy. This is a proposed extension, not the behavior of the current rolling reducer.
Summary selection, provenance, corrections, archive verification, retrieval, and deletion need their own implementation and qualification. A summary is derived context, not a replacement for exact evidence or a guarantee against context drift.
AWS documentation#
The AWS sources below explain raw-event expiry fixed at write time, optional per-strategy long-term-record expiry and explicit deletion. They do not define Kam’s History retention contract.
Expiry does not prove erasure#
Reads enforce logical expiry before asynchronous TTL cleanup. Bounded owner export, primary-state deletion, and a restore fence are implemented in source. Live downstream erasure and restore drills remain separate release gates. A missing old reference is not rebuilt on demand or silently replaced with a newer record.