Your AI Agent Doesn't Need More Memory. It Needs Receipts.

An AI agent can remember a 30-page conversation and still perform the same action twice.

It sends a request. The connection times out. The agent remembers the goal, the plan, and the tool
call—but not whether the outside system changed. So it tries again.

That is not a vector-memory problem. It is an action-receipt problem.

The missing memory layer

“Agent memory” often means conversation history, retrieved documents, or durable project knowledge.
Those are useful, but they answer questions about what the agent knew—not what happened in another
system.

I find it useful to separate four layers:

The first two help reasoning. The last two prevent duplicate emails, repeated publications,
double-created listings, and other expensive “helpful” retries.

More context does not close this gap. A model can recall the exact request and still not know
whether a server committed it before the connection disappeared.

Timeout is not failure

Before submission, failure is simple: nothing was sent, so retrying may be safe.

After submission, failure is ambiguous. A timeout, connection reset, or unreadable response can
mean either:

• the platform never received the request; or
• the platform completed it, but the response never reached the agent.

Treating both cases as “failed” converts a transport problem into a duplicate-action bug.

The operation therefore needs a state that most happy-path workflows omit:

planned -> submitted -> succeeded
                    \-> rejected
                    \-> outcome_unknown -> reconciling
                                         \-> succeeded
                                         \-> safe_to_retry
                                         \-> manual_review

outcome_unknown is not an error message to hide. It is durable knowledge about the limit of what
the system can currently prove.

What an action receipt records

A receipt should be written before the external request. Otherwise the precise failure that makes
it valuable can also prevent it from existing.

A small receipt can contain:

{
  "operation_id": "20260816T012030Z-1fd54b31a2",
  "operation": "articles.create",
  "target": "/api/articles",
  "state": "submitted",
  "intent_fingerprint": "sha256:…",
  "submitted_at": "2026-08-16T01:20:30Z",
  "external_id": null,
  "authentication_recorded": false
}

The fingerprint should be calculated from an allowlisted or redacted representation of the intent,
not from secrets. The receipt needs enough identity to recognize the effect later; it does not need
to become a second credentials store.

This is also different from a log line. Logs describe events. A receipt is an operation record with
a lifecycle. The system updates the same record as its knowledge changes.

I added this to a publishing CLI

I tested the pattern in a small CLI that writes to the DEV API. The CLI already previewed mutations,
required explicit confirmation, wrote a private intent file, and never retried a write after a
network failure.

But the intent file stayed an intent file forever. A successful response did not advance it to
succeeded, and an ambiguous transport failure did not advance it to outcome_unknown. The safety
rule existed in the client, while the durable state lagged behind it.

The corrected shape is deliberately boring:

receipt = record_intent(operation, sanitized_request)
update(receipt, state="submitted", submitted_at=now())

try:
    response = send_once()
except ExplicitRejection as error:
    update(receipt, state="rejected", error=error.code)
    raise
except TransportFailure as error:
    update(receipt, state="outcome_unknown", error=error.code)
    raise
else:
    update(
        receipt,
        state="succeeded",
        external_id=response.id,
        completed_at=now(),
    )

There is intentionally no retry in that exception path. Tests cover success, explicit rejection,
and ambiguous failure as different receipt states.

One implementation detail mattered more than I expected: state updates should be atomic. Replacing
the receipt through a private temporary file avoids turning a process interruption into half a JSON
document—the audit system creating its own ambiguous evidence.

Reconcile the world, not the agent's story

An unknown outcome is resolved with a read, not another write.

The reconciler should:

1. Query the external system by its idempotency key or returned identifier when one exists.
2. Otherwise perform a bounded search and match the smallest safe intent fingerprint.
3. Mark the operation succeeded if the intended effect exists.
4. Mark it safe_to_retry only when absence is actually provable and the operation permits retry.
5. Send every remaining case to manual_review.

This is where API design changes the safety envelope. A platform with idempotency keys and exact
read-after-write lookup is much easier to automate safely than one with neither. When the platform
offers no reliable way to prove absence, “I cannot tell” is the correct answer.

Receipts are evidence, not truth

Receipts solve one narrow problem: what request was attempted, what the transport reported, and
what external effect was later observed.

They do not prove that the request was wise, that the payload was semantically correct, or that the
verification query inspected the right thing. A perfectly maintained receipt can preserve a bad
decision with excellent fidelity.

That means receipts belong beside—not instead of—policy checks, human approval for consequential
actions, semantic validation, and negative controls for the verifier itself.

There are other limits too:

• eventual consistency can make a successful effect temporarily invisible;
• two similar operations may not have a unique fingerprint;
• some APIs expose no idempotency key or stable lookup;
• a crashed process can leave a submitted operation that still needs recovery;
• retention and redaction rules must match the sensitivity of the action.

Those limits are exactly why manual_review belongs in the state machine.

What should an agent be allowed to forget?

Scratch context can expire. Old plans can be archived. Failed approaches can become history.

But an externally visible attempt with an unknown outcome should not be forgotten or summarized
away. Keep it until the world has been reconciled with the agent's intent.

The practical question is not only, “What does the agent remember?”

It is: What can the system prove happened before the agent acts again?

Which external write in your system is hardest to reconcile after a timeout?