An executive dashboard can be wrong and still leave room for human judgment. An AI agent acting on bad context may send the wrong customer email, escalate the wrong account, or recommend the wrong renewal strategy before anyone notices.
That is the core maintenance challenge emerging for data teams: we are no longer modeling data only for people reading charts. We are modeling business context for software systems that can reason, decide, and act.
Context and background: analytics engineering is evolving
For the last decade, analytics engineering has helped organizations make data more trustworthy, usable, and governed. Tools like dbt popularized a practical discipline around version-controlled transformations, modular SQL, tests, documentation, lineage, and collaboration between data producers and consumers.
The primary user experience, however, was often a dashboard. The goal was to produce accurate metrics, well-structured marts, and clean reporting layers so business users could inspect performance and make decisions.
That model is not going away. Dashboards still matter. But the rise of AI agents introduces a new type of consumer: software that needs structured, governed, and explainable context to perform work on behalf of humans.
In dbt’s blog post, “From analytics engineer to context engineer,” the company frames this as a shift from modeling data for dashboards to modeling context for agents. The post is also the first in a series on this transition and starts with dbt’s own Gong data, a practical example because sales conversations are rich with messy, business-critical context.
That example is important. Gong data is not just rows and columns. It includes calls, transcripts, topics, objections, deal signals, customer sentiment, stakeholders, and timing. For a dashboard, you may summarize this into call counts, talk ratios, or pipeline influence. For an agent, the question becomes more nuanced: What does this conversation mean, what should happen next, and can we trust the context enough to automate an action?
From analytics engineering to context engineering
Analytics engineering gave teams a foundation for reliable data products. Context engineering extends that foundation so machines can use business knowledge safely.
A dashboard might answer:
- How many sales calls happened last week?
- Which reps had the most customer engagement?
- What percentage of late-stage deals mentioned pricing concerns?
An agent needs something closer to:
- Which open opportunities show signs of procurement risk?
- Which customer objections are unresolved?
- What follow-up should the account team send, and why?
- Which data sources support this recommendation?
- Is this action allowed under policy and ownership rules?
That difference changes how teams think about models. A metric is no longer just a number with a definition. It becomes part of an operational context graph that includes entities, relationships, policies, lineage, freshness, quality, and permissions.
Dashboards tolerate ambiguity better than agents do
Human dashboard users bring their own context. If a chart looks strange, a sales leader may ask follow-up questions, check the CRM, or message the data team. Humans can recognize that “customer health” means something different in enterprise accounts than in self-serve accounts.
Agents do not automatically have that judgment. If “active customer” is defined differently across systems, an agent may use the wrong definition. If a field is stale, it may still look authoritative. If a semantic layer contains outdated ownership rules, an agent may recommend an action to the wrong team.
This is why context engineering raises the maintenance bar. Bad data in dashboards creates bad reporting. Bad context in agent workflows can create bad operations.
What makes data agent-ready?
Agent-ready data platforms require more than access to a warehouse and a few well-modeled tables. They need durable engineering practices that make business context explicit, testable, and maintainable.
1. Strong data contracts
Data contracts define expectations between producers and consumers: schemas, meanings, freshness, quality thresholds, and change management rules. For dashboards, a broken contract may cause a failed report. For agents, a broken contract can cause an incorrect workflow.
If an agent relies on opportunity stage, renewal date, or customer tier, those fields need stable definitions and predictable behavior. A producer should not rename, repurpose, or backfill fields without a managed upgrade path.
Modernization takeaway: treat data contracts like API contracts. Version them, test them, and communicate breaking changes before they reach production agents.
2. A governed semantic layer
A semantic layer helps standardize business concepts such as revenue, churn, active users, account owner, and pipeline stage. In the dashboard era, semantic layers reduced metric sprawl. In the agent era, they reduce reasoning sprawl.
If multiple agents use different definitions of “high-value customer,” the organization can end up automating inconsistent experiences. A support agent, sales agent, and finance agent should not each infer business meaning from raw tables independently.
A governed semantic layer gives agents a shared vocabulary. It also gives humans a place to inspect and manage the assumptions behind automated decisions.
3. Lineage and explainability
Agents need to explain where their context came from. If a system recommends escalating an account, engineers and business owners should be able to trace the recommendation back through source systems, transformations, models, and policies.
Lineage is not just a debugging feature. It is an accountability feature.
When context is derived from Gong transcripts, CRM fields, product usage, and support tickets, lineage helps answer questions such as:
- Which source contributed this signal?
- When was it last updated?
- Which transformation classified the risk?
- Who owns the model?
- What downstream workflows depend on it?
For CTOs, this becomes a governance and risk management requirement. For developers, it becomes a practical requirement for maintaining complex systems.
4. Testing beyond schema validation
Traditional data tests often check for nulls, uniqueness, accepted values, and referential integrity. Those are still essential, but context engineering requires additional tests around business logic and operational readiness.
Examples include:
- Does every recommended account action include a valid owner?
- Are risk labels refreshed within an acceptable time window?
- Are sensitive fields excluded from agent-accessible models?
- Do classification rules behave consistently across customer segments?
- Are deprecated fields blocked from new agent workflows?
The key is to test the assumptions agents rely on, not only the shape of the data.
5. Clear ownership
Agent-ready context needs owners. Not vague ownership, but explicit accountability for definitions, models, source reliability, and approval policies.
When an agent makes a poor recommendation, the team needs to know whether the issue came from a source system, transformation logic, semantic definition, prompt configuration, permissions, or downstream integration. Without ownership, every incident becomes a cross-functional investigation with no clear resolution path.
Maintenance takeaway: assign owners to context domains such as customer, account, product usage, revenue, support, and sales engagement. Then map those domains to the models and workflows that depend on them.
Why Gong data is a useful starting point
The dbt article’s use of Gong data is a strong example because conversation intelligence sits at the boundary between structured and unstructured data. Sales calls contain valuable signals, but those signals need interpretation before they can support automated workflows.
A dashboard can summarize Gong activity. An agent may need to interpret it in context:
- A prospect mentioned budget concerns, but was it a blocker or a negotiation tactic?
- A competitor came up, but was the customer comparing features or signaling intent to switch?
- A decision-maker joined the call, but does the CRM reflect that stakeholder?
- A next step was discussed, but was it captured as a task?
To answer those questions reliably, teams need models that connect transcripts, CRM entities, opportunity stages, account ownership, and business rules. This is context engineering in practice: not just transforming data, but maintaining the meaning required for action.
Practical implications for engineering teams
For developers, engineers, and CTOs, the shift to context engineering should feel familiar. It mirrors lessons software teams already learned from API design, service ownership, CI/CD, observability, and platform engineering.
Modernize data models like production software
If agents depend on a data model, that model is production infrastructure. It should have code review, automated tests, deployment environments, rollback strategies, documentation, and monitoring.
Data teams can borrow heavily from software engineering practices:
- Use version control for transformations and semantic definitions.
- Require reviews for changes to agent-facing models.
- Create staging environments for context changes.
- Monitor freshness, anomalies, and downstream usage.
- Deprecate fields with migration windows instead of abrupt removal.
This is where platforms like Vibgrate focus the modernization conversation: legacy data assets, brittle pipelines, and undocumented business logic become more expensive when agents depend on them. Modernization is no longer only about efficiency. It is about operational safety.
Build an agent-readiness checklist
Before connecting agents to a data domain, teams should ask:
- Are the core entities and metrics clearly defined?
- Is there a semantic layer or equivalent source of truth?
- Are data contracts in place with upstream systems?
- Do we have lineage from source to agent-facing output?
- Are quality and freshness tests automated?
- Is ownership documented and current?
- Are sensitive fields governed by policy?
- Can we explain why an agent received a given context?
If the answer is no, the domain may not be ready for automated action. It may still be useful for human-in-the-loop assistance, but not full automation.
Treat context drift as technical debt
Business context changes constantly. Sales stages evolve. Product packaging changes. Customer segments are redefined. Compliance policies shift. New source systems appear.
When these changes are not reflected in data models, semantic layers, and contracts, context drift accumulates. Dashboards become confusing. Agents become risky.
Engineering leaders should treat context drift as a form of technical debt. It needs backlog visibility, prioritization, ownership, and remediation. Otherwise, teams will spend more time debugging agent behavior than delivering value.
Conclusion: the next platform layer is trusted context
The move from analytics engineering to context engineering is not a rejection of dashboards or BI. It is an expansion of the data team’s responsibility. The same models that once informed decisions may now power systems that take action.
As dbt’s series begins with Gong data, the broader lesson is clear: every organization will need to decide which business context is reliable enough for agents and which legacy assumptions need modernization first.
For engineering teams, the path forward is practical. Strengthen contracts. Govern semantics. Invest in lineage. Test business logic. Clarify ownership. Modernize the data models that agents will depend on before those agents become operationally critical.
The organizations that do this well will not simply have better dashboards. They will have a trusted context layer for the next generation of software automation.