Agentic Data Sprawl and How It Breaks Business Metrics

A team walks into a board meeting with a revenue number that one agent computed against the billing table and another computed against the CRM pipeline. Both numbers look authoritative. They differ materially, and nobody in the room can explain why. Agent sprawl is no longer a pilot-phase concern. It is a live condition inside organizations that are already running on agent-generated outputs without realizing those outputs are built on irreconcilable data.

The scale of this condition is now structural. Gartner predicts that by 2028, an average global Fortune 500 enterprise will have over 150,000 agents in use, up from a handful today, an increase of several orders of magnitude in three years. That is not a technology adoption curve. It is a phase change in how business information gets produced and consumed.

Gartner's Max Goss named the resulting exposure directly when he said that ungoverned agents create risks of misinformation, oversharing, and data loss, and only a small minority of organizations believe they have the right governance in place to address it. The framing most teams use, that this is an AI tools problem, misidentifies the risk. The danger is not the agents themselves but what happens to business metrics when many agents each operate on their own private, unreconciled understanding of the business. When a hundred agents each hold a slightly different definition of monthly active users, the organization no longer has a metric. It has a hundred competing answers, all of them confident, none of them reconciled, and every one of them downstream from a decision that someone has already made.

The two-part mechanism: how identity sprawl and context sprawl each corrupt metrics in different ways

Agent sprawl breaks metrics through two compounding failures, not one, and most organizations are only defending against the more visible of the two. Keeping these dimensions distinct matters because the fixes are different, and confusing them guarantees that one remains unaddressed. Identity sprawl is the ungoverned proliferation of agents without lifecycle management, access controls, or audit trails. This is the dimension that most enterprise governance programs now address through registries, scoped permissions, and deprovisioning policies. Platforms including Okta, which frames agents as non-human identities, IBM, and Databricks' Unity Gateway, formerly Unity AI Gateway, have built tooling aimed at this dimension. AWS Agent Registry, part of Amazon Bedrock AgentCore, reached general availability in August 2026, purpose-built for identity-sprawl governance.

Identity governance tells an organization that agents exist and who they are. It does not tell them what those agents know or how they define a business concept. An agent can be perfectly catalogued, with a documented identity and a scoped permission set, and still compute monthly active users against a different table than the agent that ran last week's board report.

Context sprawl, named by Prukalpa Sankar, Co-founder of Atlan, is the second and harder dimension. Agents each build isolated and conflicting understandings of the business, so the same KPI question returns different answers depending on which agent is asked. No identity registry, however mature, resolves this failure. Identity governance tells you which agents exist; context governance tells you whether those agents agree on what the business actually means.

The analogy to BI sprawl is precise and instructive. Every team built its own metrics without a shared semantic layer, resulting in conflicting KPI definitions that took years to untangle. Agent sprawl follows the same root pattern one abstraction layer up, and it is moving faster. Data sprawl multiplies data assets without a governed catalog. BI sprawl multiplies dashboards without a shared semantic layer. Agent sprawl multiplies agents without a shared context layer. It is the same failure, compounding at each level.

Why context sprawl is the dimension that actually breaks the numbers you run on

The metrics crisis created by context sprawl is a definition problem, not a data storage or data freshness problem, and that distinction determines what the fix has to be. When two agents answer the same KPI question using different logic, the result is not an error message that anyone can catch. It is two confident, plausible-looking numbers that quietly diverge.

A stale table in a static report produces a wrong number that somebody eventually notices. A stale or inconsistently defined table read by an agent produces a confident action that nobody reviews. AI analyst agents accelerate this failure because automation is the delivery mechanism, not the source of truth. Automating a broken or inconsistently defined metric produces polished nonsense at speed and at scale.

This is why the strongest objection, that teams can audit agent outputs after the fact, fails. By the time an inconsistency surfaces in a downstream output, it has already shaped a decision. A board number has been presented, a fundraising metric has been shared, an operational choice has been made. Auditing after the fact is reactive. The problem requires a structural fix upstream, because the corruption is invisible at the moment it matters most. Each agent's answer looks authoritative, and no one thinks to question it until two answers collide.

The Atlan framing puts the consequence precisely: if two executives can answer the same KPI question with different logic, the organization does not have a metric. It has a debate topic. Agents do not resolve that debate. They multiply it. The fastest dashboard in the company becomes the least trusted one, because nobody can explain how the number was built or which agent computed it.

Founders and operators without dedicated data teams are most exposed. They rely on agent-generated outputs with no verification layer and no shared semantic layer underneath, so the errors are both harder to detect and more consequential. Board numbers, fundraising metrics, and operational decisions all sit downstream from definitions that no one has ratified. Agents amplify whatever is in the underlying data: messy field names, inconsistent naming conventions, and outdated documentation produce low-trust outputs at higher velocity than any human analyst could.

Why connecting agents to production databases makes context sprawl structurally worse

Giving agents direct access to a production database does not solve the context problem. It embeds it at the connection layer and adds operational risk on top of the definitional chaos. The most common mistake is connecting a source to an agent and governing it afterward. AI retrieval inherits the source's permissions and data quality, so governance and role-based access control have to be in place at the source before anything connects to it.

The scale of this risk is now structural for Supabase teams specifically. More than half of all new Supabase databases are now deployed by AI agents, with Claude Code the single largest source of that traffic, which means AI agent production database access has moved from a hypothetical to a default the tooling already assumes. Supabase has responded with concrete controls: scoped Personal Access Tokens with granular read or read-write permissions per capability, MCP Elicitations requiring explicit confirmation before paid actions or destructive SQL, and Enterprise-Managed Auth for MCP through Okta now generally available. A query_logs MCP tool provides raw SQL log access, and the open-source supabase/agent-skills repository packages official Postgres best practices into a standardized format agents can discover and use, organized across eight impact-prioritized categories.

These are meaningful identity-layer controls. They do not touch the definition layer. An agent with a properly scoped token and an audited identity still computes churn against whichever table it finds first, and that table may not be the one the finance team certifies. Identity governance makes agent access safer. It does not make agent answers consistent.

The architectural failure mode is compounding. A Supabase agent system almost always hits a Postgres connection ceiling or a Realtime channel quota before it hits an LLM rate limit, meaning the database layer is the operational bottleneck, and unmanaged agent access accelerates that ceiling. Each agent querying production directly is not just a governance risk. It is a performance risk that degrades the production application every other user depends on.

MCP has become the dominant pattern for agent-to-data connectivity. By mid-2026, more than 10,000 MCP servers had reportedly been deployed in production. MCP is valuable, and widely adopted, and it does not solve the context problem. It moves data and actions to the agent efficiently. It does not make the data semantically consistent or certifiably correct. An agent connected by MCP to uncertified, ungoverned tables still gets confident wrong answers, faster and at greater scale than before.

The July 2026 MCP specification revision, released on 2026-07-28, made the protocol stateless at the protocol layer, simplifying deployment behind standard load balancers. That is a meaningful operational improvement, and it does nothing to address semantic consistency. MCP does its job well. This is a different job.

What a shared governed data layer actually requires — and what it fixes

The fix for context sprawl is not more governance policies. It is a shared context layer that pre-models business concepts into certified, consistent datasets that every agent queries from the same definitions. The Atlan framing is precise: a governance control plane addresses identity sprawl, and a shared context layer addresses context sprawl. Both are required, because identity governance without semantic consistency still produces divergent metrics. One definition of a metric, shared across every agent and every human stakeholder, is more valuable than any individual dashboard feature or agent capability.

Gartner's six-step framework for managing agent sprawl makes the same point from the institutional side. The framework explicitly includes AI information governance, governing what information an agent can access, keeping data current, managing permissions, and archiving obsolete data, alongside identity and lifecycle management. The data layer is a first-class governance requirement, not an afterthought. Gartner also calls for monitoring and remediating agent behavior through ongoing visibility into agent usage, policy compliance, and detection of agents that exceed their intended scope, which is only possible if there is a reference layer to measure behavior against.

A complete governed data layer has two required control surfaces that must be built together. Agent-layer governance covers identity, permissions, permitted actions, and lifecycle management, the dimension that registries and identity platforms address. Data-layer governance covers certified datasets, semantic consistency, access control, and lineage, the dimension that prevents context sprawl from corrupting metrics in the first place. Building one without the other leaves the failure mode intact.

For Supabase and Postgres teams, the architectural principle follows directly. Postgres is already the operational home. Analytics should extend from there rather than requiring extraction into a separate warehouse, and the governed data layer should live between the production database and any agent, never allowing agents to query production directly.

Pre-modeled, pre-calculated datasets, queryable via DuckDB and exposed through a governed MCP server, let agents get fast, accurate, cheap-to-query context without touching the production connection pool or the raw schema. This pattern resolves the connection exhaustion risk and the semantic inconsistency risk simultaneously. Agents query governed Parquet datasets, not live tables, so neither the application performance nor the metric definitions are at the mercy of which agent asked which question.

Metrics should be calculated ahead of time and pushed to where people and agents work, not pulled on demand by whichever agent happens to remember to check, each using its own query logic. A proactive metrics layer also enables anomaly detection. When a metric drifts, the system surfaces it automatically rather than waiting for an agent or human to notice the divergence in a downstream output.

How to audit your current agent setup for both types of sprawl before they corrupt your numbers further

The audit starts with the question most teams have not yet answered: not how many agents the organization runs, but how many definitions of each core metric those agents collectively operate on. That reframing changes what the audit looks for. The identity sprawl audit establishes the inventory first. Produce a current inventory of every agent running in the environment, including those provisioned by individual teams without central IT visibility. Gartner recommends using AI TRiSM tools to discover and categorize agents across both sanctioned and shadow sources. For each agent, document its identity, its permitted actions, its data access scope, and who owns its lifecycle, including a deprovisioning plan. Treat every agent as a distinct non-human identity with scoped permissions, never as a human user and never on a shared account. Flag any agent with write access to production data as a priority review. Gartner's framework explicitly calls for governing what agents can act on, not only what they can read.

The context sprawl audit is the harder and more consequential half. For each core business metric, revenue, churn, active users, pipeline, whatever the business runs on, ask which table or tables each agent queries to compute it. Ask whether those tables are the same and whether the filters are the same. Divergences here are not configuration errors. They are definition gaps that need to be resolved at the semantic layer before any agent is trusted with a metric that informs a decision.

Knowledge cleanup often improves output quality faster than switching models or adding agents. Standardizing field names, resolving inconsistent naming conventions, and removing outdated documentation that agents may be treating as authoritative addresses the inputs that context sprawl amplifies. The audit that only catalogs agents and stops there has done half the work.

The structural fix that the audit points toward is that governance and role-based access controls must be in place at the data source before anything connects to it, not added afterward as a remediation layer. For Supabase teams, this means the governed data layer sits between production Postgres and any agent, with agents querying pre-modeled, certified datasets rather than live tables. It is the same architecture that resolves both the connection exhaustion risk and the metric definition risk.

Gartner's final step, fostering a culture of responsible AI usage with training and a community of practice, points to a governance truth the audit should surface. Sprawl is not only a technical problem. It is an organizational default that recurs unless ownership is explicit and visible at every level of the team. The measure of a successful audit is not a cleaner registry. It is a team that can answer, for any agent-generated metric, exactly which definition was used and who certified it.