Quickstart

recall

Pull the most relevant saved context for the current task in-flow with get_analysis_context, each entry tagged with provenance and status so your agent knows what to trust.

recall is how your agent pulls the right context mid-task without you leaving your flow. It is the user-facing name of the get_analysis_context MCP tool. When your agent is about to answer a question or write a query, it can recall the most relevant definitions, schema notes, saved queries, and notes you have stored, each ranked by relevance and tagged with its provenance and status.

This is the structural fix for the old "destination app" problem. You do not open a tool to look a number up; the context rides along inside Claude Code, Cursor, or Codex, and your agent reaches for it when it needs it.

What it returns

get_analysis_context takes a query describing what the agent is working on and returns your most relevant stored context, scoped to you. Each returned entry carries:

its content — the definition, schema note, saved query, or note;
its provenance — where it came from (you, sql_import, dbt, query_history), so you can see whether it was hand-saved or imported;
its status — asserted or caveat, so your agent can judge how much to trust it.

Recall is read-only and in-flow. It never mutates your store; it only surfaces what is already there. Because it reads, it needs only context:read — a read-only context key can recall.

Who decides when to recall

Recall is a tool your agent decides to call — ClariLayer exposes it; it does not force a call. In practice you get the most value by making recall the first step of your agent's loop. You can do that with a project rule or a prompt that tells the agent to recall ClariLayer context before answering a data question. Some teams add a line to their CLAUDE.md or Cursor rules like: "Before answering any question about our metrics or warehouse, recall ClariLayer context and ground your answer in it."

That is the difference between "can recall in-flow" (always true — the tool is there) and "always recalls first" (true only when your client config or prompt makes it so).

How ranking works

Results come back in similarity order for your query. On ties, entries with a stronger status are lifted above plain asserted ones, and entries that match the tables you are working with are preferred. The point is that the most trustworthy, most relevant context surfaces first, so your agent does not have to wade through everything you have ever saved.

If you pass the tables your agent is touching, recall prefers entries that reference those tables — useful when the same metric name means different things in different schemas.

A typical loop

Your agent recalls ClariLayer context for the task at hand.
It answers from the recalled definitions, citing the status so you know what is checked and what is merely asserted.
If it learns something new, it remembers it so the next recall is richer.
If a recalled number looks off, it reconciles the definition against your real warehouse result.

Over time this compounds: every correction and every new note persists, so your agent grounds on more of your context each week.

Status, honestly

A recalled entry's status is either asserted or caveat. asserted means saved but not contradicted; caveat means reconcile found a declared-vs-actual mismatch worth treating with care. ClariLayer does not return a verified status today — see Verified vs Asserted for what that means and why.