Context Window Data Delivery for AI Agents

An AI agent fails to answer a business question correctly far less often because its context window ran out of room than because the context it received was wrong before a single token entered the window. The instinct to expand token limits or tune retrieval treats the symptom. The defect sits upstream, in data that was never modeled, governed, or reconciled. So getting trustworthy data into an agent's context window is an upstream data modeling problem, not a runtime token problem.

Why context window failures are upstream data problems, not runtime token problems

Say an agent has to compute net revenue retention for mid-market accounts. Before it can reason about the question, it must discover what tables exist, sample rows to infer column meanings, resolve what "mid-market" means in this particular database, and test join logic against live schema. Four categories compete for that budget at every inference step: fixed overhead from system instructions and tool definitions, retrieved context such as schema and documentation, tool output that is often verbose JSON, and the accumulated conversation history. All four categories are re-read at every subsequent step, so an early error gets reinforced rather than corrected.

The failure mode that matters in enterprise deployments is semantic conflict, not token overflow. Finance's "customer" and Sales' "customer" are frequently not the same entity. If those definitions have not been reconciled before retrieval, no runtime pruning technique can fix the answer. Expanding the window does not repair this condition. It enlarges the surface over which bad data can do damage.

The implication is architectural. The question of whether an agent's context is correct cannot be answered at inference time, because correctness was determined, or not determined, before retrieval began. What the agent retrieves must be pre-modeled and definition-consistent before it reaches the window.

What a context store is and why it is architecturally distinct from the context window

The context window and the context store are architectural complements that serve different functions, and conflating them is the mistake that makes runtime techniques seem sufficient when they are not. Atlan's 2026 guide defines the distinction precisely: the context window is the agent's active reasoning workspace at inference time, while the context store is the persistent infrastructure that populates it with validated, governed content. The window is ephemeral and bounded by tokens. The store is persistent and bounded by governance, meaning what has been certified, versioned, and permissioned for agent access.

Runtime techniques such as compaction, trimming, and summarization operate entirely on the window side. But that table counted expansion revenue differently than the finance team's definition. The wrong definition is now locked in as settled fact, and the two tables that would have revealed the ambiguity are gone from the window. Once compaction has summarized over a definitional error, no recovery path exists at runtime. The error is baked into the agent's working state.

This is why a context store must be engineered as persistent, governed infrastructure separate from the ephemeral window. That separation is the layer where platforms like Dreambase operate, serving validated datasets via MCP so agents access certified metrics and modeled data rather than raw schema exploration or contradictory source tables. Atlan's context architecture guide identifies five: system context, session context, memory, artifacts, and on-demand context retrieved via RAG or MCP. The design goal is high-signal, low-noise context at every step. Atlan's guide cites Stanford's "Lost in the Middle" finding that language models consistently underperform when relevant information sits in the middle of long contexts, regardless of window size.

How pre-modeled, pre-calculated datasets solve the problems runtime retrieval cannot

Pre-modeled, pre-calculated datasets are the correct unit of context delivery because they eliminate discovery overhead, enforce definition consistency, and make agent outputs reproducible. When the data an agent retrieves is already a modeled dataset with metric definitions locked, transformations applied, and schema documented, the agent skips the discovery phase entirely and moves directly to reasoning. The NRR problem does not arise when "NRR for mid-market accounts" is a pre-calculated field in a governed dataset. The definition of "mid-market," the revenue counting convention, and the time-period scope were resolved at modeling time, not at query time.

Cost efficiency reinforces the argument. The deeper advantage is reproducibility. Atlan's 2026 guide contrasts the two patterns directly: ad-hoc context assembly produces unknown freshness and non-reproducible runs, while governed context delivery produces freshness-stamped, versioned context products with reproducible outputs across runs. Reproducibility is what makes agent behavior auditable.

The standard objection is that retrieval-augmented generation over well-documented raw tables can achieve the same result. It cannot, because RAG retrieves the most semantically similar content, not necessarily the correct or current definition. If two tables define the same metric differently and both are in the index, RAG may surface the wrong one with high confidence. Pre-modeling collapses ambiguity before retrieval. You build trust into the context store by pre-calculating and versioning datasets before agents ever query them, which eliminates the discovery work that consumes most of an agent's context budget. This is the inverse of on-demand retrieval and the foundation of what Dreambase calls a governed analytics layer: data that is already modeled, definition-locked, and ready to serve both human reasoning and agentic workflows.

Definition consistency is what separates a context store from a search index over raw documentation. A search index retrieves text that describes metrics. A governed dataset embeds the metric's definition into its structure. The field is the definition, not a description of it. Versioned datasets extend this property across time. Starburst's post on agentic AI infrastructure documents the stakes: the same foundation model moves from roughly half accuracy on enterprise questions to more than nine-tenths accuracy once it receives structured business context. The context quality changed.

MCP as the delivery mechanism between the context store and the agent

MCP's role is transport and permissioning, not data quality. It delivers what the context store contains, which means a well-designed MCP deployment is only as trustworthy as the data it is connected to. MCP enforces structured, permissioned access so that only pre-approved metrics, reports, or fields are exposed. That is a meaningful governance property, but it moves data and actions to the agent without making the data correct. An agent connected by MCP to uncertified tables still gets confident wrong answers. The semantic layer is what makes MCP trustworthy. MCP is not a substitute for it.

MCP's July 2026 stateless revision changed the infrastructure requirements for production deployments. The official MCP blog post dated July 28, 2026 describes a stateless protocol core transforming MCP from a bidirectional stateful protocol into a request/response stateless protocol, and Microsoft's.NET Blog confirms that sticky sessions and shared session stores that horizontal deployments needed are no longer required at the protocol layer. This makes horizontally scalable MCP deployments straightforward on ordinary HTTP infrastructure. DBHub's Postgres MCP review documents this concretely for Supabase MCP configurations.

Prompt injection is a documented, vendor-acknowledged risk in MCP-connected systems, and runtime mitigations alone do not resolve it. In 2025, attackers exfiltrated data through malicious instructions in support tickets that an agent read with elevated privileges. The structural defense is pre-approved, permissioned datasets. If the agent can only retrieve from a governed set of pre-modeled outputs, the attack surface for injection through retrieved content is dramatically smaller than if the agent has open query access to raw tables. Access restriction at the data layer is the primary defense. MCP permission configuration is the second layer, not the first.

Why agents querying production Postgres databases directly undermines everything the data layer is supposed to provide

Direct agent access to a production Postgres database is not an analytics architecture. It is an absence of one, and it exposes both data integrity and query performance to risks that no runtime technique can contain. Production databases are optimized for transactional workloads with concurrent reads and writes and row-level locking. The SQL injection incident documented in the research, where an autonomous agent gained full read-write access to a production database, began with unauthenticated API endpoints and required no sophisticated attack on the agent itself.

The safe access patterns are not optional. Gateway-mediated access with centralized permission enforcement and access logging is the starting point. Read replicas serve analytical queries. Service accounts hold least privilege. Isolated contexts test transformations before they touch production data. Supabase's own tooling reflects this. The official MCP connector lets an AI client work with a Supabase project in plain language, with Claude writing the SQL, running it, and reading the answer back. PostgreSQL row-level security provides tenant isolation at the database layer. Combined with a stateless MCP server and read-only mode, this architecture keeps the agent horizontally scalable without opening production to uncontrolled access.

The semantic conflict problem, where Finance's "customer" and Sales' "customer" mean different things, is precisely why governed data infrastructure matters before retrieval ever begins. Dreambase addresses this by pre-modeling datasets with locked, versioned definitions into a shared data layer. Agents retrieve against datasets where the definition has already been resolved, not raw tables where ambiguity still lives.

Building the single source of truth that both humans and agents can consume from the same definitions

The single source of truth problem is definitional before it is technical. If "MRR" means booked subscriptions in one dashboard and recognized revenue in another, the failure is that the organization never agreed on the definition, and no amount of tooling resolves that upstream disagreement. Once a field is the definition rather than a description of it, every agent and every human consuming that field gets the same answer.

The operator's path to this is concrete and bounded. Start with the three to five most critical data sources and validate that data is flowing correctly and reconciles to the source of truth. Then define and certify core KPIs in the semantic layer. Then connect to live data rather than manual exports. A dashboard that shows last week's numbers because someone forgot to update a CSV creates false confidence and corrupts agent context with stale figures. dbt's MetricFlow metric definitions, dbt schema contracts, and column-level lineage, whether via dbt Explorer or third-party tools, are one established pattern for embedding the semantic layer into the data stack. An analytics engineer who structures this context well is directly improving the reliability of every AI agent that runs against the stack.

Metrics that are pre-calculated and pushed to where people work, rather than pulled on demand by whoever remembers to check, create the conditions for humans and agents to operate on the same numbers simultaneously. An agent that retrieves a metric from a pre-calculated, freshness-stamped dataset and a human who reads the same metric in their inbox are consuming the same computation. Push architectures calculate once and distribute, so the metric is the same for every consumer at every moment. That is what one definition of a metric shared across every stakeholder means operationally: not a governance document, but a pre-calculated dataset that is the metric, serving as the retrieval target for both human dashboards and agent context windows.

What governed, headless analytics infrastructure looks like for a team running on Supabase without a data team

A team running on Supabase already has Postgres as its analytical home. The architecture for trustworthy agent context extends from there without requiring a separate data warehouse, ETL pipelines, or a data team to operate them. Postgres is already storing the business's transactions, user events, and application state. The gap is not data storage but data modeling, meaning the pre-calculation, definition enforcement, and governance layer that transforms raw Postgres rows into context-ready datasets. A separate data warehouse introduces the ETL problem: data is extracted, transformed, and loaded on a schedule, so every analytical surface works from a copy that is at least as stale as the last sync. For agent context, staleness is indistinguishable from incorrectness.

Extending Postgres into analytics in place, using governed Parquet datasets queryable via DuckDB and exposed through a single MCP server, gives agents fast, cheap, accurate-to-query context without adding infrastructure to manage or credentials to secure separately. It acts as the governed data layer between a Supabase Postgres project and any AI agent or human consumer, pre-modeling metrics into versioned datasets, enforcing definitions, and exposing everything through a single MCP server. Agents never touch production, but they still receive the structured business context that moves accuracy from roughly half to more than nine-tenths.

Headless analytics is data infrastructure that is decoupled from any single front end and accessible via MCP or API, so one governed layer serves both human dashboards and agent context windows simultaneously. The data modeling and governance layer is decoupled from the presentation layer, so the same pre-calculated, definition-consistent datasets can be consumed by a dashboard, a Slack alert, a board report, and an AI agent's context window without being recalculated or redefined for each consumer. For a team without a data team, this architecture delivers trustworthy, board-ready numbers and trustworthy agent context from the same infrastructure, governed by the same metric definitions, maintained by the same people who run the product.