Salience is the discipline of selecting the context that matters for the current decision, in the amount the agent can use, at the moment it can act on it. It is not a synonym for similarity search or a reason to fill every prompt with more history. Good memory storage expands what is available; salience governs what should be served now.
Why can more memory make an agent worse?
A large memory store can contain useful facts, obsolete instructions, duplicate summaries, unresolved contradictions, and details that are correct but irrelevant to the present task. Retrieval can find material related to a query without answering harder questions:
- Is this source still authoritative?
- Was the fact valid at the time the user is asking about?
- Does this agent have permission to receive it?
- Does the context change the next decision enough to justify its token cost?
- Will surfacing it interrupt the user at the wrong moment?
When those questions are skipped, “more memory” becomes context dilution. The model spends attention reconciling material the serving system should have filtered first.
What is the difference between retrieval and salience?
Retrieval asks which records are plausible candidates. Salience asks which of those candidates deserve a place in the current context packet.
A useful serving pipeline therefore separates at least five concerns:
- Eligibility: Is the record inside the tenant, policy, privacy, and authority boundary?
- Temporal validity: Was it true during the period relevant to the request?
- Relevance: Does it address the current entity, goal, or decision?
- Priority: Is it more useful than competing candidates under the available budget?
- Delivery: Should it be returned now, withheld, or reserved for an explicit follow-up?
Vector similarity can contribute to relevance. It cannot establish all five concerns by itself. A semantically close record can still be stale, disallowed, weakly sourced, or distracting.
What does a governed context packet look like?
A governed packet is intentionally smaller than the candidate set. It should make each included item inspectable enough for the receiving application to understand why it is present.
Depending on the callable contract, useful packet properties can include:
- the selected context;
- the entity or interaction it belongs to;
- source or provenance information;
- freshness or temporal scope;
- an explanation of degraded or partial results;
- stable correlation data for later feedback and troubleshooting.
The objective is not a universal “perfect prompt.” Voice, coding, support, and workflow agents have different deadlines and consequences. The serving policy should respect the surface without letting each client quietly invent its own authority rules.
How should teams measure salience?
Do not measure success only by whether the desired fact appeared somewhere in a large result set. That rewards retrieval volume and ignores the cost of junk.
Evaluate both positive and negative behavior:
- Did the useful item appear?
- Did stale, unauthorized, or contradictory material stay out?
- Did adding irrelevant candidates make the packet look better under the metric?
- Did the agent use the selected context correctly?
- Could a suppressed result be explained and reproduced?
A measurement that excludes empty or failed packets can produce a flattering average while hiding the cases that matter most. Likewise, a gate that is observed only on allowed examples has not proved that it can suppress anything.
What can Northsun (formerly Mnemix) users use today?
Northsun is the memory and enrichment layer for AI agents. Its current public surfaces support explicit, reactive context workflows:
- the frozen caller REST lifecycle for recall before a voice interaction and write-back after it;
- the hosted MCP endpoint and its authenticated, source-defined tools for caller, contact, and evolving context workflows; a complete authenticated production MCP lifecycle still requires fresh release proof.
These surfaces let an application ask for context deliberately. They do not prove that proactive salience delivery is running in production.
Where does Beacon fit?
Beacon is the design-stage name for a future mechanism that would surface governed context without waiting for an agent to formulate the perfect recall request. Proactive scoring, push delivery, consent controls, frequency caps, and the user-facing surface remain governed design work—not a shipped capability.
That boundary matters. A design can define strong requirements before runtime exists:
- storage consent must remain separate from proactive-push consent;
- server policy must own silence versus delivery;
- non-silent output must retain provenance;
- frequency limits and a kill switch must be server-controlled;
- deleted or disallowed information must not reappear through caches or projections;
- both suppression and allowed delivery must be observed in tests.
Calling an ordinary retrieval result “Beacon” would erase those unproved requirements.
A practical salience checklist
Before injecting a retrieved item into an agent prompt, ask:
- Is the requester authorized to receive it?
- Is its source and temporal scope understandable?
- Does it change the current decision or merely resemble the query?
- Is there a stronger, newer, or explicitly locked fact?
- What useful context would be displaced by including it?
- What evidence will show whether the agent used it correctly?
This checklist works even before a dedicated salience engine exists. It turns prompt construction from “append everything” into a governed serving decision.
What should you do next?
Start with Core concepts to understand Northsun's current memory and governance model. Read Salience and Beacon for the explicit shipped-versus-design boundary, then use the MCP server or Quickstart to prove one reactive lifecycle before designing proactive behavior.