Your AI Doesn't Have a Model Problem.

The modern data stack was rational before AI

The way we built data systems made sense for a long time.

We wanted each product to be excellent at one job. The ingestion tool should be excellent at moving data. The warehouse should be excellent at storing and computing over it. The transformation tool should be excellent at modeling it. The BI tool should be excellent at dashboards. The task manager should track work. Meeting notes and company decisions could live somewhere else.

Specialization gave teams better products and the freedom to choose the best tool in every category. It also gave us a stack that often looks something like this:

Sources → ingestion → warehouse → transformations → metrics → dashboards
                                      ↕                       ↕
                              tasks, docs, and meetings

Every box may be very good at what it does. But the meaning of the data does not live in any one box. It lives in the connections among them.

That fragmentation has consequences for cost and staffing. Every product introduces another bill, another skill set, another permission model, and another system someone must operate. Those are real problems, but they are not the problem I want to focus on here.

The more urgent problem is what this architecture does to AI.

We put an AI inside every box

The first wave of data AI has mostly followed the boundaries of the existing stack.

Your dashboard tool gets an AI assistant. Your transformation tool gets a copilot. Your warehouse gets a natural-language query box. Each can be impressive inside its own product, but each inherits the same hard boundary as the product around it.

Ask the dashboard AI why a number looks wrong and it may explain the chart or generate a new visualization. But it may not know the code that produced the underlying table.

Move to the transformation AI and start again. Now you have to explain which dashboard, which tile, which filters, which metric, and which result you saw. The assistant may understand the model definition, but not the live state of the dashboard. Depending on the product and its permissions, it may not be able to inspect the warehouse data or determine whether the source was refreshed.

So you copy the query. You paste the result. You carry the filter state from one tool to another. You look up the job run, then search the task tracker, then ask in Slack whether anyone remembers a tracking change.

The human becomes the integration layer between a collection of AIs.

That is why so many data copilots feel disappointing even when the underlying model is excellent. They can generate an answer from the context they have. They cannot investigate the context they were never given.

Follow one number all the way down

Consider what an agent actually needs to answer, “Why is this number wrong?”

First, it needs the state of the dashboard in front of you—not merely the dashboard definition. Which tile are you looking at? What date range is selected? Are there page-level, chart-level, or user-level filters? Is the comparison period what you think it is?

Then it needs the metric definition. What does “active customer” actually mean here? Is it a customer who logged in, completed an activity, or paid during the period? Which timezone and attribution rules apply? A query can be technically correct while answering a different question from the one the user intended. This is why semantic systems exist: dbt's MetricFlow, for example, is explicitly designed to define and manage company metric logic instead of letting each analyst recreate it independently (dbt documentation).

Next, the agent needs the transformation logic and lineage. Which models and raw activities produced the metric? What assumptions, joins, exclusions, and identity rules live in the code? Were the transformations successful, and when did they last run?

Then it needs freshness. The latest successful transformation does not prove that the underlying source was current. It may need to trace the data through the warehouse to the ingestion layer and compare the actual update time with the expected service level. Freshness is its own operational concern—dbt, for instance, documents source-freshness checks separately from building and testing models (dbt documentation).

If the pipeline is healthy and the result is still suspicious, the agent needs organizational context. Is there an open task for this issue? Was a tracking change mentioned in last week's meeting? Did someone document an incident, a launch, or a known caveat? Has the business changed the definition but not yet updated the model?

A trustworthy answer may require all of this:

what the user sees
        ↓
dashboard state and filters
        ↓
metric meaning
        ↓
transformation code and lineage
        ↓
job status and data freshness
        ↓
raw warehouse data and source syncs
        ↓
tasks, incidents, decisions, and meeting context

The investigation is not a sequence of isolated questions. Each step changes what the agent should inspect next. That is what makes this agentic work rather than a chatbot answering from documentation.

More context does not mean one enormous prompt

There is an important distinction here.

An agent needs access to the full context of the data system. It does not need the full data system dumped into its context window all at once.

That would be slow, expensive, and often counterproductive. Anthropic's work on context engineering makes the same point: context is a finite resource, and useful agents must curate high-signal information from tools, external data, history, and memory rather than indiscriminately loading everything (Anthropic).

The right architecture gives the agent a map of the system and the ability to investigate it. It should begin with the dashboard state, follow the lineage, inspect definitions and run history, query the live data when needed, and retrieve only the relevant tasks or meeting notes. Context should be available end to end and loaded just in time.

This is not a small implementation detail. It is the difference between an AI that summarizes one screen and an agent that can own an outcome.

The strongest data agents are being built this way

OpenAI recently described its internal data agent, and the architecture is notable because it mirrors this exact problem.

The agent does not rely on warehouse access alone. It combines table metadata and lineage, human annotations, code-level definitions, institutional knowledge from Slack, Google Docs, and Notion, memory from prior corrections, and runtime queries against live systems. OpenAI's team summarizes one of its lessons in four words: “Meaning lives in code.” Schemas show a table's shape; the pipeline logic holds assumptions, business intent, and freshness guarantees (OpenAI).

That is the important pattern. A useful data agent needs both technical context and business context. It must understand not only what a table contains, but how it was produced, whether it is current, what the business means by the metric, and what people already know about the issue.

You cannot get there by adding a chat window to the last tool in the pipeline.

This is why we built Polyform end to end

We learned this first as consultants.

When a client asked us why a number was wrong, we were responsible for the answer. We could not tell them to ask the dashboard vendor, then the transformation vendor, then the person who owned ingestion. We had to trace the problem across the entire system until we found the cause.

Before Polyform, that meant clicking through a long list of tools and manually rebuilding the chain. A question that took ten seconds to ask could consume hours of engineering time.

So we built the environment we needed to deliver the outcome.

Polyform connects the full path from sources to modeled data, metrics, analytics, and AI applications. We organize the system around business activities so definitions and downstream uses share a coherent foundation, instead of scattering meaning across endless one-off tables and marts. That is the basis of our Activity Schema approach.

Because the system is connected, our agent can investigate the way we do. It can see what the user is looking at, inspect the metric, follow the activities and transformations behind it, check processing and source freshness, query the underlying data, and find relevant work already recorded in the system.

It does not merely tell us how we might debug the problem. It can perform the investigation.

The result is not that AI replaces the judgment of a great data team. It is that the team's context becomes operable. The agent can execute the repetitive search across systems in minutes, preserve the chain of evidence, and bring a person a much better starting point for judgment.

“End to end” does not mean every tool must disappear

I do not believe every company must replace every specialized product with one giant application.

The interface can remain modular. Teams will keep using products they love. The necessary change is underneath: there must be one coherent context and action layer with access to the state, definitions, lineage, freshness, data, and organizational knowledge required to complete the work.

Integrations alone are not enough if they expose disconnected actions without shared meaning. A catalog of hundreds of tools can create a new form of fragmentation inside the agent. The system needs consistent concepts, discoverable relationships, clear permissions, and a way to follow one business question across every layer.

For Polyform, owning the platform end to end lets us create that coherence and be accountable for the result. It means a dashboard is not an isolated artifact. It remains connected to the metric, the activities, the processing state, the source data, and the work around it.

That connection is what makes the AI useful.

The next data platform will be judged by what its agent can understand

In the pre-AI era, it was reasonable to evaluate each data product on how well it performed its specialized function.

In the AI era, we also have to evaluate the whole system on whether an agent can understand and operate across it.

Can it see what the user sees? Can it understand what the metric means? Can it follow the code and lineage? Can it verify freshness? Can it inspect the live data? Can it recover the decision or incident that explains the anomaly? Can it take the next step instead of telling a person where to click?

If the answer is no, a better model will not solve the fundamental problem. The agent is still trapped inside one box while the truth is spread across ten.