Kin Lane, a prominent API industry analyst and co-founder of Naftiko, has issued a stark warning: the substantial financial reckoning for the widespread adoption of artificial intelligence is imminent. This impending bill arrives on the heels of a long-overdue tab that has been accumulating for nearly a decade, as the unchecked proliferation of APIs and applications has outpaced businesses’ capacity to comprehend, govern, or accurately cost their technological creations.
"I was getting people to care about it for APIs and API management," Lane shared with The New Stack. "Then AI slammed into us, and all that was forgotten." As organizations worldwide are rapidly channeling vast resources into AI initiatives with a mounting sense of urgency, a foundational reckoning that has been brewing for years is now playing out on an exponentially larger scale and at an accelerated pace.
Lane draws a direct parallel between the current generative AI rush and the early days of cloud migration. He observes that companies possessing robust engineering foundations, well-defined domain-driven design architectures, and psychologically safe, agile cultures navigated that transition with relative ease. Conversely, those lacking these critical elements struggled significantly. This unchecked technical proliferation fosters an environment ripe with hidden liabilities—an issue previously highlighted when examining the necessity for organizations to meticulously map their API landscapes to avert potential agentic AI disasters. Without a clear understanding of these foundational layers, businesses are attempting to construct their future on an unstable and unpredictable base.
Bridging the Engineering-Business Divide
To comprehend why the financial outlay for AI has become so opaque and difficult to track, Lane points to the persistent chasm that exists between engineering and business departments. "There has been an IT-business divide for most of this century," he stated. "Business people throw requirements over the wall. Engineers build things, but they are often very disconnected from the customer."
While agile methodologies can offer solutions, they are frequently implemented in a "faux-agile" manner, where business and software teams lack a shared vocabulary. This communication breakdown results in engineers struggling to articulate technical challenges in terms business stakeholders can grasp, and vice versa. "I go into a lot of business groups that don’t know what their engineers are saying or doing, or have any bridge to connect the dots," Lane elaborated. "Engineers are resistant to anything business-aligned, and business people are resistant to opening up GitHub to see what’s going on."
Engineering Observability vs. Business Observability
This disconnect extends to tooling. While platforms like GitHub are a symptom, another critical area is observability and traceability. Current tools excel at providing software engineers with insights into uptime, error rates, and security threats. However, they offer little to no value to the business in terms of crucial financial and strategic information: What is the cost of running this system? What tangible value is it generating? What are the environmental impacts? Which specific customer segments does it serve?
The absence of answers to these fundamental questions stems from a historical failure to build the necessary tools and cultivate the requisite culture. Without this visibility, a true understanding of the total cost of ownership for operating APIs, let alone the complex world of AI, remains elusive for most organizations. "I think that’s what has allowed AI to run so rampant for so long," Lane posited. "No one’s been calculating the cost." This lack of insight directly contributes to the broader systemic issue of "API sediment," where forgotten and unmonitored legacy layers stifle innovation and silently drain corporate resources.
Lane advocates for an expansion of technical observability rather than its replacement. "You should see dollar signs and customer sectors, lines of business, and products, instead of error rates and technical details," he argued. "You should have more of a product view, not just a Kubernetes ops observability view."
Business observability, as defined by Lane, shifts the focus from infrastructure to tangible business outcomes. It involves aggregating spend and usage data by relevant domains such as product, customer segment, sales pipeline, or support functions, and presenting this information in a format that business stakeholders can readily interpret and act upon. The ultimate goal is to render the work of engineers more transparent. This is not merely a user experience enhancement; it necessitates a fundamental shift in ownership of the underlying vocabulary and in what data is tagged, tracked, and surfaced.
Lane expresses optimism that AI itself can serve as a crucial bridge to overcome this translation gap, acting as an interpreter between engineering telemetry and business language. "I’m hoping that AI can help us create this vocabulary for traceability and give those business stakeholders the ability to interact with, evolve, and tailor it to what their businesses need," he stated.
The Taxonomy of Traceability and Context Engineering
The mechanism that underpins business observability is tagging—specifically, the practice of embedding structured metadata within HTTP headers. This ensures that every API call, every model inference, and every token consumed carries vital information about its business context. Lane draws an analogy to UTM (Urchin Tracking Module) campaign parameters, the tagging system used in marketing analytics to attribute web traffic to specific campaigns, channels, and messages. "You need a similar strategy for traceability," he asserted. "How do you build these headers, and how does it group downstream in ways that matter to the business?"
While technical traceability tags are designed for system health and routing, business traceability tags are intended for cost centers, product domains, customer segments, and revenue lines. When aggregated, these tags empower organizations to answer critical questions such as: What is the cost of serving this particular customer? What proportion of our AI expenditure can be attributed to this product line? Is this business domain generating more value than it consumes?
Lane emphasizes that this tagging vocabulary should not be solely owned by engineering. "Engineers are going to lean towards those ops observability needs. We need sales, support, customer pain points, and all the problem statements associated with products," he explained. The taxonomy must be owned and governed by the business domains it represents, with domain experts defining the terminology. This approach aligns with established domain-driven design principles, treating the enterprise as a collection of bounded contexts, each with its own stakeholders, language, and accountability. This structured discipline is a prerequisite for comprehensive risk mitigation in agentic AI, as autonomous agents cannot be safely deployed if businesses lack the ability to trace or bound their operational guardrails.
Applying domain-driven design to AI also addresses a significant security challenge: over-sharing. As explored in previous analyses on maximizing existing API investments through context engineering, the default instinct when deploying autonomous systems is often to expose an entire platform’s API surface to an agent. Lane, however, advocates for strict "context engineering" through Model Context Protocol (MCP) boundaries. By restricting an agent’s access to only the specific tools, operations, and read/write permissions necessary for an immediate business capability, companies can safeguard their data while sharpening agent focus. Precedents for structured traceability at this level can be found in standards like GS1 Global Traceability Standard and architectures such as the Common Architecture Language Model (CALM), though the application of these frameworks to AI expenditure is still in its nascent stages.
FinOps in the Age of AI
While standards and tooling exist for calculating infrastructure costs, the practice of FinOps—bringing financial accountability to cloud spend—is often underutilized and poorly integrated with business context. Lane identifies three converging streams of FinOps activity: SaaS management (which services are being used and their per-user cost), container and compute costs (the expense of running infrastructure), and cloud billing (ensuring cloud spend is under control). AI introduces a fourth, highly complex dimension, with costs that fluctuate based on the specific model, token usage, tier, and API call volume.
"If you don’t have FinOps in place for your models, clouds, and AI services, they’re going to be taking advantage of you rather than you managing them," Lane warns, drawing a direct parallel to the early cloud era. "Everyone said the server bill was going to be much cheaper in the cloud. Fifteen years later, your bill is 10x what it used to be. AI is going to be 100x that."
In response to this challenge, Lane has begun developing machine-readable FinOps profiles for the APIs and AI services that organizations utilize. His project, FinOps Focus, which aligns with the FinOps Foundation’s FOCUS specification, meticulously documents pricing models, usage tiers, and rate limits in a structured, programmatically accessible format. Achieving this level of programmatic precision necessitates standardized data contracts. This is where tools like JSON Schema for AI reliability become indispensable, providing the predictable, machine-readable validation structures required to audit these intricate transactions.
"They’re not going to do it for us," Lane states regarding vendors. "You need to budget and project your spend without relying on your vendors to give you the right answer, because they won’t."
The MCP Problem: A New Wave of Sprawl
Lane’s concerns extend beyond existing AI services, as he observes a new wave of sprawl emerging through MCP (Model Context Protocol) servers. "We just unleashed all these MCP servers, and there’s no documentation solution for it. So we created this whole wave of API sprawl that we can’t see, but we have to support and sustain." He clarifies that "MCP is just an API—a long-lived HTTP connection serving up JSON. We’ve been doing that for years."
However, the architectural dynamics have fundamentally shifted. For the past fifteen years, API design was primarily outward-facing, built for a predictable stream of human developers. Agents invert this paradigm entirely. "Your API consumers aren’t just Bob and Fred," Lane explains. "You have a DDoS of these agents. The Matrix sentinels are trying to get in, rather than you trying to get out. That reversal in polarity is a big shift."
Organizations that have treated OpenAPI specifications as an afterthought will find managing this influx of agentic consumers exceptionally challenging. An OpenAPI specification should not merely serve as documentation; it is the machine-readable "menu" from which agent skills are dynamically derived. A company’s readiness for this can often be gauged by a surprisingly simple proxy: whether it maintains a mature public or partner-facing API portal. These portals represent an internalized muscle memory for access control, rate limiting, and semantic clarity. Companies lacking this framework often encounter significant political friction and operational anxiety when compelled to adapt to the demands of autonomous agents.
What Comes Next: Building for Solvency
Throughout this discussion, the critical importance of foundational work has been underscored: mapping the service landscape, implementing tagging for traceability, governing spend with FinOps discipline, defining data contracts, and establishing domain boundaries before sprawl becomes unmanageable. "You can’t see what you don’t map out and define as artifacts," Lane asserts.
For enterprises finding themselves behind the curve, the situation is not insurmountable. Late adopters possess a distinct advantage: they can bypass decades of legacy database debt and construct clean, modern data pipelines directly with cloud-native gateways and contemporary data warehouses like Snowflake.
Ultimately, AI rewards consistency over reactivity. The enterprises currently thriving are those that made seemingly unglamorous, yet compounding, investments in governance, schema validation, and documentation standards years ago. As Lane observes, "The deeper your roots, the less you’re likely to respond in a knee-jerk or emotional way."
Lane anticipates that business traceability will eventually compel the integration of spending, ROI, and business outcomes into the same framework as infrastructure decisions. However, this crucial conversation typically does not occur until the invoices arrive. "That’s going to be in the next three to five years with AI," he predicts. "We just spent a crazy amount of money on this. What was the ROI? That answer doesn’t exist yet."
"Technical observability has kept the lights on; business observability is what will keep the enterprise solvent."
For organizations aiming to proactively address this impending reckoning, the path forward is clear: map the complete internal and SaaS landscape, implement machine-readable FinOps accounting, embed business context headers into every token transaction, and ensure that the domain vocabulary is owned by the business itself. Technical observability has kept the lights on; business observability is what will keep the enterprise solvent.
