# From accepted outcome to verified retrieval

Inspect optional delivery to AgentCore Memory: acceptance, submission and verified retrieval have separate receipts and do not prove model consumption.

Status: Implemented in source. Prelaunch; not a live service guarantee.

Reviewed: 2026-10-14.
Backend source: e16b81b4a637acec91f3aed8a71cf5b0f42f0c19.
Native toolkit: merged in PR #176, reviewed at e16b81b4a637acec91f3aed8a71cf5b0f42f0c19.
HTML: /docs/publication

## In short

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.

**Available today:** Delivery is implemented and off by default, with simulated AWS transport tests. Live destination access, retrieval and consumption need separate evidence.

> Inspect AgentCore Memory delivery separately from accepted State and model use.

## 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

1. **AWAITING_PUBLICATION** — Durable work exists for one eligible generation. The worker plans the authorized request and records publication attempts.

2. **AWAITING_VERIFICATION** — The write has been acknowledged. A separate exact read still needs to match the expected content and lineage.

3. **VERIFIED** — The exact record matched through the approved namespace at verification time. This is not proof of semantic-search ranking or agent consumption.

4. **Explicit stops** — REJECTED, AUTHORITY_BLOCKED, and RECONCILIATION_REQUIRED remain visible. The orchestrator does not repair mismatched remote content.

5. **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.

> **Current release boundary**
> Marketplace availability, production p99, and production AgentCore write-back remain qualification gates. The delivery loop is implemented, disabled by default, and tested through simulated transport. This is not live production qualification.

[See the delivery-state diagram](/architecture#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.