The simplest useful agent-memory lifecycle has three observable steps: recall context before the interaction, submit the completed interaction after it ends, and verify the write with a later recall. Keeping reads and writes at those boundaries prevents partial conversations from becoming premature memory.
Why recall before the interaction?
Context is most valuable before the agent commits to its first useful action. In a voice call, that means requesting same-number caller history and available enrichment before the opening turn. In another agent surface, it means assembling the relevant context packet before the task or decision that needs it.
The application should decide how much of the response enters the model context. It should also preserve a neutral fallback: missing memory or partial enrichment must not make the interaction unusable.
For Northsun (formerly Mnemix)'s frozen caller REST contract, the pre-interaction call is:
POST /v1/recall_and_enrich
The response can include caller profile, prior-call memory, nullable enrichment branches, request timing diagnostics, freshness information, and a trace identifier. Request-level timing fields are diagnostics, not public benchmarks.
Why wait until after the interaction to write back?
During an interaction, the state is incomplete. The user may correct a detail, reverse a decision, abandon a request, or clarify an outcome near the end. Writing durable summary material too early can preserve a draft as if it were final.
After hangup or workflow completion, normalize the event into a stable record:
- the same caller or entity identifier used for recall;
- a session or platform correlation ID;
- the completed transcript or structured observation;
- duration or relevant event timing;
- the final outcome;
- only the metadata your contract allows.
For the frozen caller API, submit that record once to:
POST /v1/calls/end
What does 204 No Content prove?
It proves that the HTTP request received the documented successful acknowledgement. It has no body and must not be parsed as JSON.
For Northsun's caller-memory path specifically, it also proves the interaction is already committed durably — the database write happens before the response returns, and an immediate subsequent recall for that caller contains it. That guarantee is scoped to the interaction record; it does not, by itself, prove that every other downstream step (enrichment, a separate background bridge) has completed. See Hangup, and what happens next.
That distinction matters whenever a queue, background processor, enrichment job, summarizer, or index sits behind the response.
How do you verify write-back?
Use a controlled observation that is easy to identify and safe to store, then perform a later independent read:
- Recall the controlled test number with session ID
session_before. - Complete the synthetic interaction.
- Submit one unique outcome or phrase with
calls/end. - Record the acknowledgement time and retain the redacted session and trace identifiers.
- No wait is required — the interaction is already committed durably by the time
calls/endresponds. - Recall the same number with a new session ID.
- Verify the unique observation appears in the returned summary or recent-call history.
If it does not appear, you have a diagnosable failure instead of an ambiguous success. Keep the two trace IDs and timestamps, then follow the troubleshooting path.
How should retries work?
Voice platforms and webhook providers may deliver the same end event more than once. Deduplicate at the integration boundary using the platform's stable call or event identifier.
Do not create an unbounded retry loop when the state of an earlier write is unknown. Use bounded exponential backoff for retryable failures, respect Retry-After when present, and stop when the retry budget is exhausted. A later read can help determine whether a previously acknowledged submission became visible.
The failure mode to avoid is retry amplification: several webhooks each launch several write attempts, producing duplicate interactions while the original request may already be processing.
What if recall is unavailable?
The agent should continue with a neutral experience. Do not invent remembered details, do not turn enrichment into identity proof, and do not disclose stale cached context merely to avoid an empty prompt.
For authenticated caller-memory database degradation, recall_and_enrich can preserve a 200 response shape with empty defaults and degraded: true. Authentication, validation, and rate-limit errors still require normal non-2xx handling. Your integration should distinguish those cases rather than treating every response as equivalent.
Does the pattern apply outside voice?
Yes. The boundaries generalize:
- coding agent: recall repository decisions before planning; record the ratified outcome after verification;
- support chat: recall account context before responding; save the final interaction after the conversation closes;
- workflow agent: retrieve governed facts before proposing an action; record the observed result after the external system responds.
The transport may be REST or MCP. The invariant is temporal: read before the decision, write after the event, verify the write with a later read.
What does one successful lifecycle establish?
For the controlled test, it can establish:
- authentication and tenant scope;
- request and response mapping;
- safe handling of partial enrichment;
- correlation across the interaction;
- observed the write-back through a later read.
It does not establish a latency percentile, every vendor-platform mapping, proactive delivery, another tenant's behavior, or production readiness at arbitrary scale.
Run the lifecycle
Follow the Quickstart for copyable requests, then use the API reference for exact fields and status codes. Add the bounded failure behavior in Errors and retries before connecting real traffic.