Skip to main content
Retrieve and the drop-in proxy both ship with sensible defaults, but “sensible” isn’t always right for your data. This guide is a symptom-to-fix map for the knobs that actually move recall quality.

”It’s returning duplicates of the same fact”

This is by design, and there’s a knob for it. Anona keeps two layers (raw fact memories and consolidated note memories synthesized from them), and by default (prefer_observations: true) a note replaces the facts it was built from, so you see one distilled result instead of the same content several times. If you’re still seeing what looks like duplication, you’re probably retrieving with prefer_observations: false (or an old space that predates consolidation catching up). Leave it at the default unless you specifically need the raw evidence behind a synthesis:

“It’s returning too little” / “missing an obvious memory”

Check these in order:
  1. Is min_score filtering it out? min_score drops anything below the floor without shrinking limit, so a high floor can silently return fewer results than you asked for. Lower it or omit it.
  2. Is a scope key excluding it? A scoped query (user_id/agent_id/session_id) returns only memories written under that exact scope, never unscoped ones, never another scope’s. If the memory was written without a scope and you’re querying with one, it won’t come back. See Scoping.
  3. Is limit too low? Default is 10. Raise it (limit / top_k, up to 100) if the memory exists but is being cut off by rank.
  4. Is it filtered by memory_type or tags? Both narrow the result set; drop them to confirm the memory shows up unfiltered, then add them back deliberately.

”It’s returning too much” / “the wrong things are ranking high”

  1. Raise min_score. This is the direct lever for precision vs. breadth. It trims low-relevance results without touching how many you asked for.
  2. Add memory_type or tags filters if you know which kind of memory you actually want (e.g. memory_type: ["fact"] to skip synthesized notes and summaries).
  3. Check you’re on mode: "accurate", not "fast". fast skips the neural rerank pass and ranks on retrieval fusion alone: faster, but lower precision. It trades exactly the quality you’re trying to improve.

”The proxy is injecting too much / too little context into the model”

This is the chat/responses/messages proxy, not raw retrieve, so the knobs are the memory tunables, not retrieve parameters: Set these once as space defaults (PUT /v1/spaces/{space_id}/chat-settings) instead of a header on every call if the whole space should behave differently. Resolution order is body → header → space default → platform default, so a space default is a safe place to change behavior without touching call sites. See Migrating to the drop-in proxy.

”I want the model to see the memories exactly, not rely on the proxy’s injection”

Build the prompt yourself with format: "block" on retrieve, which returns a ready-to-paste string with the token budget already applied:
context_max_tokens drops whole memories, lowest-ranked first, until the block fits, and text is never truncated mid-sentence. results is still returned alongside the block, so you get both for one round trip.

”Recall is too slow”

Latency-sensitive path (an agent loop, autocomplete-style lookups)? Set mode: "fast" on retrieve, which skips the neural cross-encoder rerank and ranks on retrieval fusion alone. Accept the precision tradeoff deliberately, and don’t set it globally as a default without checking result quality first.

Quick reference

Next steps

Retrieve API

Full parameter and response reference.

Chat API: memory tunables

Every proxy tunable, body and header form.