From accepted outcome to verified retrieval
Inspect AgentCore Memory delivery separately from accepted State and model use.
Guide context
Inspect optional delivery to AgentCore Memory: acceptance, submission and verified retrieval have separate receipts and do not prove model consumption.
Optional delivery can send an eligible Kam result to a configured AgentCore Memory destination and verify retrieval. Acceptance, submission and retrieval are separate facts. A delivery receipt does not establish that an agent recalled the record or used it in a model request.
On this page · 4 sections
Inspect the Memory delivery boundary
Start with accepted State
Acceptance alone does not establish destination delivery.
Check submission and retrieval
Keep the configured Memory request and verification receipts distinct.
Leave consumption unclaimed
Retrieval does not prove recall or model use; live qualification is separate.
Select an authorized destination and starting point#
A prospective delivery policy names the scope, lifecycle epoch, destination binding/version, and first eligible checkpoint version. Older generations are not implicitly backfilled. Under policy v1 every eligible generation keeps its own obligation. Under policy v2 a newer generation may replace only a candidate that was never planned, dispatched or submitted; the replaced obligation is kept as SUPERSEDED with the replacing generation. Submitted or uncertain work is never coalesced.
Read the progression and stop states#
AWAITING_PUBLICATION
Durable work exists for one eligible generation. The worker plans the authorized request and records publication attempts.
AWAITING_VERIFICATION
The write has been acknowledged. A separate exact read still needs to match the expected content and lineage.
VERIFIED
The exact record matched through the approved namespace at verification time. This is not proof of semantic-search ranking or agent consumption.
Explicit stops
REJECTED, AUTHORITY_BLOCKED, and RECONCILIATION_REQUIRED remain visible. The orchestrator does not repair mismatched remote content.
SUPERSEDED (policy v2)
A never-submitted candidate replaced by a newer generation. Counted separately from unresolved work; it is neither a failure nor a delivery.
Separate local correction from remote cleanup#
Local revisions and new generations are implemented. Remote supersession, deletion, and operator reconciliation require separate work. A failed verification read does not become another create. Do not infer that publishing a newer memory automatically removes all older destination records.
Count like with like#
deliveryStatus() reports accepted/applied outcome revisions separately from local-generation delivery counts. Do not subtract verified generations from accepted revisions or chart them as one funnel.
The status read covers at most 32 scopes and 100 obligations per scope. Check coverage.complete before treating counts as complete. Counts of due or leased work overlap workflow stages; they are not extra stages to add to a total. Oldest-work reporting includes non-verified stop states.