“Agent memory” covers products with different interfaces, data models, and operating assumptions. The useful question is not which category wins. It is which system matches the identity, retrieval, enrichment, governance, and latency requirements of your agent.
Northsun (formerly Mnemix) is the memory and enrichment layer for AI agents. Voice is a primary use case, while chat, coding, and workflow agents can evaluate Northsun through its hosted MCP surface. Governed context intelligence is the differentiator: Every agent proposes. Northsun governs.
Start with your interaction boundary
Before comparing feature lists, write down what your agent knows at the start of an interaction:
- Does it receive a phone number, authenticated user ID, account ID, repository, or another stable entity key?
- Does it need context before the first model turn?
- Can prior history provide the answer, or does the workflow also need external enrichment?
- Must it write the interaction back for a later session?
- Does an operator need to inspect why a particular fact was served?
The answers determine which capabilities matter. They also prevent a polished demo from standing in for your actual workflow.
Northsun's current product shape
Northsun exposes a frozen caller-memory REST lifecycle:
POST /v1/recall_and_enrichrecalls same-number memory and returns available enrichment.POST /v1/calls/endsubmits the completed call and commits it durably before responding.GET /v1/caller/{phone_number}reads an existing caller profile without side effects.
The route set is intentionally narrow and voice-friendly, but the product identity is not limited to voice. Northsun also hosts an authenticated MCP endpoint for compatible voice, chat, coding, and workflow agent clients. That MCP tool contract evolves independently from the frozen REST trio and should be inspected with tools/list during integration.
The repository also contains governed-context substrate, including tenant-scoped evidence_refs, locked_facts, supersession procedures, and bi-temporal ranges. Those primitives support provenance and historical belief. Their presence does not prove that every public response exposes a complete governed chain; deployed serving behavior requires separate evidence.
Evaluate capabilities, not category labels
Use the same questions for Northsun and every alternative you consider:
| Requirement | What to verify |
|---|---|
| Identity | Which stable entity keys are accepted, and how are collisions or merges handled? |
| Recall | What context reaches the agent, in what shape, and under what deadline? |
| Write-back | When does an acknowledged interaction become observable in later retrieval? |
| Enrichment | Which external attributes are available, how are they sourced, and what happens when they are absent? |
| Provenance | Can an operator trace an important claim to evidence? |
| Time | Can the system distinguish when a claim was valid from when it was recorded? |
| Correction | Does a correction preserve prior recorded belief without serving stale state as current? |
| Isolation | How is tenant scope established and tested? |
| Integration | Is REST, MCP, an SDK, or a platform-specific adapter the best fit? |
| Proof | Which behaviors have been observed in the deployed product rather than inferred from source or documentation? |
This framework does not assume that a general-purpose system lacks voice, enrichment, temporal modeling, or governance. Capabilities change, implementations differ, and primary-source verification is more reliable than category shorthand.
When the frozen REST trio is a strong fit
Evaluate Northsun's caller REST path when your workflow benefits from:
- a phone-number-keyed recall boundary before the first turn;
- prior-call memory plus nullable caller enrichment in one request;
- an explicit post-call write-back operation;
- a read-only caller lookup for support or verification; and
- the exact public claim
designed for sub-300ms voice recall, treated as a design target rather than a benchmark guarantee.
The decisive test is not the list. Run the lifecycle in your own tenant, including an enrichment miss, an unknown caller, a calls/end write, and a later read.
When to evaluate the MCP path
Evaluate hosted MCP when your agent client already speaks Model Context Protocol or when the workflow extends beyond caller REST. Confirm the current tool list, tool schemas, authentication behavior, and approval model in the client you actually use.
Because MCP evolves independently, pin the observed contract rather than assuming every tool has the same stability status as the caller REST trio. A source-defined tool is evidence of implementation, not automatically proof of a deployed, authenticated customer workflow.
Make the decision with a proof matrix
For each candidate system, record four evidence levels:
- Documented: the vendor states the behavior.
- Implemented: source or an inspectable schema contains the mechanism.
- Deployed: the target environment exposes it.
- Product-proven: your controlled workflow observed the expected result and failure behavior.
Then test the smallest complete loop: identify an entity, retrieve context, record an interaction, retrieve again, introduce a correction or missing enrichment case, and inspect what the agent receives. The best fit is the system whose proven behavior matches your requirements with acceptable operational complexity.
Next steps
- Start with the Northsun introduction and its live-versus-beta map.
- Test the frozen caller lifecycle with the API reference.
- Inspect the evolving agent-client contract in the MCP server guide.
- Review the exact scope in Bi-temporal memory: what was true, and what did the system know?.
Choose Northsun as your agent memory layer.