Beyond the Semantic Layer: Context Engineering for Business Teams

The semantic layer solves one kind of context. AI needs another.

In the previous article, I argued that the next shift in BI is from people asking data questions to data that can speak first. Once AI starts the interaction, it needs two answers before it can be useful: what is true, and what matters now.

The first is the problem semantic layers are built to solve. What does revenue mean? Which customer table is authoritative? How should churn be calculated? Those definitions should be shared, governed, and stable enough that every person and every agent works from the same reality.

But an agent that knows the correct definition of revenue still does not know whether a 7% decline matters this week, whether enterprise pipeline outranks MQL volume this quarter, or whether a usage drop should be escalated because a renewal is approaching. That is a different kind of context.

The reliability problem is already visible. In an August 2026 follow-up to its Pulse research, VentureBeat reported that 68% of enterprises had traced a confident but wrong AI-agent answer to missing or inconsistent business context, up from 57% in the prior survey. The answer is not to weaken the semantic layer. It is to be explicit about what the semantic layer should govern, and what should stay closer to the teams running the business.

That is the argument of this essay: data teams should govern the context that tells AI what is true. Business teams should maintain the fast-changing context that tells AI what matters now.

Two contexts, two owners

The word "context" hides two very different things.

The first is the context AI needs to understand the business correctly: what "revenue" means, how a customer is identified, which table is authoritative, how the data joins, what grain it lives at, where it came from, and who is allowed to see it. This context is shared across the company, relatively durable, and costly to get wrong. For clarity, I will call it canonical context.

The second is the context AI needs to know what matters right now: this quarter's priorities, the segments a team is watching, what counts as a meaningful drop, which exceptions to ignore, and who should be told when something breaks. This context is team-specific, fast-changing, and lives closest to whoever owns the KPI. I will call it decision context.

The one-sentence version:

Data teams provide the context AI needs to understand the business. Business teams provide the context AI needs to know what matters right now.

This is where the semantic layer stops being sufficient on its own. It should govern the shared meaning agents use to know what is true. But it cannot encode every team's fast-changing judgment about what matters now. That second job belongs to context engineering closer to the business outcome.

These two contexts move at different speeds and carry different risks. They should not be owned or updated in the same way.

The semantic layer should govern what is true

Nothing in this argument weakens the case for governed semantics. If anything, proactive AI raises the stakes.

A governed semantic layer can define shared business meaning centrally, with lineage, tests, and access controls, so every consumer, whether human or agent, works from the same definitions. It is the foundation this design pattern stands on, not an opponent of it.

An AI that monitors the business on a team's behalf must inherit definitions, not reinvent them. If ten teams' agents each compute "churn" differently, proactive BI doesn't just fail. It manufactures confident, conflicting signals at scale. Centralized, governed, shared meaning is what makes autonomous monitoring trustworthy in the first place.

Context engineering for what matters now belongs close to the business

Decision context behaves differently. It changes with quarters, campaigns, and reorganizations, not with schema migrations.

Marketing pivots from MQL volume to enterprise pipeline conversion mid-quarter. Customer success decides that renewal risk in one segment now outranks everything else. Sales starts caring about a region that didn't exist on last quarter's map. None of this belongs in a semantic layer, and none of it should. It is not a definition. It's a judgment about what deserves attention right now.

Today this context lives in team leads' heads, planning docs, chat threads, customer conversations, and standups. It is valid this week and stale next month. Any system that requires it to pass through another team's queue before AI can act on it will always be reasoning from last quarter's priorities.

The market is beginning to expose how broad this context really is. TechCrunch reported in June that Jedify raised $24 million to build context graphs spanning databases and BI tools, but also documentation, Slack, meeting recordings, workflows, operational assumptions, and company-specific terminology. A month later, TechCrunch reported that Encore AI raised $30 million after growing ARR more than fivefold since its seed round; its agents learn from the playbooks embedded in real customer interactions. These are different products, but they point to the same shift: useful agent context increasingly comes from how the business actually operates, not only from the data model.

Context transfer becomes the bottleneck

AI is rapidly reducing the cost of implementation. Writing SQL, building a dashboard, and standing up a monitor are becoming much cheaper. What AI does not remove is the cost of coordination: explaining what you actually need to another team, waiting for it to be interpreted, checking whether the result matches your intent, and re-explaining when it does not.

When implementation was expensive, that transfer cost was easy to ignore inside a multi-day request. As build time falls, the translation and handoff become a larger share of the work. The bottleneck moves.

To be precise about where the risk sits: definitions don't need to change weekly, so routing them through central governance costs little. The backlog problem appears specifically when fast-changing decision context must be re-implemented through the data team every time it changes.

Which suggests an inversion. Instead of shipping business context to the data team so it can be implemented near the data, ship the AI to the business team so it can be instructed near the context.

The team that owns the outcome should also own the context AI uses to reason about that outcome.

Ownership here means authoring and maintenance responsibility. It does not mean team-local storage, shadow pipelines, or bypassing governance. Decision context can, and often should, live on shared, governed infrastructure. The point is who keeps it true.

Users should do less data work, not more

This can sound like another version of self-service BI. It is closer to the opposite.

Self-service BI often asked business users to do more data work themselves: learn the tool, build the chart, maybe touch SQL. For many teams, that was a mismatch. Data work was never their job.

AI-native BI inverts the direction. Business users provide business judgment. AI compiles it into data work. A marketing manager should never write SQL. What they should express is exactly what only they know:

• This quarter, enterprise pipeline is what matters.
• For this campaign, watch pipeline conversion, not MQL count.
• If it drops more than 20%, tell me.

The AI translates that intent into governed queries against shared definitions, monitoring schedules, and investigation procedures. The human contribution moves up the stack, from operating tools to declaring intent.

The architecture: governed meaning, business-owned intent

Put the pieces together and a design pattern emerges:

Centralize shared meaning. Decentralize decision-context authoring. Automate attention.

Or shorter: Centralize understanding. Decentralize intent.

The wrong way to draw this is as one long pipeline, where decision context is just another transformation stage and every tool is an equally weighted box in a row. That picture makes the most important part invisible. Read it instead as two inputs meeting in a runtime:

Trusted Data Foundation + Team-authored Decision Context → Proactive BI Runtime → Evidence-backed Signal → Human Decision

• Trusted Data Foundation: This treats the Modern Data Stack as one foundation: ingestion, warehouse, transformation, canonical semantics, and access policy. It answers what is true, and it stays governed centrally.
• Team-authored Decision Context: This is not the next stage of the pipeline, but a control plane entering the runtime in parallel with the data. It answers what matters now: goals, priority segments, thresholds, exceptions, hypotheses, and escalation paths. KPI owners author it and keep it current.
• Proactive BI Runtime: AI compiles that context into recurring monitoring and investigation against governed data.
• Evidence-backed Signal: The runtime delivers a claim that carries a path back to its evidence, not a bare alert.
• Human Decision: Attention is finally spent on judgment, not on scanning.
• Feedback: Decisions, corrections, and outcomes flow back into the decision context, keeping it current.

Governed team autonomy is the operating rule. Teams inherit canonical metrics and access policies from the foundation; team-level connections and reusable queries give a team a trusted foundation at its own scale. They are not a replacement for organization-wide semantics. What teams author is judgment, not definitions. And cross-cutting rails still run through everything: identity and access, provenance, versioning, freshness, approval, audit. Decentralized authoring without these is just chaos with better branding.

Domain ownership of context is not new. Data mesh made it a founding principle, and Palantir's ontology shows deeply centralized operational context working at serious scale. Both are serious precedents, not strawmen; the pattern above is not novel because it decentralizes something.

What has changed is feasibility. AI now makes team-authored decision context executable without teams running their own infrastructure: expressed in business language, compiled into governed operations, and auditable end to end. The differentiation is not any single ingredient. It is the loop: governed facts, team-authored decision context, executable monitoring, evidence, and feedback operating as one system.

One agent should create the analysis and keep watching it

In AI-native BI, creating an analysis and monitoring it should not become two separate jobs. The same AI agent should carry the purpose of the work from creation into ongoing monitoring and delivery.

First, the agent turns a team's judgment into concrete work: queries, dashboards, and reports that can be inspected. Then the same agent watches that work on a schedule and, when something important changes, delivers the finding in a format and channel the recipient already uses. Because creation and monitoring share the same context, the reason the analysis was built and the reason a particular finding was sent do not drift apart.

Consider churn monitoring. A customer success lead may want to focus on customers whose renewal is within 90 days, product usage has fallen more than 30%, and support sentiment is deteriorating. The agent can connect that judgment to governed customer, usage, and support data, create the analysis and dashboard, and continue watching for accounts that match those conditions. When it finds one, it can deliver a report that shows who needs attention and what evidence triggered the finding.

Delivery should be the beginning of the investigation, not the end. From the report or the agent thread, the recipient should be able to ask a follow-up question, inspect the dashboard, open the underlying query, and return to the source data. If the signal is noisy, the team can adjust the threshold. If a segment no longer matters, the team can remove it. The same context continues from the original request into the follow-up.

This also keeps operating judgment inside the company. When an experienced lead leaves, the reasoning does not have to leave with them. Another team can understand not only what was monitored, but why.

Figure: The same AI agent creates the analysis, keeps watching it, delivers the finding, and stays available for deeper investigation.

What this looks like in Squadbase

You can assemble a similar workflow from multiple products. But technical possibility is not the same as an experience that a business team can use every day.

A data team may be able to maintain separate systems for metrics, alerts, notebooks, scheduling, delivery, and documentation. Marketing, sales, and customer success teams have a different job. They cannot spend their time learning which product holds a monitoring condition, where a report must be changed, how a failed schedule is repaired, or where the evidence behind an alert lives. If every change requires that knowledge, KPI teams will hand the work back to the data team, and the same context-transfer bottleneck returns.

Squadbase is designed around a simpler experience. Inside the same project, the same AI agent can create and revise the queries, dashboards, and reports, monitor them on a recurring schedule, and deliver findings by email or Slack. The agent's work remains in a thread, so a recipient can move from the delivered report into a follow-up investigation and then to the dashboard, query, and data behind the conclusion.

Figure: A delivered report opens into the same Squadbase project, where the recipient can continue in the agent thread and inspect the dashboard, query, and data behind it.

The important difference is not that many tools have been placed in one screen. It is that one agent carries the same purpose and evidence through creation, monitoring, delivery, and deeper investigation.

This keeps the user's job simple: explain what matters, review the analysis, receive the insight in a useful format, and go deeper when needed. The team does not have to operate a data-tool stack to own its judgment.

This is the model Squadbase is designed for. Data teams can keep shared definitions and trusted data reliable. KPI teams can keep current priorities close to the people who own the outcome. Squadbase connects those priorities to analysis that is created, monitored, delivered, and investigated in one continuous experience.

Centralize understanding. Decentralize intent. Automate attention.

The semantic layer gives AI a governed understanding of what the business means. Context engineering for business teams keeps current what the business cares about now. AI data agents need both.

Context should live where the KPI lives.