[Cloud API] Queued agent-memory writes lack a usable task_id or exact visibility proof

[viowai]

Summary

Agent-memory writes accepted through the EverMe gateway remain observable only as queued, but the client-facing response does not preserve a usable task_id or another exact ingestion identifier. This makes it impossible for a safety-conscious importer to distinguish:

• accepted but still processing,
• indexed and exactly retrievable,
• expired from the task-status TTL,
• or failed server-side.

The result is a fail-closed ingestion pipeline that cannot safely advance its visibility watermark and must stop instead of retrying or duplicating data.

Observed behavior

On 2026-07-13, a bounded recovery sent 20 controlled batches exactly once through the EverMe agent-memory gateway with extraction disabled for historical data.

• Every request was accepted.
• Every client-visible result was status: "queued".
• No upload error was returned.
• The response/checkpoint contained no task_id, request_id, terminal state, or exact visibility proof.
• The batches were not retried or resent.
• Subsequent ranked memory searches did not provide exact proof that these specific batches became visible.
• A local reconciler therefore correctly classified the state as remote_ingestion_stalled and left the checkpoint unchanged.

There are currently 6,598 historical checkpoint entries in the same state. This count is included only to show operational impact; no identifiers or memory contents are included here.

Relevant API contract

The Cloud agent-memory documentation says an async 202 response includes a task_id, and documents GET /api/v1/tasks/{task_id}. The task record has a one-hour TTL.

However, the EverMe gateway/MCP path used by agent integrations does not expose that tracking metadata to the caller. In the current MCP implementation, mem_save_turn returns only:

{
  "saved": true,
  "status": "queued",
  "messageCount": 0,
  "flushed": false
}

Even if the upstream gateway response contains a task ID, this response shape drops it.

Expected behavior

Please provide at least one exact, documented reconciliation path:

1. Preserve and return task_id and/or request_id from the EverMe gateway and MCP tools.
2. Document whether that ID is accepted by the Cloud GET /api/v1/tasks/{task_id} endpoint.
3. Return a terminal state such as indexed, failed, or expired, including a sanitized failure reason.
4. Provide an exact raw-message lookup/list operation scoped by conversationId / session_id and message or batch identifier, rather than requiring ranked semantic search as proof.
5. Clarify the relationship between the EverMe gateway credentials and the EverOS Cloud task-status API.

Why exact status matters

Semantic/vector search is intentionally ranked and cannot prove absence. Re-uploading on a search miss risks duplicates, while treating queued as indexed creates false health reports. Importers need an exact reconciliation signal to remain idempotent and fail closed.

Environment

• EverMe Codex plugin: 0.4.0
• evercli: 0.2.3 (darwin/arm64)
• Managed EverMe gateway
• Official EverOS Cloud API independently authenticated and healthy
• No remote delete, force import, bulk flush, or repeated upload was performed

Security

This report is deliberately sanitized. It contains no API keys, agent tokens, account identifiers, conversation IDs, batch hashes, local paths, raw messages, or private logs.