Your agent does not only have a memory problem

Agent failures that look like forgetting are often failures of context control. The system may have stored the relevant history and still serve a stale instruction, flatten a recommendation into a fact, omit the source, or bury the useful item under irrelevant material.

Storage is necessary. It is not enough. The harder problem is deciding what context is warranted for this agent, entity, task, and moment.

Memory can be present and still fail

The symptoms are familiar: an agent asks a question that was already answered, reopens a settled decision, follows an obsolete runbook, or confidently repeats a claim nobody can trace. The reflex is to increase retrieval depth or paste more material into the prompt.

That can make the failure larger. A longer prompt does not decide which of two conflicting documents has authority. A larger vector result does not explain whether a statement was observed, inferred, recommended, or later corrected. More stored history does not tell the agent when a once-valid preference stopped being valid.

Five failures can hide behind the word “memory”:

1. Rot: the stored statement no longer matches live state.
2. Conflict: two sources disagree and no precedence rule resolves them.
3. Timing: useful context arrives after the decision it was meant to inform.
4. Authority: an inference or recommendation quietly hardens into fact.
5. Dilution: the useful memory is retrieved but buried among irrelevant material.

Those are control problems. None is solved by storage volume alone.

Six questions governed context should answer

A governed context system should make six questions explicit:

• Identity: which person, account, project, or caller is this context about?
• Evidence: where did the claim come from?
• Time: when was it true, and when did the system learn it?
• Authority: is it an observation, a source claim, an inference, a recommendation, or a locked decision?
• Salience: how much of it is useful for the task now?
• Feedback: what evidence shows that the served context helped or contradicted the task?

This is governed context intelligence as Northsun (formerly Mnemix)’s differentiator. Every agent proposes. Northsun governs. The model still generates behavior. The context beneath that behavior needs evidence, time, precedence, and measurement.

What builders can evaluate today

Northsun is the memory and enrichment layer for AI agents. It does not build the voice, chat, coding, or workflow agent. Builders wire their own agents to the available surfaces.

The frozen public caller-memory API has three endpoints:

• POST /v1/recall_and_enrich
• POST /v1/calls/end
• GET /v1/caller/{phone_number}

That surface supports a concrete lifecycle: request the known caller profile, prior-call memory, and available enrichment before an interaction; submit the completed call after hangup; and verify the resulting history with a later read. Enrichment is contextual evidence, not identity proof, and integrations must remain useful when enrichment is partial or unavailable.

Northsun also has a hosted MCP endpoint and a source-defined tool surface for agent clients. The MCP contract evolves independently from the frozen REST trio. Evaluate it by inspecting tools/list, pinning the behavior your workflow depends on, and proving the lifecycle in a controlled tenant. A complete authenticated production lifecycle remains something each release must prove, not something a source file can guarantee.

Substrate is not the same as a public capability

The Northsun repository contains tenant-scoped provenance and fact primitives, including evidence_refs and locked_facts. The locked-fact substrate supports assertion, evolution, correction, supersession, and transaction-time history.

Those mechanisms matter, but they do not prove that every caller-memory response carries a complete evidence chain. A migration is evidence of implemented substrate, not permission to describe an end-to-end customer behavior that has not been observed on the deployed path.

The honest state map is:

• The caller-memory lifecycle is the frozen public REST surface.
• The hosted MCP surface can be evaluated through its observed tool contract.
• Provenance, bi-temporal ranges, and locked facts are implemented substrate.
• Unified serving, proactive Beacon delivery, and measured precision remain proof-gated.

A better evaluation than “does it remember?”

Ask for a lifecycle proof instead of a feature list:

1. Record a controlled interaction.
2. Retrieve context for a second task or session.
3. Show exactly what the agent received.
4. Identify the source and state of each important claim.
5. Correct or contradict one item.
6. Verify that a later retrieval reflects the correction without erasing the earlier record.
7. Record what remains unproven.

That test separates storage from control. It exposes whether the right entity was resolved, whether stale context survived, whether a write was merely acknowledged or became observable, and whether the agent received signal or a dump.

The goal is not a database that remembers everything. It is a context system that can defend why this agent received this information now.

Start with the Northsun introduction, then prove one caller-memory or MCP lifecycle in a controlled tenant.

Choose Northsun as your agent memory layer.