I was on a call last quarter with the CTO of a mid-market logistics company in one of our PE client portfolios. They had deployed nine AI agents across their operations workflow over the previous six months. Routing decisions, exception handling, customer communication drafts. The system was working. The engineering team was proud.
Then the cloud bill arrived, forty percent over the prior month's projection. Nobody could explain it at the agent level. The billing console showed an aggregate LLM line item. There was no record of which agents drove which spend, which model tiers they called, or which workflows generated the expensive exceptions. The bill was real. The attribution was not.
That is not an unusual story. Most enterprises that have moved into production agentic deployment have done so without a control plane in place. The agents work. The infrastructure around them does not.
Before you scale your agentic AI stack, you need to be able to answer three questions: how much does each agent cost to run, what data does each agent access, and who authorized that access. Those questions are not complicated. Getting clean answers in a production deployment, at scale, is.
The Control Plane Gap
A meaningful share of enterprises now have agentic AI in production. Mayfield's 2026 CXO survey of 266 senior technology executives puts 42 percent of organizations already in production, with 72 percent in production or active pilots combined. That is a real milestone and the deployments I see are generating genuine operational value. What is not real yet, in most of those deployments, is the governance layer.
The governance gap in those deployments is documented in the field data. Gravitee and Opinion Matters surveyed organizations running production AI; their April 2026 State of AI Agent Security report found roughly 48 percent of agent deployments operating without meaningful security controls. IBM’s Think 2026 research, released in June 2026, found that approximately 70 percent of executives say the AI governance they have in place today is not yet fit for purpose. No centralized cost tracking. No audit trail at the call level. No lineage connecting agent behavior to the data it consumed. The agents are in production; the control plane is not.
For a PE portfolio company, this gap matters in two distinct ways. First, it is a cost management problem. Agentic workloads are expensive relative to traditional software, and that expense is variable in ways that traditional software costs are not. An agent that encounters an unexpected data distribution will make more LLM calls than projected. An agent with misconfigured retry logic will compound those calls. Without a routing layer that enforces cost policy, the first signal you get is the bill.
Second, it is a compliance and diligence problem. Agents that read customer data, process sensitive transactions, or make consequential decisions without a documented audit trail are a liability in any regulated industry. They are also a liability in a PE transaction, where the data governance question will surface in diligence.
The Routing Layer: Cost and Governance at the Traffic Point
The first place to build the control plane is where agent traffic flows: the model gateway. Every time an agent makes an LLM call, it is executing a transaction. That transaction has a cost, a latency, a model choice, and a data footprint. In most deployments that are not deliberately engineered for it, those attributes are invisible to anyone except the engineer who built the agent.
Databricks has shipped this capability through the Unity AI Gateway, which sits at the routing layer and applies model policies, enforces rate limits, enforces hard spend caps that automatically stop requests when budgets are exceeded, surfaces per-call cost attribution, and logs every call with enough metadata to support attribution and audit. For portcos on the Databricks stack, this is now the standard pattern. For portcos on other stacks, the equivalent is a proxy or gateway layer that does the same work.
Let me be precise about what enforcing policy at the routing layer actually means. You define rules: this application class can only call these model tiers. This agent has a per-run rate limit. This user has a spend ceiling that halts requests the moment the budget is exceeded. This workflow requires a specific model for compliance reasons. Those rules are evaluated at call time, before the model receives the request. The agent never reaches the LLM until the routing layer approves the transaction.
The value is not just cost control, though cost control is significant. It is that you now have an event log of every model call, tagged to an agent, tagged to a business workflow. When your CFO asks why the AI line item on the cloud bill is up 40 percent, you can answer at the agent level. When your compliance team asks which model processed customer data in that workflow, you have a call-level record to produce.
The routing layer also enables model-tier optimization that is otherwise invisible. A smaller, less expensive model may produce equivalent output quality for a specific workflow. Without call-level attribution, you cannot know which workflows are candidates. With it, you can run the comparison and make the switch based on actual performance data rather than intuition.
Without the routing layer, you are always working backwards from an aggregate bill. With it, you are working forward from an event log.
The Lineage Layer: dbt as Your Audit Trail
The second piece of the control plane is the data lineage layer. Agents do not work on abstract prompts. They read data. Customer records, transaction histories, operational logs, external feeds. Those reads are data access events, and in regulated industries, data access events need a trail.
dbt is the right tool to close this gap, and not because it has become the default transformation layer for mid-market data stacks. It is the right tool because it produces a documented, versioned lineage graph as a natural byproduct of doing transformation work. If your agentic workflows are instrumented to read from dbt-defined models rather than from raw or intermediate tables, the lineage follows without additional engineering.
What this means in practice: when an agent reads customer data to make a routing decision, it reads from a dbt model that is documented, versioned, and sits in a lineage graph showing exactly which source data contributed to it. If an audit asks what customer data the AI system accessed during a given period, the answer is a query, not a two-week manual reconstruction.
The lineage layer also enforces data access policy at the right level of abstraction. If certain fields should never be agent-accessible, that boundary is enforced in the dbt model. The agent reads from a model that was built without those fields. You are not relying on every agent developer to remember to apply a privacy policy at runtime. The policy is in the transformation, which is a more durable enforcement point than agent code.
There is a third benefit to the dbt boundary that shows up when you have multiple agents running against the same data: dependency management. When a dbt model changes, you know which downstream agents depend on it. That dependency graph is your safety check before shipping a transformation update. Without it, schema changes are landmines for agent workflows.
For PE diligence purposes, a portco that runs agents against documented dbt models is presenting a fundamentally different data governance posture than one that runs agents against raw tables. The first produces a clean lineage trace on demand. The second produces a research project.
What Ungoverned Actually Looks Like
Abstract risk does not change behavior the way a specific scenario does, so here is a representative case from the kind of portco AI audit I have been part of over the past year.
An agent is deployed to handle exception cases in a fulfillment workflow. It reads order data, inventory records, and customer contact information. It makes routing decisions. In some cases it calls an LLM to generate a customer-facing response. It runs for three months.
A routine data governance audit finds that the agent has been reading PII fields that were not in scope for its original design. Nobody made a deliberate decision to expose them. The agent had broad read permissions because that was the fastest path to deployment, and the PII was co-located with the data it legitimately needed. There was no alert. There was no audit trail at the model call level. The agent ran for ninety days, at unknown cost per decision, accessing data beyond its intended scope, with no record of any of it.
That scenario is not a horror story manufactured to illustrate a point. Variations of it surface in a meaningful fraction of portco AI audits today. The pattern is consistent: agent deployed quickly, broad data access granted for convenience, no routing governance, no lineage instrumentation, no cost attribution. The agent performs its intended function. The infrastructure around it does not perform its function.
Building the Control Plane: Where to Start
The good news is that this is not a research problem. The tooling exists and the patterns are established. The work is integration and operational discipline.
On the routing side, the Unity AI Gateway pattern is mature for Databricks-native stacks. For portcos on other stacks, the equivalent is any proxy or gateway layer that intercepts model API calls, applies policy, and logs at the call level. The specific technology matters less than the principle: no agent calls a model API directly without passing through an instrumented gateway. Every call is a transaction. Every transaction needs a record.
On the lineage side, if dbt is already in use, the primary integration work is establishing the convention that agents read from documented dbt models rather than raw tables. This is a team convention backed by access control. Agents get read access to model layer tables only; direct access to source tables is restricted. The lineage instrumentation comes for free as part of the dbt workflow.
If dbt is not yet in use, the moment when agentic workloads demand governance is actually a good forcing function for adoption. The lineage benefit is not limited to agent governance. It applies across the whole transformation layer and tends to improve the data team's own debugging and change management workflows.
The third element, cost attribution, gets skipped most often because it is not a platform feature. It is an operational practice. Tagging model calls to agents and workflows at the routing layer produces the raw data. Aggregating that data into a cost-per-agent report and reviewing it on a recurring basis is the practice. The review does not require a large team. It requires that someone owns it.
What PE Diligence Should Be Asking
If you are evaluating a portco that has made meaningful AI commitments in its operational or go-to-market positioning, the technical due diligence needs to include the control plane. The standard checklist questions, does the company have AI in production, are the agents performing their intended function, are necessary but not sufficient.
The right questions are: Where does every model API call get logged, and what is the retention policy? Can you produce a cost-per-agent breakdown for the last ninety days? What is the data access scope for each production agent, and how is that scope enforced at the data layer rather than in application code? If a compliance team asked for an audit of what data the AI system accessed last quarter, what would that process look like, and how long would it take?
If the answers are vague, the portco has agents without governance. That is a risk item. The remediation path is known and achievable. The question is whether the team recognizes the gap. Teams that know they have a control plane problem are much closer to fixing it than teams that believe their governance is adequate because the agents are running.
The Platform Readiness Standard
The portcos building agentic AI on a solid foundation share three characteristics. They have a centralized routing layer where model policies are enforced and every call is logged. They have lineage instrumentation so agent data access is traceable from model call back to source data. And they have a cost attribution practice that ties LLM spend to specific agents and workflows, reviewed on a recurring basis by someone with authority to act on it.
None of those characteristics require a mature AI organization or significant budget. They require treating the control plane as a precondition rather than a retrofit. The teams that defer governance to a later phase consistently arrive at that phase with an expensive, ungoverned system to untangle. The retrofit is always harder than the build.
Data platform readiness for agentic AI is not about having the most sophisticated agent framework or the best models. The model is the easy part, and the options improve every quarter regardless of what you do. The harder problem is building the infrastructure that makes agent behavior observable, cost-attributable, and auditable.
That infrastructure is the gate before agentic scale. The portcos that build it before they need it are the ones that can scale without cost surprises or compliance exposure. The portcos that skip it are building a debt that will surface at the worst possible time, either when the bill arrives or when the audit does.