THE FINANCE LAYER: A PE INSPIRED OPERATING MODEL FOR DATA ARCHITECTURE

WHY DATA ARCHITECTURE NEEDS UNIT ECONOMICS IN THE AGENTIC ERA

The Finance Layer: A PE-Inspired Operating Model for Data Architecture

Why Data Architecture Needs Unit Economics in the Agentic Era

By Karl Ivo Sokolov and Mario Meir-Huber

Abstract

Data architecture has always mattered but the nature of its consequences has changed. In the agentic era, architectural decisions carry asymmetric financial weight that most enterprises are poorly equipped to evaluate. We introduce the concept of the Finance Layer, a discipline that connects platform choices to P&L outcomes. Our argument is that the current “agentic transformation” is, at its core, a data architecture transformation with less familiar economics. The February 2026 SaaS-software selloff offered a preview: data infrastructure held value while application-layer software repriced dramatically. Organizations treating agentic AI as an application-layer initiative, bolting agents onto existing infrastructure, are investing heavily while remaining structurally unprepared to capture value. We explore the addressability problem that “clean data for AI” fails to solve, how architectural efficiency functions as a financial variable, and why platform decisions now carry asymmetric consequences that demand new governance approaches including strategic decommissioning.

The Addressability Problem

Many consultants have arrived with a familiar pitch: “You need clean data for AI.” And while the statement sounds reasonable it may be inadequate in ways that could cost organizations years of misdirected effort.

“Clean data” is a quality attribute that asymptotes quickly. You can spend two years improving data quality from 85% to 92%, and the marginal value of each percentage point diminishes as you approach it. The deeper problem is that “clean” remains undefined in the agentic context. Clean for what purpose? Clean according to whose schema? Clean data sitting in a warehouse that agents cannot programmatically address is clean but useless.

When we began working with enterprises preparing for agentic deployment, we found that the organizations struggling most were the ones that had invested heavily in data quality without investing in the infrastructure required for machines, rather than humans, to consume that data. The shift required is from cleanliness to addressability. Addressability means an agent can locate the data it needs, understand what the data represents through proper semantic modeling, act on the data within defined guardrails, be traced for what it did, and have its costs allocated to the appropriate business unit.

The “clean data for AI” framing solves yesterday’s problem by preparing data for human analysts who can interpret ambiguity, navigate incomplete metadata, and mentally translate between systems. Agents do this poorly and expensively, burning tokens on context reconstruction that a properly architected semantic layer would have made unnecessary.

The practical difference in investment is significant. A data quality initiative might cost $2M and take 18 months. A data architecture transformation for agent readiness, including semantic layer construction, API exposure with governance, and proper cost attribution mechanisms, might cost $15M and take three years. The first feels safer and shows progress in dashboards. The second is what actually unlocks the value that everyone is projecting in their AI business cases.

The Frey Formula: Architecture as a Financial Variable

At the Vienna Engineering Management Conference in February 2026, Mathias Frey, Chief Engineering Technology Officer of Erste Digital at Erste Group, Austria’s largest bank, presented a formulation that captures what most data leaders intuitively know but rarely express in terms that Finance departments can evaluate:

V ∼ D/p = C = logₐ(n)

The variables: D represents demand (the work the organization needs done), p is a product capability multiplier reflecting how effectively that demand is managed and filtered, C is capacity (what can actually be delivered), n is the number of people, and a is the architecture efficiency coefficient, the base of the logarithm.

The formula’s power lies in what it makes visible. Capacity scales logarithmically with headcount, and the steepness of that curve is determined by architecture. When a = 10, you need ten times the people to produce one additional unit of output. When a = 2, you only need twice the people. The gap between those scenarios represents the difference between an organization that scales and one that drowns in coordination costs.

Frey’s observation that matters most: AI impacts n (the people variable), but does not fundamentally change p (product capability) or a (architecture efficiency). You can deploy agents against poorly architected data, and the agents will fail faster, or worse, confidently produce wrong outputs at scale. The architecture coefficient remains the binding constraint.

As organizations compress headcount through AI augmentation, the architectural efficiency variable becomes more consequential, not less. In a world where n is being actively compressed, a becomes the primary lever for value creation. And a is determined by decisions made in data architecture, decisions that were often made years ago, for different reasons, with different constraints. Architecture belongs in investment discussions, not as a technical appendix but as a parameter that determines what productivity gains are achievable and at what cost.

What “Agentic” Actually Means for Data Architecture

Enterprise software vendors are pushing what they call the “agentic layer” into sales conversations with remarkable intensity, Microsoft with Copilot, Salesforce with Agentforce, SAP with Joule, and others. The marketing suggests revolution. The underlying architecture suggests evolution.

Strip away the branding, and the agentic layer is a combination of API enablement, semantic modeling, orchestration infrastructure, and governance planes. Data architects have been building these components, under different names, for years. What has changed is the consumer of this infrastructure. Previously, the consumers were BI tools, data scientists, and application developers. Now, the consumers are AI agents operating at machine speed with machine economics.

This shift in consumer changes the design requirements: latency tolerance narrows, context window limitations impose retrieval precision requirements, and cost attribution per inference becomes necessary for financial governance. The agentic layer is the next iteration of data architecture, built for machine consumers with different constraints, which is precisely why agentic transformation budgets should be evaluated as data architecture investments rather than AI experiments. The success criteria, the governance intensity, and the payback period all follow platform economics.

What We Learned Operating Under Private Equity-Style Economics

We have had the experience of operating technology functions in environments where private equity economics applied, where every initiative was scrutinized for its contribution to value creation, where carrying costs were reviewed quarterly, and where the question was never “is this interesting?” but “does this move the number?”

Very few technology expenditures successfully pass through that filter.

What does is technology that takes cost out of the business while maintaining or improving output, technology that unlocks capacity without proportional headcount growth, technology that reduces cycle times on revenue-generating processes. What does not pass includes capability-building programs with vague “future flexibility” rationales, data quality initiatives that cannot trace impact to a P&L line, and AI experiments that produce cool demos but not deployable workflows.

The PE operating model would typically look like this: 20% annual increases in technology spend, not decreases, combined with 40%+ reductions in operational costs enabled by that technology. Technology becomes a lever to extract operational gains that exceed the investment.

We raise this because the economic pressure that PE creates explicitly is now arriving implicitly for most enterprises. Competitive pressure from AI-native entrants, margin compression, and investor scrutiny of AI spending without demonstrated returns are creating PE-like conditions across industries. Data architecture investment either passes the test of demonstrable value creation, or it becomes a target for the next round of cost reduction.

The Virtue Cycle That Architecture Should Enable

Business departments spinning up agents should not be pursuing one-time improvements. The potential, unrealized in most organizations, is a self-improving virtue cycle where structured process data, unstructured documents, and workflow telemetry combine to continuously improve agent performance.

Consider what happens when an agent processes procurement requests. Each request generates structured data (vendor, amount, category, approval chain) alongside unstructured context (email threads, specifications, negotiation notes). If the architecture supports it, this combined signal can flow back into the semantic layer, improving retrieval for similar future requests, refining the agent’s understanding of which approvals require escalation, and identifying patterns that suggest process inefficiency or fraud risk. The agent that processed a thousand requests should be meaningfully better than the agent that processed ten, but only if the architecture captures the learning.

This requires semantic layers that can incorporate feedback loops, observability that captures agent behavior in ways that support learning, and governance that permits this feedback while maintaining controls. Most enterprise data architectures were designed for batch reporting, where data flowed in one direction, from operational systems to warehouses to dashboards to humans who made decisions. The agentic architecture requires bidirectional flow. Organizations that build for this will compound their advantage. Organizations that deploy agents against static architecture will achieve one-time productivity gains that plateau quickly.

Where Value Is Concentrating

The February 2026 “Software-mageddon” offered a natural experiment. While application-layer software lost approximately $2 trillion in market capitalization, the data infrastructure layer held. Databricks raised $5 billion at a $134 billion valuation, oversubscribed, during the selloff. Snowflake’s AI Services consumption is reported to be growing while traditional SaaS seats and their pricing are being questioned across the industry.

The signal is clear: investors who allocate capital professionally have concluded that the application layer is being commoditized by models, while the data layer is becoming more valuable.

Foundation models compress the domain logic that previously required custom software development. The barrier to replicating application functionality has collapsed. Value is migrating to two places: the model layer (captured by foundation model providers) and the data layer (captured by whoever owns proprietary, well-architected enterprise data).

And since you are most probably not building foundation models, your competitive position depends on the data layer. The ROI calculation for data architecture has shifted accordingly, from the efficiency gains of better BI to the option value of participating in AI value creation.

How Platform Costs Map to Financial Statements

Data platform leaders rarely possess fluency in how their investments appear on financial statements, and finance leaders reviewing data platform spend rarely understand the technical drivers of those costs. This mutual illegibility creates problems that compound over time.

Traditional on-premise data infrastructure was CAPEX: servers purchased, depreciated over useful life, creating assets on the balance sheet. Cloud infrastructure is predominantly OPEX: consumed as services, expensed immediately, hitting the P&L in the period incurred. This shift has made data platform costs more visible to CFOs on a quarterly basis, which sounds like improved governance but often creates perverse incentives, pressure to reduce cloud spend in the current quarter at the expense of architectural investments that would reduce total cost of ownership over a multi-year horizon.

Where costs land on the P&L determines scrutiny intensity. AI costs embedded in COGS receive intense board attention because they directly affect gross margin. AI costs in R&D receive different scrutiny: they are expected to be investment-like, with payoff in future periods. AI costs buried in G&A often receive the least strategic attention, treated as overhead rather than investment, which may be exactly wrong if those costs are enabling productivity gains across the organization.

The depreciation question is increasingly problematic. When you capitalize software development under ASC 350-40 (US GAAP) or IAS 38 (IFRS), you assert that the development creates an asset with multi-year useful life. But this seems to be less true for AI systems. E.g. AI systems would drift; models degrade as distributions shift and prompts require maintenance as underlying models update. We have seen organizations capitalize AI development on five-year schedules for systems that require substantial rework within eighteen months, creating a mismatch between accounting treatment and economic reality.

Data Platform Economics

When a CIO signs a three-year platform commitment, they are making a capital allocation decision that will shape cost trajectories, constrain architectural choices, and determine what the organization can afford to do with agents. Yet most platform selection processes evaluate features and benchmarks. Almost none model the financial behavior of the platform under the workload patterns that agentic deployment will create.

The two dominant platforms are not interchangeable products with different logos. They are different financial instruments. Snowflake’s separated compute model charges by warehouse runtime and rewards discipline and predictability. It punishes concurrency: agents issuing hundreds of small, high-frequency queries against the semantic layer will trigger scaling costs that BI-only projections just never really anticipated. Databricks charges through DBUs, a normalized processing measure, and rewards strong engineering discipline (that comes with a cost of its own, typically requiring more rigorous engineering capabilities). It punishes immaturity: unoptimized Spark jobs, poorly partitioned tables, and over-scanning retrieval pipelines burn DBUs without producing proportional value. We are just experiencing large Databricks projects migrated poorly that even run into performance issues, next to cost issues precisely for this reason. We have also seen organizations with comparable workloads where annual platform costs easily diverged by 100% from $300K to $600K purely based on the match between the platform’s financial model and the organization’s operational maturity.

In terms of Mathias Frey’s Formula, platform choice thus directly affects the architecture efficiency coefficient a, because misaligned economics raise the cost of every unit of capacity (i.e. independent of the vendor, subpar architecture induces subpar economics).

Similarly, the convergence around Apache Iceberg may be the most financially significant data infrastructure development since the shift to cloud, precisely for what it does to the reversal premium of platform decisions. I.e. this optionality is valuable on its own merit and not on technical gains alone. When data sits in an open format on object storage, the compute layer becomes interchangeable. A decision that once required an 18-month migration to reverse can now be reversed in weeks. Organizations adopting Iceberg are buying optionality: converting a high-reversal-premium commitment into something closer to a rolling option. Databricks’ moves with Lakebase and Snowflake’s deepening Iceberg integration both signal that the vendors recognize this shift in buyer power.

Serverless compute is marketed as the efficient default, and for bursty, unpredictable workloads it genuinely is. But we are finding that agentic workloads are not that bursty. Agents in production generate sustained, high-frequency load that seems to resemble application workloads more than it does analyst queries workloads.

More tests are needed for this, but observations and a rule of thumb, show that similar to application workloads, with anything over 60% sustained utilization, provisioned capacity costs 30% less than serverless for equivalent throughput.

Organizations that default to serverless during experimentation and fail to re-evaluate as workloads mature accumulate an overspend that compounds monthly.

This raises a governance question about commitment structures. Vendors offer one- and three-year discounts of 15-30%, but a multi-year commitment is a bet that workload patterns will remain stable, and agentic adoption will change them. The better approach we believe is to have structured optionality: commit on the predictable base, retain on-demand capacity for agentic workloads, and migrate into committed tiers as consumption patterns stabilize. The 10-15% premium over a full commitment can be seen as the price of “the right to adapt”. For Finance departments (and esp. Purchasing deparments) evaluating platform renewals, the question is not what is the deepest discount on compute possible, but what is the cost of being wrong about the consumption forecast in an environment where that forecast has never been less certain.

Architecture Patterns for Agent Readiness

Agent readiness can be seen as a stack with three distinct layers, each requiring different architectural investment. Layer one is retrieval: can an agent find the data it needs? This is where most organizations focus today, building vector stores, tuning RAG pipelines, optimizing embedding models. Layer two is semantics: can the agent understand what the data represents, what business logic applies, and what constraints govern its use? Layer three is action: can the agent execute a governed operation, with cost attribution, audit trails and guardrails? Most enterprise investment concentrates on layer one while layers two and three remain immature (but indeed also unfunded). This is why current agent deployments can retrieve information but cannot reliably act on it. We predict that this will also reverse the overall ROIs and efficiency expectations down, as enterprises find out that fully bringing these things into production requires also an additional investment in CAPEX, plus additional OPEX spend to keep them maintained well into production.

The architectural mistake compounding this imbalance is the generalist agent. Organizations default to building broad-purpose agents that attempt to handle diverse tasks across multiple domains. This feels efficient because it reduces the number of components to manage. It is, in practice, we believe the opposite. A generalist agent must carry the context for every domain it might encounter and it needs access to every data source, every schema, every set of business rules. This means larger context windows, more tokens consumed per inference, more retrieval surface to search, and weaker governance because permissions must be broad enough to accommodate the widest possible task range. The result is an agent that is expensive to run, difficult to govern, and mediocre at most of its tasks.

Specialized agents could invert this equation. For instance, a procurement agent needs access to vendor data, contract terms, and approval workflows, but it does not need access to HR records, marketing analytics, or financial planning models and so on. By constraining the agent’s scope, you constrain its context requirements, its retrieval surface, and its permission boundaries. Fewer tokens per inference, more precise retrieval and indeed tighter governance. The unit economics improve at every level of the stack here. In our example above, specialized agent processing procurement requests at a cost of $0.03 per transaction will outperform a generalist agent doing the same work at $0.12, precisely because of this architecture choice. Specialization also improves output quality, while in many cases permitting the use of smaller, less expensive models without sacrificing performance or cost.

This is where agent routing becomes an architectural requirement. A routing layer sits above the specialized agents and directs incoming requests to the agent best equipped to handle them, based on intent classification, domain mapping, and required capability. Routing is lightweight: it consumes minimal tokens to classify and forward. The expensive inference happens in the specialized agent, which operates within a constrained, well-governed context. The pattern mirrors how well-run organizations work. You do not send every question to the CEO. You route it to the person with the relevant expertise and authority. Agent routing is the organizational chart of an agentic architecture, and like a good org chart, it makes the system faster, cheaper, and more accountable.

Standards like the Model Context Protocol (MCP) reinforce this pattern by providing a standardized interface through which agents connect to data sources and tools. MCP means each specialized agent does not need custom integration code for every system it touches. It reduces the engineering overhead of specialization, which was historically the argument against it. We could assume that with MCP and similar protocols, the cost of building ten specialized agents approaches the cost of building two or three generalist ones, while the operational efficiency and governance properties remain superior. The architecture that supports this, a semantic layer designed for machine consumption, a routing layer for intent-based dispatch, and specialized agents with constrained scope, is what would enable organizations to deploy agents profitably.

The Edge and On-Premise Arbitrage

Cloud was the obvious choice when inference required the same GPU clusters used for training, but that coupling too is dissolving. Apple Silicon, optimized smaller models, and dedicated inference hardware mean that for predictable, high-volume inference workloads, the cost crossover where owning compute beats cloud consumption is arriving faster than most CFOs (and many CIOs) realize. An enterprise running specialized agents at sustained volume, the procurement agent project example from the previous section, processing thousands of daily transactions, can reach a breakeven against cloud inference pricing within 12-18 months of a modest hardware investment.

This connects directly to the specialized agent argument. Generalist agents with unpredictable workload patterns remain cloud-native by necessity: you cannot size hardware for demand you cannot forecast. Specialized agents with constrained scope and predictable throughput are the ideal candidates for on-premise or edge deployment. The architecture implication is a hybrid model: centralized data platform in the cloud for governance and complex analytics, distributed inference at the edge for workloads where cost, latency, or data residency requirements make cloud consumption the more expensive option. Organizations that architected for specialization will have the option while organizations that built generalist agents will not.

The Asymmetry of Architectural Consequences

Not all architectural choices carry equal weight. Some decisions are reversible: you can change a data model, swap an orchestration tool, refactor a pipeline. The cost of being wrong scales roughly with the effort invested, which is of course uncomfortable, but remains linear.

Other decisions are more structural: from data platform selection, to multi-year cloud commitment, data residency choices, core schema design. These decisions carry asymmetric consequences. The goal is to get them right, so that you have a foundation that enables years of capability building at decreasing marginal cost. But if you get them wrong, or pursue an inconsistent and duplicate data architecture, and you pay what we have come to call the Dual-Run Tax, i.e. the multiplicative cost of running old and new systems in parallel during migration.

The Dual-Run Tax is not simply 2x, but in our experience across various migration projects, it runs 2.2x to 2.5x, because parallel systems require data synchronization between environments (often the hardest engineering problem), staff capacity split across paradigms (reducing effectiveness in both), governance overhead for both systems, and extended timelines as teams context-switch between incompatible mental models.

This asymmetry also creates an obligation that most organizations neglect but would be well advised to embrace and that is: strategic decommissioning. Legacy components that remain in production impose carrying costs, maintenance, security patching, staff knowledge, governance overhead. In a PE-style efficiency regime, every system that does not contribute to current value creation is a candidate for retirement. We have found that organizations serious about agentic transformation budget decommissioning as explicitly as they budget new capability. The capacity freed by removing legacy load is often more valuable than the capacity added by new hires.

Before committing to a platform or architecture, the question Finance should ask is: what is the reversal premium? What will it cost to unwind this decision if circumstances change? Decisions with high reversal premiums, multi-year cloud commits, proprietary format adoption, deep platform dependencies, require different governance intensity than decisions that can be unwound at the cost of engineering time alone.

What This Means for the Data Architect’s Role

Data architecture is no longer a technical specialization that produces artifacts for other teams to consume. In our view it has become also an economic discipline that determines what an organization can and cannot achieve with AI, and at what cost.

Data architects who cannot speak the language of unit economics, TCO modeling, OPEX/CAPEX tradeoffs, and investment payback periods will find their influence shrinking even as the technical importance of their work grows. Data leaders are advised to study the CFO’s perspective and treat it as a constraint that improves architecture by forcing clarity on value creation and cost allocation; it is the fabled “fit-for-purpose”-ness that good data architecture requires.

We believe the organizations that manage to capture value in the agentic era the quickest will be those that treat data architecture as a first-class strategic investment, governed with the same rigor applied to M&A activity or major capital allocation decisions.

References

Sokolov, K.I. & Meir-Huber, M. (2026). Finance-Grade Data & AI Products: The VANE Loop Framework. Vane Loop Research. vaneloop.com/book

Frey, M. (2026). “Scaling Beyond Code: The Architecture of Leadership.” Vienna Engineering Management Meetup.

Inmon, W.H. & Linstedt, D. (2014). Data Architecture: A Primer for the Data Scientist. Morgan Kaufmann.

Taleb, N.N. (2012). Antifragile: Things That Gain from Disorder. Random House. [On asymmetric consequences and optionality]

Gartner (2025). “40% of Enterprise Applications Will Feature Task-Specific AI Agents by 2026.”

MuleSoft (2026). “2026 Connectivity Benchmark Report.” [On agent proliferation and governance gaps]

The Finance Layer: A PE-Inspired Operating Model for Data Architecture

Why Data Architecture Needs Unit Economics in the Agentic Era

By Karl Ivo Sokolov and Mario Meir-Huber

Abstract

Data architecture has always mattered but the nature of its consequences has changed. In the agentic era, architectural decisions carry asymmetric financial weight that most enterprises are poorly equipped to evaluate. We introduce the concept of the Finance Layer, a discipline that connects platform choices to P&L outcomes. Our argument is that the current “agentic transformation” is, at its core, a data architecture transformation with less familiar economics. The February 2026 SaaS-software selloff offered a preview: data infrastructure held value while application-layer software repriced dramatically. Organizations treating agentic AI as an application-layer initiative, bolting agents onto existing infrastructure, are investing heavily while remaining structurally unprepared to capture value. We explore the addressability problem that “clean data for AI” fails to solve, how architectural efficiency functions as a financial variable, and why platform decisions now carry asymmetric consequences that demand new governance approaches including strategic decommissioning.

The Addressability Problem

Many consultants have arrived with a familiar pitch: “You need clean data for AI.” And while the statement sounds reasonable it may be inadequate in ways that could cost organizations years of misdirected effort.

“Clean data” is a quality attribute that asymptotes quickly. You can spend two years improving data quality from 85% to 92%, and the marginal value of each percentage point diminishes as you approach it. The deeper problem is that “clean” remains undefined in the agentic context. Clean for what purpose? Clean according to whose schema? Clean data sitting in a warehouse that agents cannot programmatically address is clean but useless.

When we began working with enterprises preparing for agentic deployment, we found that the organizations struggling most were the ones that had invested heavily in data quality without investing in the infrastructure required for machines, rather than humans, to consume that data. The shift required is from cleanliness to addressability. Addressability means an agent can locate the data it needs, understand what the data represents through proper semantic modeling, act on the data within defined guardrails, be traced for what it did, and have its costs allocated to the appropriate business unit.

The “clean data for AI” framing solves yesterday’s problem by preparing data for human analysts who can interpret ambiguity, navigate incomplete metadata, and mentally translate between systems. Agents do this poorly and expensively, burning tokens on context reconstruction that a properly architected semantic layer would have made unnecessary.

The practical difference in investment is significant. A data quality initiative might cost €2M and take 18 months. A data architecture transformation for agent readiness, including semantic layer construction, API exposure with governance, and proper cost attribution mechanisms, might cost €15M and take three years. The first feels safer and shows progress in dashboards. The second is what actually unlocks the value that everyone is projecting in their AI business cases.

The Frey Formula: Architecture as a Financial Variable

At the Vienna Engineering Management Conference in February 2026, Mathias Frey, Chief Engineering Technology Officer of Erste Digital at Erste Group, Austria’s largest bank, presented a formulation that captures what most data leaders intuitively know but rarely express in terms that Finance departments can evaluate:

V ∼ D/p = C = logₐ(n)

The variables: D represents demand (the work the organization needs done), p is a product capability multiplier reflecting how effectively that demand is managed and filtered, C is capacity (what can actually be delivered), n is the number of people, and a is the architecture efficiency coefficient, the base of the logarithm.

The formula’s power lies in what it makes visible. Capacity scales logarithmically with headcount, and the steepness of that curve is determined by architecture. When a = 10, you need ten times the people to produce one additional unit of output. When a = 2, you only need twice the people. The gap between those scenarios represents the difference between an organization that scales and one that drowns in coordination costs.

Frey’s observation that matters most: AI impacts n (the people variable), but does not fundamentally change p (product capability) or a (architecture efficiency). You can deploy agents against poorly architected data, and the agents will fail faster, or worse, confidently produce wrong outputs at scale. The architecture coefficient remains the binding constraint.

As organizations compress headcount through AI augmentation, the architectural efficiency variable becomes more consequential, not less. In a world where n is being actively compressed, a becomes the primary lever for value creation. And a is determined by decisions made in data architecture, decisions that were often made years ago, for different reasons, with different constraints. Architecture belongs in investment discussions, not as a technical appendix but as a parameter that determines what productivity gains are achievable and at what cost.

What “Agentic” Actually Means for Data Architecture

Enterprise software vendors are pushing what they call the “agentic layer” into sales conversations with remarkable intensity, Microsoft with Copilot, Salesforce with Agentforce, SAP with Joule, and others. The marketing suggests revolution. The underlying architecture suggests evolution.

Strip away the branding, and the agentic layer is a combination of API enablement, semantic modeling, orchestration infrastructure, and governance planes. Data architects have been building these components, under different names, for years. What has changed is the consumer of this infrastructure. Previously, the consumers were BI tools, data scientists, and application developers. Now, the consumers are AI agents operating at machine speed with machine economics.

This shift in consumer changes the design requirements: latency tolerance narrows, context window limitations impose retrieval precision requirements, and cost attribution per inference becomes necessary for financial governance. The agentic layer is the next iteration of data architecture, built for machine consumers with different constraints, which is precisely why agentic transformation budgets should be evaluated as data architecture investments rather than AI experiments. The success criteria, the governance intensity, and the payback period all follow platform economics.

What We Learned Operating Under Private Equity-Style Economics

We have had the experience of operating technology functions in environments where private equity economics applied, where every initiative was scrutinized for its contribution to value creation, where carrying costs were reviewed quarterly, and where the question was never “is this interesting?” but “does this move the number?”

Very few technology expenditures successfully pass through that filter.

What does is technology that takes cost out of the business while maintaining or improving output, technology that unlocks capacity without proportional headcount growth, technology that reduces cycle times on revenue-generating processes. What does not pass includes capability-building programs with vague “future flexibility” rationales, data quality initiatives that cannot trace impact to a P&L line, and AI experiments that produce cool demos but not deployable workflows.

The PE operating model would typically look like this: 20% annual increases in technology spend, not decreases, combined with 40%+ reductions in operational costs enabled by that technology. Technology becomes a lever to extract operational gains that exceed the investment.

We raise this because the economic pressure that PE creates explicitly is now arriving implicitly for most enterprises. Competitive pressure from AI-native entrants, margin compression, and investor scrutiny of AI spending without demonstrated returns are creating PE-like conditions across industries. Data architecture investment either passes the test of demonstrable value creation, or it becomes a target for the next round of cost reduction.

The Virtue Cycle That Architecture Should Enable

Business departments spinning up agents should not be pursuing one-time improvements. The potential, unrealized in most organizations, is a self-improving virtue cycle where structured process data, unstructured documents, and workflow telemetry combine to continuously improve agent performance.

Consider what happens when an agent processes procurement requests. Each request generates structured data (vendor, amount, category, approval chain) alongside unstructured context (email threads, specifications, negotiation notes). If the architecture supports it, this combined signal can flow back into the semantic layer, improving retrieval for similar future requests, refining the agent’s understanding of which approvals require escalation, and identifying patterns that suggest process inefficiency or fraud risk. The agent that processed a thousand requests should be meaningfully better than the agent that processed ten, but only if the architecture captures the learning.

This requires semantic layers that can incorporate feedback loops, observability that captures agent behavior in ways that support learning, and governance that permits this feedback while maintaining controls. Most enterprise data architectures were designed for batch reporting, where data flowed in one direction, from operational systems to warehouses to dashboards to humans who made decisions. The agentic architecture requires bidirectional flow. Organizations that build for this will compound their advantage. Organizations that deploy agents against static architecture will achieve one-time productivity gains that plateau quickly.

Where Value Is Concentrating

The February 2026 “Software-mageddon” offered a natural experiment. While application-layer software lost approximately $2 trillion in market capitalization, the data infrastructure layer held. Databricks raised $5 billion at a $134 billion valuation, oversubscribed, during the selloff. Snowflake’s AI Services consumption is reported to be growing while traditional SaaS seats and their pricing are being questioned across the industry.

The signal is clear: investors who allocate capital professionally have concluded that the application layer is being commoditized by models, while the data layer is becoming more valuable.

Foundation models compress the domain logic that previously required custom software development. The barrier to replicating application functionality has collapsed. Value is migrating to two places: the model layer (captured by foundation model providers) and the data layer (captured by whoever owns proprietary, well-architected enterprise data).

And since you are most probably not building foundation models, your competitive position depends on the data layer. The ROI calculation for data architecture has shifted accordingly, from the efficiency gains of better BI to the option value of participating in AI value creation.

How Platform Costs Map to Financial Statements

Data platform leaders rarely possess fluency in how their investments appear on financial statements, and finance leaders reviewing data platform spend rarely understand the technical drivers of those costs. This mutual illegibility creates problems that compound over time.

Traditional on-premise data infrastructure was CAPEX: servers purchased, depreciated over useful life, creating assets on the balance sheet. Cloud infrastructure is predominantly OPEX: consumed as services, expensed immediately, hitting the P&L in the period incurred. This shift has made data platform costs more visible to CFOs on a quarterly basis, which sounds like improved governance but often creates perverse incentives, pressure to reduce cloud spend in the current quarter at the expense of architectural investments that would reduce total cost of ownership over a multi-year horizon.

Where costs land on the P&L determines scrutiny intensity. AI costs embedded in COGS receive intense board attention because they directly affect gross margin. AI costs in R&D receive different scrutiny: they are expected to be investment-like, with payoff in future periods. AI costs buried in G&A often receive the least strategic attention, treated as overhead rather than investment, which may be exactly wrong if those costs are enabling productivity gains across the organization.

The depreciation question is increasingly problematic. When you capitalize software development under ASC 350-40 (US GAAP) or IAS 38 (IFRS), you assert that the development creates an asset with multi-year useful life. But this seems to be less true for AI systems. E.g. AI systems would drift; models degrade as distributions shift and prompts require maintenance as underlying models update. We have seen organizations capitalize AI development on five-year schedules for systems that require substantial rework within eighteen months, creating a mismatch between accounting treatment and economic reality.

Data Platform Economics

When a CIO signs a three-year platform commitment, they are making a capital allocation decision that will shape cost trajectories, constrain architectural choices, and determine what the organization can afford to do with agents. Yet most platform selection processes evaluate features and benchmarks. Almost none model the financial behavior of the platform under the workload patterns that agentic deployment will create.

The two dominant platforms are not interchangeable products with different logos. They are different financial instruments. Snowflake’s separated compute model charges by warehouse runtime and rewards discipline and predictability. It punishes concurrency: agents issuing hundreds of small, high-frequency queries against the semantic layer will trigger scaling costs that BI-only projections just never really anticipated. Databricks charges through DBUs, a normalized processing measure, and rewards strong engineering discipline (that comes with a cost of its own, typically requiring more rigorous engineering capabilities). It punishes immaturity: unoptimized Spark jobs, poorly partitioned tables, and over-scanning retrieval pipelines burn DBUs without producing proportional value. We are just experiencing large Databricks projects migrated poorly that even run into performance issues, next to cost issues precisely for this reason. We have also seen organizations with comparable workloads where annual platform costs easily diverged by 100% from $300K to $600K purely based on the match between the platform’s financial model and the organization’s operational maturity.

In terms of Mathias Frey’s Formula, platform choice thus directly affects the architecture efficiency coefficient a, because misaligned economics raise the cost of every unit of capacity (i.e. independent of the vendor, subpar architecture induces subpar economics).

Similarly, the convergence around Apache Iceberg may be the most financially significant data infrastructure development since the shift to cloud, precisely for what it does to the reversal premium of platform decisions. I.e. this optionality is valuable on its own merit and not on technical gains alone. When data sits in an open format on object storage, the compute layer becomes interchangeable. A decision that once required an 18-month migration to reverse can now be reversed in weeks. Organizations adopting Iceberg are buying optionality: converting a high-reversal-premium commitment into something closer to a rolling option. Databricks’ moves with Lakebase and Snowflake’s deepening Iceberg integration both signal that the vendors recognize this shift in buyer power.

Serverless compute is marketed as the efficient default, and for bursty, unpredictable workloads it genuinely is. But we are finding that agentic workloads are not that bursty. Agents in production generate sustained, high-frequency load that seems to resemble application workloads more than it does analyst queries workloads.

More tests are needed for this, but observations and a rule of thumb, show that similar to application workloads, with anything over 60% sustained utilization, provisioned capacity costs 30% less than serverless for equivalent throughput.

Organizations that default to serverless during experimentation and fail to re-evaluate as workloads mature accumulate an overspend that compounds monthly.

This raises a governance question about commitment structures. Vendors offer one- and three-year discounts of 15-30%, but a multi-year commitment is a bet that workload patterns will remain stable, and agentic adoption will change them. The better approach we believe is to have structured optionality: commit on the predictable base, retain on-demand capacity for agentic workloads, and migrate into committed tiers as consumption patterns stabilize. The 10-15% premium over a full commitment can be seen as the price of “the right to adapt”. For Finance departments (and esp. Purchasing deparments) evaluating platform renewals, the question is not what is the deepest discount on compute possible, but what is the cost of being wrong about the consumption forecast in an environment where that forecast has never been less certain.

Architecture Patterns for Agent Readiness

Agent readiness can be seen as a stack with three distinct layers, each requiring different architectural investment. Layer one is retrieval: can an agent find the data it needs? This is where most organizations focus today, building vector stores, tuning RAG pipelines, optimizing embedding models. Layer two is semantics: can the agent understand what the data represents, what business logic applies, and what constraints govern its use? Layer three is action: can the agent execute a governed operation, with cost attribution, audit trails and guardrails? Most enterprise investment concentrates on layer one while layers two and three remain immature (but indeed also unfunded). This is why current agent deployments can retrieve information but cannot reliably act on it. We predict that this will also reverse the overall ROIs and efficiency expectations down, as enterprises find out that fully bringing these things into production requires also an additional investment in CAPEX, plus additional OPEX spend to keep them maintained well into production.

The architectural mistake compounding this imbalance is the generalist agent. Organizations default to building broad-purpose agents that attempt to handle diverse tasks across multiple domains. This feels efficient because it reduces the number of components to manage. It is, in practice, we believe the opposite. A generalist agent must carry the context for every domain it might encounter and it needs access to every data source, every schema, every set of business rules. This means larger context windows, more tokens consumed per inference, more retrieval surface to search, and weaker governance because permissions must be broad enough to accommodate the widest possible task range. The result is an agent that is expensive to run, difficult to govern, and mediocre at most of its tasks.

Specialized agents could invert this equation. For instance, a procurement agent needs access to vendor data, contract terms, and approval workflows, but it does not need access to HR records, marketing analytics, or financial planning models and so on. By constraining the agent’s scope, you constrain its context requirements, its retrieval surface, and its permission boundaries. Fewer tokens per inference, more precise retrieval and indeed tighter governance. The unit economics improve at every level of the stack here. In our example above, specialized agent processing procurement requests at a cost of $0.03 per transaction will outperform a generalist agent doing the same work at $0.12, precisely because of this architecture choice. Specialization also improves output quality, while in many cases permitting the use of smaller, less expensive models without sacrificing performance or cost.

This is where agent routing becomes an architectural requirement. A routing layer sits above the specialized agents and directs incoming requests to the agent best equipped to handle them, based on intent classification, domain mapping, and required capability. Routing is lightweight: it consumes minimal tokens to classify and forward. The expensive inference happens in the specialized agent, which operates within a constrained, well-governed context. The pattern mirrors how well-run organizations work. You do not send every question to the CEO. You route it to the person with the relevant expertise and authority. Agent routing is the organizational chart of an agentic architecture, and like a good org chart, it makes the system faster, cheaper, and more accountable.

Standards like the Model Context Protocol (MCP) reinforce this pattern by providing a standardized interface through which agents connect to data sources and tools. MCP means each specialized agent does not need custom integration code for every system it touches. It reduces the engineering overhead of specialization, which was historically the argument against it. We could assume that with MCP and similar protocols, the cost of building ten specialized agents approaches the cost of building two or three generalist ones, while the operational efficiency and governance properties remain superior. The architecture that supports this, a semantic layer designed for machine consumption, a routing layer for intent-based dispatch, and specialized agents with constrained scope, is what would enable organizations to deploy agents profitably.

The Edge and On-Premise Arbitrage

Cloud was the obvious choice when inference required the same GPU clusters used for training, but that coupling too is dissolving. Apple Silicon, optimized smaller models, and dedicated inference hardware mean that for predictable, high-volume inference workloads, the cost crossover where owning compute beats cloud consumption is arriving faster than most CFOs (and many CIOs) realize. An enterprise running specialized agents at sustained volume, the procurement agent project example from the previous section, processing thousands of daily transactions, can reach a breakeven against cloud inference pricing within 12-18 months of a modest hardware investment.

This connects directly to the specialized agent argument. Generalist agents with unpredictable workload patterns remain cloud-native by necessity: you cannot size hardware for demand you cannot forecast. Specialized agents with constrained scope and predictable throughput are the ideal candidates for on-premise or edge deployment. The architecture implication is a hybrid model: centralized data platform in the cloud for governance and complex analytics, distributed inference at the edge for workloads where cost, latency, or data residency requirements make cloud consumption the more expensive option. Organizations that architected for specialization will have the option while organizations that built generalist agents will not.

The Asymmetry of Architectural Consequences

Not all architectural choices carry equal weight. Some decisions are reversible: you can change a data model, swap an orchestration tool, refactor a pipeline. The cost of being wrong scales roughly with the effort invested, which is of course uncomfortable, but remains linear.

Other decisions are more structural: from data platform selection, to multi-year cloud commitment, data residency choices, core schema design. These decisions carry asymmetric consequences. The goal is to get them right, so that you have a foundation that enables years of capability building at decreasing marginal cost. But if you get them wrong, or pursue an inconsistent and duplicate data architecture, and you pay what we have come to call the Dual-Run Tax, i.e. the multiplicative cost of running old and new systems in parallel during migration.

The Dual-Run Tax is not simply 2x, but in our experience across various migration projects, it runs 2.2x to 2.5x, because parallel systems require data synchronization between environments (often the hardest engineering problem), staff capacity split across paradigms (reducing effectiveness in both), governance overhead for both systems, and extended timelines as teams context-switch between incompatible mental models.

This asymmetry also creates an obligation that most organizations neglect but would be well advised to embrace and that is: strategic decommissioning. Legacy components that remain in production impose carrying costs, maintenance, security patching, staff knowledge, governance overhead. In a PE-style efficiency regime, every system that does not contribute to current value creation is a candidate for retirement. We have found that organizations serious about agentic transformation budget decommissioning as explicitly as they budget new capability. The capacity freed by removing legacy load is often more valuable than the capacity added by new hires.

Before committing to a platform or architecture, the question Finance should ask is: what is the reversal premium? What will it cost to unwind this decision if circumstances change? Decisions with high reversal premiums, multi-year cloud commits, proprietary format adoption, deep platform dependencies, require different governance intensity than decisions that can be unwound at the cost of engineering time alone.

What This Means for the Data Architect’s Role

Data architecture is no longer a technical specialization that produces artifacts for other teams to consume. In our view it has become also an economic discipline that determines what an organization can and cannot achieve with AI, and at what cost.

Data architects who cannot speak the language of unit economics, TCO modeling, OPEX/CAPEX tradeoffs, and investment payback periods will find their influence shrinking even as the technical importance of their work grows. Data leaders are advised to study the CFO’s perspective and treat it as a constraint that improves architecture by forcing clarity on value creation and cost allocation; it is the fabled “fit-for-purpose”-ness that good data architecture requires.

We believe the organizations that manage to capture value in the agentic era the quickest will be those that treat data architecture as a first-class strategic investment, governed with the same rigor applied to M&A activity or major capital allocation decisions.

References

Sokolov, K.I. & Meir-Huber, M. (2026). Finance-Grade Data & AI Products: The VANE Loop Framework. Vane Loop Research. vaneloop.com/book

Frey, M. (2026). “Scaling Beyond Code: The Architecture of Leadership.” Vienna Engineering Management Meetup.

Inmon, W.H. & Linstedt, D. (2014). Data Architecture: A Primer for the Data Scientist. Morgan Kaufmann.

Taleb, N.N. (2012). Antifragile: Things That Gain from Disorder. Random House. [On asymmetric consequences and optionality]

Gartner (2025). “40% of Enterprise Applications Will Feature Task-Specific AI Agents by 2026.”

MuleSoft (2026). “2026 Connectivity Benchmark Report.” [On agent proliferation and governance gaps.

Kark Ivo Sokolov

Mario Meir-Huber

Karl Ivo Sokolov:

Karl Ivo Sokolov is Managing Director Data & AI at Specific-Group Austria, where he leads international teams across eight European countries. His work focuses on building robust data products and guiding enterprises through the modernization of complex data environments spanning both legacy and modern platforms. Beyond his role at Specific-Group, Karl Ivo also serves on the Global Board of Directors of the U.S. Institute of Management Accountants (IMA), contributing to the advancement of data-driven decision-making in finance and management accounting worldwide.

Mario Meir-Huber:

Mario Meir-Huber helps organizations turn scattered data initiatives into governed, business-driven Data Products. A former Head of Data and ex-Microsoftie, he has built Data Products across European companies. He created the GAP (Governance–Architecture–People) model and the DRIVE lifecycle framework and applies them in real engagements. Mario lectures at WU Vienna and TU Wien, teaches on LinkedIn Learning and speaks at events like WeAreDevelopers, Data Modelling Zone, London Tech Week, Data Science Conference and GITEX. He co-authored Handbook Data Science & AI and is writing The Data Products Series.

Karl Ivo and Mario Meir-Huber are co-authors of “Finance-Grade Data & AI Products: The VANE Loop Framework”, Jan 2026, available at Amazon and vaneloop.com/book