# Save and verify

Source: https://docs.getdeeprecall.com/agents/save-and-verify/

> Handle queued writes without false success claims or duplicate retries.

Report what the service has confirmed, then verify that the intended memory is available.

## Interpret the acknowledgement

A `remember` call can return:

```json
{ "status": "queued", "job_id": "00000000-0000-4000-8000-000000000001" }
```

The UUID above is illustrative. The real job ID is generated by the server. Say that processing started. Do not say the memory is already searchable.

Extraction and reconciliation can produce one memory, multiple memories, an update, or no new stored memory. A successful workflow is not a promise that every submitted sentence became a new record.

## Verify through the supported surface

The current MCP surface has **four tools** and no job-status tool. Use later `recall` to check for the intended information. A first-party account integration can use the authenticated REST job-status endpoint with its own appropriate authentication; an MCP token is not a REST token.

For a user-facing test, inspect the memory in the app and recall it from a fresh conversation. Match the content and source, not only a familiar phrase repeated from chat context.

## Recover from an unknown result

If a response is lost or a save is still processing, do not immediately submit the same content again. Check available status or search later. If the job is known to have failed, explain the failure and offer a deliberate retry.

Do not poll indefinitely or claim completion because a timeout elapsed. Explain what remains unknown and point to [troubleshooting](/help/troubleshooting/).

## Preserve temporal meaning

Include dates and temporary scope in natural language. Do not supply your own learning timestamp, tags, confidence, entities, or validity windows to MCP `remember`; those fields are not accepted by its strict schema.