AI agents are only as useful as the data they can safely use. If an agent is expected to answer business questions, trigger workflows, recommend code changes, or automate operational decisions, the real question becomes: can it trust the data plane underneath it?
That is why the completed merger of Fivetran and dbt Labs matters beyond the data engineering world. As announced in the dbt Blog post, “Fivetran + dbt Labs Complete Merger to Create the Data Infrastructure for Trusted AI Agents”, the combined company is explicitly framing its mission around building the data foundation for the agentic AI era. For developers, platform teams, and CTOs, this is a signal that data pipelines are becoming a control plane for AI-enabled software and business operations.
The merger is about more than vendor consolidation
Fivetran and dbt Labs occupy two critical parts of the modern data stack. Fivetran is widely known for automated data movement and ingestion: extracting data from operational systems, SaaS tools, databases, and event sources into analytical platforms. dbt Labs is closely associated with analytics engineering: transforming raw data into modeled, tested, documented, and reusable datasets.
The merger brings ingestion and transformation closer together under one organizational umbrella. That alone is significant, but the strategic framing is even more important. The announcement positions the combined company as building data infrastructure for trusted AI agents, not just dashboards, warehouses, or analytics teams.
That framing reflects a broader shift. In the last decade, data pipelines mostly served human consumers: analysts, executives, finance teams, product managers, and customer success leaders. Today, those pipelines increasingly serve software consumers as well: AI agents, copilots, automation systems, retrieval-augmented generation pipelines, and decision engines.
When software begins acting on data instead of merely displaying it, the standards change. Stale data, undocumented transformations, duplicated metrics, and unclear lineage are no longer just reporting annoyances. They become automation risks.
Why agentic AI raises the bar for trusted data
Traditional analytics workflows are relatively forgiving. If a dashboard shows a strange number, a human analyst can pause, investigate, and ask follow-up questions. In an agentic workflow, the system may summarize the number, recommend a course of action, create a ticket, update a customer record, or trigger another process.
That makes trust boundaries more important.
An AI agent needs to know not only what data is available, but also whether that data is complete, current, governed, and appropriate for the task. It needs context about definitions, joins, ownership, freshness, and lineage. Without that context, agents can amplify the same data quality issues that already frustrate analytics teams.
Common examples include:
- A revenue agent using a deprecated bookings table because it still exists in the warehouse
- A support automation workflow relying on stale customer health scores
- An engineering productivity assistant misinterpreting issue tracker fields because custom workflows are undocumented
- A finance agent combining actuals and forecasts without understanding transformation logic
- A product analytics agent recommending roadmap changes from incomplete event data
These are not model problems alone. They are data maintenance problems.
Data technical debt becomes AI technical debt
Many organizations already carry significant data technical debt: inconsistent ingestion patterns, one-off scripts, unclear ownership, fragile transformations, duplicated metrics, undocumented business logic, and manual quality checks. Before AI agents, that debt often surfaced as slow reporting cycles or stakeholder mistrust.
In agentic systems, the same debt becomes operational risk.
If an agent is connected to a messy data environment, it can produce confident but unreliable answers. Worse, it may take action based on those answers. This is why the Fivetran and dbt Labs merger lands at an important moment. The combined emphasis on ingestion and transformation maps directly to the maintenance work teams must do before they can safely expand AI-assisted workflows.
Modernization is not just about migrating to a newer warehouse or adopting a new orchestration tool. It is about making data assets reliable enough to be consumed by both humans and machines.
That requires engineering discipline across the full lifecycle:
- Standardized data ingestion
- Version-controlled transformations
- Automated testing and validation
- Clear lineage from source to model to consumer
- Documented ownership and definitions
- Observability around freshness, volume, schema, and quality
- Deprecation strategies for outdated models and metrics
In other words, the future of AI agents depends on many of the same practices that software teams already apply to maintainable application code.
Pipelines as the control plane for AI agents
A control plane is where policies, routing, configuration, permissions, and operational decisions are coordinated. In cloud infrastructure, the control plane determines how resources are provisioned and managed. In Kubernetes, it coordinates desired state. For AI agents, data pipelines increasingly play a similar role.
They determine what an agent can see, how information is shaped, which definitions are trusted, and whether outputs are grounded in governed datasets.
This does not mean every agent needs direct access to a warehouse. In many cases, agents will interact through semantic layers, APIs, vector indexes, feature stores, or application services. But all of those interfaces still depend on upstream data pipelines being correct and maintainable.
The ingestion layer defines what enters the analytical ecosystem. The transformation layer defines what that data means. The lineage layer explains where it came from and how it changed. The quality layer determines whether it is safe to use. Together, these layers become the practical boundary between useful automation and unreliable automation.
That is the deeper implication of bringing Fivetran-style ingestion and dbt-style transformation together around trusted AI agents.
Lineage is no longer just for debugging dashboards
Lineage has historically been treated as a data engineering convenience. It helps teams understand what breaks when a source changes, which dashboards depend on a table, and how metrics are produced. In an AI-enabled environment, lineage becomes a safety feature.
If an agent produces a recommendation, teams need to answer questions such as:
- Which source systems informed this answer?
- Which transformations were applied?
- Was the dataset fresh enough for this task?
- Were any upstream tests failing?
- Is this metric still approved for use?
- Who owns the model or data product?
Without lineage, agent outputs are difficult to audit. With lineage, teams can trace recommendations back to data sources, transformation logic, and quality checks. That traceability is essential for regulated industries, financial workflows, customer-facing automation, and any environment where AI decisions need to be explained.
For CTOs, this should influence AI architecture decisions. Before connecting agents to operational workflows, evaluate whether your data estate can support investigation, rollback, and accountability.
Analytics maintenance becomes a platform concern
The merger also reinforces a trend that many engineering organizations are already experiencing: analytics is becoming part of the software platform.
Historically, application teams owned production systems while data teams owned reporting environments. AI blurs that boundary. Agents may need application data, product telemetry, customer interactions, billing records, CRM history, support tickets, and internal documentation. They may also feed insights back into product experiences or business processes.
That makes analytics maintenance a platform engineering concern, not just a BI concern.
Teams should treat important datasets more like production services. That means applying software maintenance practices such as code review, automated tests, dependency management, release planning, observability, and deprecation policies. Data models that power executive dashboards, customer health workflows, fraud detection, or AI agents deserve the same operational rigor as APIs.
At Vibgrate, we see this as part of the broader modernization challenge: organizations cannot safely layer advanced automation on top of brittle legacy foundations. Whether the legacy system is a monolith, an outdated dependency tree, or an ungoverned data pipeline, the pattern is the same. Modern capabilities require maintainable infrastructure underneath.
Practical implications for engineering teams
The Fivetran and dbt Labs merger does not mean every team needs to immediately change tools. It does mean engineering leaders should reassess how ready their data foundation is for agentic workflows.
1. Inventory the datasets agents are likely to use
Start with the obvious candidates: customer data, product usage, financial metrics, support history, incident data, engineering delivery metrics, and sales pipeline information. Identify which datasets are already trusted and which are informally used but poorly governed.
For each dataset, ask:
- Who owns it?
- How fresh is it?
- What are its upstream dependencies?
- Are transformations version controlled?
- Are tests in place?
- Is there a canonical definition?
- Is it safe for automated decision-making?
This inventory often reveals that the datasets most attractive for AI workflows are also the ones with the most accumulated technical debt.
2. Consolidate ingestion patterns
Unmanaged ingestion is a common source of fragility. Teams accumulate custom scripts, ad hoc exports, manually scheduled jobs, and overlapping connectors. This creates inconsistent schemas, hidden dependencies, and unclear failure modes.
Modernization should include standardizing how data enters the analytical environment. Whether you use Fivetran, another managed ingestion platform, open-source connectors, or internal tooling, the goal is consistency: predictable sync behavior, schema change handling, monitoring, and ownership.
3. Treat transformations as code
Transformation logic is business logic. If it defines revenue, churn, activation, account health, or engineering throughput, it should be reviewed, tested, documented, and versioned.
This is one reason dbt became influential: it helped bring software engineering practices into analytics workflows. For AI agents, this discipline becomes even more important. Agents need stable, well-defined data products, not a warehouse full of ambiguous tables.
4. Add data quality gates before agent access
Do not let agents consume critical datasets without automated validation. At minimum, teams should monitor freshness, volume anomalies, null rates, uniqueness, referential integrity, accepted values, and schema drift.
Quality gates should be tied to access and workflow design. If a critical upstream test fails, an agent should either avoid using the dataset, warn the user, or fall back to a safer mode. This is similar to circuit breaker patterns in application architecture.
5. Make lineage visible to developers, not just data teams
If developers are building AI-powered features, they need visibility into the data dependencies behind those features. Lineage should not be locked away in a data team tool that application engineers never see.
Expose lineage through documentation, catalogs, pull request checks, or internal developer portals. When a schema change could affect an agent or downstream workflow, developers should know before production breaks.
6. Create a deprecation process for data assets
Old tables and metrics are dangerous when agents can discover and use them. If deprecated datasets remain accessible without clear warnings, they may be treated as valid context.
Establish a lifecycle for data assets: experimental, certified, deprecated, and retired. Make the status machine-readable where possible so tools and agents can distinguish between approved and risky sources.
What CTOs should watch next
The combined Fivetran and dbt Labs company is positioning itself around the data foundation for trusted AI agents. Whether or not your organization uses either platform, the direction is important: the modern data stack is being reinterpreted as AI infrastructure.
CTOs should watch for three developments.
First, expect tighter integration between ingestion, transformation, lineage, observability, and governance. Fragmented data workflows are harder to operate when agents depend on them.
Second, expect semantic layers and governed metrics to become more important. Agents need shared business definitions, not just raw access to tables.
Third, expect data maintenance to become part of AI risk management. The reliability of agentic systems will depend on the reliability of the data supply chain.
The modernization mandate: make trusted data maintainable
The Fivetran and dbt Labs merger is a milestone because it reflects where the industry is heading. Agentic AI will not be powered by prompts alone. It will be powered by data infrastructure that can deliver trusted, explainable, and maintainable context.
For engineering teams, the path forward is practical: reduce data technical debt, standardize ingestion, treat transformations as code, invest in lineage, and enforce quality gates before automation depends on the results. The organizations that do this well will be better positioned to use AI agents safely—not as experimental side projects, but as reliable extensions of their software and business systems.