Context engineering for data agents: authority, permissions and a token budget

A working definition

Anthropic describes context engineering as "the set of strategies for curating and maintaining the optimal set of tokens" during inference. Prompt engineering concerns how you phrase instructions. Context engineering covers everything else that reaches the model, and it repeats at each step of a loop: a tool result arrives, so you decide again what stays. Anthropic’s framing treats attention as a budget that each token draws down, and sets the goal as the smallest set of high-signal tokens that makes the desired outcome likely.

Most guides stop at that general framing, with compaction, memory and sub-agents as the toolkit. Those techniques transfer directly to data work. What transfers badly is the unstated assumption that more relevant material is always safe to include. In a coding agent, a stale file produces a failing test. In a data agent, a stale definition produces a plausible revenue figure, and nobody gets an error.

Four properties ordinary context does not need

A snippet of retrieved text does a data agent little good unless the system also knows four things about it. I’d store them alongside the text, in machine-readable form, so code can act on them.

• AuthorityWho stands behind this? A finance owner’s approved definition and a pattern inferred from last month’s queries can both say what revenue means. They do not deserve equal weight, and the reader should know which one was used.
• Permission scopeWho may see this? A list of customer names sampled for value lookup is customer data. An index built by a privileged job and queried by everyone has removed row-level security for that column, and nobody decided to.
• ExpiryWhen does this stop being true? Table descriptions and fiscal calendars are tied to releases and business events. Context with no owner or review date decays without anyone noticing.
• BindingWhich physical objects does it apply to? A definition that names columns can be checked against the catalog on each change. A paragraph in a wiki cannot.

id: metric.net_revenue
text: >
  Invoiced amount after discounts and returns, before tax.
  Excludes internal test accounts. Fiscal year starts in February.
authority: owner_approved
owner: finance-data@example.com
reviewed: 2026-09-30
binds_to: [fct_invoices.net_amount, dim_accounts.is_internal]
visible_to: all_authenticated
conflicts_with: [metric.gross_bookings]

What goes into the assembly

OpenAI’s account of its in-house data agent lists six context layers: table usage, human annotations, code-derived enrichment, institutional knowledge, memory and runtime context. It’s a useful public reference since it describes a large deployment and several layers come from outside any catalog. Enrichment drawn from the code that generates a table can surface what metadata cannot, such as a table’s grain.

This diagram reorganizes that kind of inventory around what your system must do with each source. Inputs arrive with very different trust levels, and an assembly step in code decides what enters this turn. Keep that step out of the model. The model can request context through tools, but code should attach authority labels, filter by the person’s permissions and resolve conflicts before the text arrives.

Spending the budget, with arithmetic

Take a synthetic warehouse of 2,000 tables averaging 30 columns, at about 25 tokens per column with a short description. Dumping the schema costs roughly 1.5 million tokens before anyone asks anything. Even restricting to one 200-table domain costs about 150,000. An agent using just-in-time retrieval starts with lightweight references and loads detail through tools, which brings a single question to something like the 9,000 tokens shown in the chart.

Two lines in that budget surprise teams. Tool definitions are charged on every turn, and Anthropic gives an example of definitions consuming about 150,000 tokens when many servers are connected. Results are the other. A query that returns 10,000 rows into the conversation has spent the budget on data the model can’t reliably read anyway. Return an aggregate, a row count and a handle, and keep raw rows in the execution layer. Privacy gains too, because rows the model never receives can’t leak through its next response.

Format is a lower priority than teams tend to assume. A 2026 study using SQL generation as its test task ran 9,649 experiments across 11 models and four formats, and found no significant effect of format on aggregate accuracy. It also reported model capability as the largest factor and that splitting schemas by domain let file-based agents navigate up to 10,000 tables. Spend your effort on content and retrieval before arguing about YAML against JSON.

When two pieces of context disagree

Every mature warehouse holds conflicting definitions. A retrieval step that returns both and lets the model pick has made a business decision, differently on each run, with nobody told. Decide the order in advance: an approved definition outranks a person’s own saved definition for shared use, which outranks a standard industry definition, which outranks anything inferred from usage. Inside one level, two meanings that would produce different answers are a conflict to surface to the person.

Keep a distinction between missing and conflicting context. Missing context means the agent should say that it interpreted the term. Conflicting context means there are real alternatives to choose between, so name them. Both differ from the failure where a model averages two definitions into a sentence that sounds right and matches neither.

Compaction has to keep the binding

Long sessions get summarized, and general advice is to preserve decisions and drop raw tool output. For data work, be specific about what counts as a decision. A summary that says "the user is looking at Q3 revenue in EMEA" has lost the definition chosen, the filter as applied, and any exclusions. The next query is then built from a paraphrase, and the number shifts without warning.

Keep the analytic state out of the prose. Hold the chosen definition, filters, period and grain in a structured object that compaction never touches, and let the summary cover the rest. The same discipline applies to memory. Scope it to one person by default, since a remembered filter or customer name is exactly what the next person may not be allowed to see. Our post on conversational analytics architecture works through this state across several turns.

Context is an attack surface and a permission leak

Column comments, wiki pages and text fields all reach the model, and all are writable by people who are not your agent’s developers. OWASP’s description of indirect prompt injection covers exactly this: external content containing instructions that change the model’s behavior. Its mitigations include separating and labeling untrusted content, and limiting what the model can do. No filter here is foolproof, so the durable defense is architectural. Keep permissions out of the model’s hands entirely, so a successful injection still cannot widen what the query returns.

The permission leak is quieter. Check every place where context is precomputed: embedding indexes of values, cached table summaries with examples, query logs retained with literals, shared memory. Ask of each one what identity built it and what identity reads it. If those differ, you have a row-security bypass with a retrieval interface. For query history, keep the shape of the query and strip the values. For value lookup, run it at question time under the person’s own access.

Sub-agents lose meaning at the handoff

Sub-agents are a standard technique for keeping the main context lean: a focused worker explores in a clean window and returns a condensed summary. For data work the summary is the risk. A worker reporting that EMEA revenue fell has dropped the definition, the filters and the identity it ran under, and the lead agent has no way to recover them. Have workers return the number together with its structured frame and a reference to the executed query, so the lead can compare like with like and refuse to combine results built on different definitions.

Prove each source earns its tokens

Vendor charts showing enormous gains from adding context are hard to interpret, so run an ablation on your own system. Take a set of questions with known answers, grade on returned results, and run it repeatedly with one context class removed each time. A published reference point is useful as orientation only: a 2023 benchmark on an insurance schema reported 16 percent accuracy for GPT-4 asked directly over SQL, and 54 percent over a knowledge graph representation. That shows the direction on one domain and one older model, and your numbers will differ.

Track two things besides accuracy: tokens per answered question, and how often the answer names the right definition. A source that adds tokens and moves neither should go, however sensible it sounds. Rerun after each model change, because the same study on formats found that behavior varies across models.

Where you’d see this in Nexatron

Nexatron gives the model tools for catalog search, table context with joins and conventions, value lookup and definitions, and deterministic checks decide whether a proposed query runs. We show authority to the reader as a trust label on each answer: Approved, Team-defined, Standard, Learned or Interpreted, the last one being a reading no person has confirmed. The used and left-out record from the diagram appears in the trust panel, under Definitions used, Filters applied, Answered from, Tables and Not included. You can inspect those on any answer during an evaluation.