Prompt and Context Design for Claude Analytics Agents

Two analytics agents can run the same model against the same warehouse and produce wildly different quality. The difference is almost always context design: what information the agent sees when it reasons, and just as importantly, what it does not. Engineers new to building agents tend to over-stuff context — every table, every past message, every rule — on the theory that more information helps. It usually hurts. This post is about the craft of deciding what belongs in a Claude analytics agent's context window and what to deliberately keep out, and why those choices drive accuracy more than model selection does.

Context engineering is a curation problem

Context engineering is the practice of deciding which information enters a model's working context at each step, so the model has exactly what it needs to reason well and nothing that distracts it. For an analytics agent, the temptation is to treat the context window as a dumping ground: paste the whole data dictionary, every business rule, the full conversation history, and hope the model sorts it out. Modern Claude models have enormous context windows, which makes this feel safe. It is not. A large window is a budget, not a mandate to fill it.

The reason curation beats accumulation is that attention is finite even when the window is huge. When the one schema note that disambiguates "revenue" sits buried among four hundred irrelevant tables, the model is more likely to miss it. Signal-to-noise matters. The discipline is to ask, for every token you add, "does this help the agent answer this question?" If not, it belongs in a tool the agent can fetch on demand, not in the standing context.

What belongs in the standing context

Some things should always be present because they govern every interaction. The agent's role and non-negotiable rules belong here: it queries a governed warehouse, emits read-only SQL, discovers schema before writing queries, shows its SQL, and asks one clarifying question when intent is unclear. Your dialect and fiscal calendar belong here if dates or syntax matter. A small set of worked examples — a question, the SQL, the expected answer shape — belongs here because they anchor behavior more effectively than abstract rules. And the tool definitions belong here, since the agent needs to know its available moves.

flowchart TD
  A["Standing context: role, rules, examples, tools"] --> B["Question arrives"]
  B --> C{"What does THIS need?"}
  C --> D["Fetch only relevant schema"]
  C --> E["Pull only relevant metric defs"]
  D --> F["Compact working context"]
  E --> F
  F --> G["Reason, query, verify"]
  G --> H["Answer + cited SQL"]
  G -->|prune stale turns| F

The pruning arrow in that diagram is easy to overlook and important to build. As a conversation grows, old intermediate query results and superseded schema fragments stop being useful and start being noise. A well-designed agent drops or summarizes them, keeping the working context focused on the current question. Stale context is not free; it costs money and dilutes attention.

What to deliberately leave out

The harder skill is exclusion. Leave the full schema out of the standing prompt — fetch it per question. Leave raw PII out entirely; the agent rarely needs individual records to answer aggregate questions, and excluding them shrinks your risk surface. Leave verbose past turns out once they are no longer relevant; a ten-message conversation does not need all ten messages re-fed at full fidelity. Leave out exhaustive lists of edge-case rules that apply to questions nobody asks; encode those as schema notes the agent pulls only when it touches the relevant table.

There is also a subtler exclusion: do not paste raw, ungroomed metadata. Cryptic column names with no explanation are worse than absent — they invite confident wrong guesses. Either curate a column into a useful note or leave it out of what the agent sees. The goal is that everything in context is both relevant and trustworthy. Half-explained data is a trap that produces plausible, wrong SQL, which is the most expensive kind of error because it looks right.

Grounding: every claim traces to retrieved data

The strongest defense against hallucinated analytics is a grounding rule baked into context: the agent may only state numbers that came from a tool result, and it must cite the query that produced them. This turns the model from a source of facts into a narrator of retrieved facts. When the context makes clear that unsupported numbers are forbidden and that every answer must carry its SQL, the agent's failure mode shifts from "makes up a plausible figure" to "says it could not find the data" — which is a vastly safer failure.

Grounding also shapes how you feed tool results back. Return them as clean, structured data with column names and row counts, so the model narrates from something unambiguous rather than reinterpreting a blob. Include the query_id and execution metadata so the cited SQL and the stated number are provably the same event. The discipline of "context in, evidence out" is what lets non-technical users trust the agent: they can always see the receipts beneath the sentence.

Iterating on context with real questions

Context design is never right the first time; it is tuned against reality. Run real user questions through the agent and read the transcripts. Where it guessed a column, the schema note was missing or unclear — add it. Where it asked a needless clarifying question, your rules were too cautious — relax them. Where it pulled tables it did not use, your discovery step was too broad — tighten it. Each fix is a small, surgical change to what enters context, and the improvements compound. Within a couple of iterations the same model that gave shaky answers becomes dependable.

The meta-lesson is that the context is your real product surface, more than the prompt and far more than the model. Treat your schema notes, metric definitions, examples, and pruning logic as living artifacts that you version and improve. A team that systematically refines what its agent sees will beat a team that keeps reaching for a bigger model, because they are solving the problem that actually limits quality: not raw capability, but the right information in the right place at the right moment.

Frequently asked questions

If Claude has a huge context window, why not include everything?

Because attention is finite even when the window is large. Burying the one note that disambiguates a metric inside hundreds of irrelevant tables makes the model more likely to miss it. Curated, relevant context beats exhaustive context for both accuracy and cost.

How do I handle long conversations without context bloat?

Prune or summarize stale turns and superseded query results as the conversation grows. Keep the standing rules and the current question's relevant data; drop intermediate scratch work once it has served its purpose. This keeps attention focused and per-turn cost low.

Should metric definitions live in the prompt or be fetched?

Fetch the ones tied to specific tables on demand, alongside the schema. Keep only the handful of truly universal definitions and rules in the standing context. This mirrors progressive disclosure: the agent learns how to find definitions and pulls just the ones each question requires.

What single context change most improves accuracy?

Curated schema notes that explain ambiguous columns and encode your real metric definitions. More than model choice or window size, clear, trustworthy metadata in context is what stops the confident-but-wrong SQL that erodes user trust fastest.

Bringing agentic AI to your phone lines

CallSphere applies the same context discipline to voice and chat agents — giving them exactly the live data they need to answer every call and message, use tools mid-conversation, and book work 24/7. See it at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.