In this post, I will now list the key anti-pattern in my mind that’s a consequence of shallow product thinking in the world of LLMs and autonomous agents. I will also, based on my understanding of this anti-pattern, make my case for why context-heavy and domain-specific flywheel building is the real unlock for product companies.

Everyone was Wrong About the Interface

Soon after the consumer mainstreaming of ChatGPT and Claude apps had taken place, two prognostications started crystallizing in product circles around enterprise AI -

1. while the model-core might be intelligent, the chat-only interface must be a limitation for some use-cases, and
2. while the model might be eloquent, there’s value in extending its knowledge beyond the training data to bring to it up-to date world information.

Over the course of the next couple of years since 2023, both these notions seemed to fall flat, albeit due to different misreading of the development curves.

In relation to the chat-only interface, customers, including engineers in enterprises spoke loud and clear in their propensity to adjust their workflows to the text interface, rather than shunning the tools due to a lack of integration into existing enterprise work-horses, e.g. MS Excel or Salesforce. If anything, the enterprise SaaS vendors found themselves flat-footed when trying to get the same users to adopt shabbily bolted-on GPT wrappers onto their interfaces, who quickly found a new home in Claude artifacts, because it was never as much about the interface but the intelligent core itself.

Then there were the packaged “AI-native” vector databases sold as the enterprise search solutions that also missed the point: it turns out that agentic systems using BM25 but built close to the business logic layer can match or outperform pure vector search at scale, at a fraction of the migration+operational cost of vector databases all while being extremely flexible, understandable, and extensible, i.e. actually taking search seriously.

Forget the Model, Build the Context

All of that to say that the intelligent core is the only indispensable unit. So, how can a plucky startup even begin to create an LLM core to surpass general ones from the world-leading labs? The answer is - they don’t have to.

What they need is a context engine that grows over time, and a mechanism to "pattern match" on the growing context at inference time.

Agents allow an arbitrary level of control over a company-specific workflow AND validation steps necessary to get a particular job done. While designing such workflows might be trivial, creating a flywheel of continuous learning “on the job” is the real unlock.

The best way to understand this pattern is to first make sense of its anti-pattern, i.e. what not to do. Shallow product thinking, one written without a real persona in mind, will quickly settle at a product offering (or if you’re really unlucky - a drag-and-drop graph UX) where

1. the atomic sub-agents are so generic that they now have only a distant relationship to your user’s day job. Example - PDF extraction agent
2. the users are now in total control of how the sub-agents should be composed to actually accomplish a task.

By the fact of being both generic and infinitely composable, you lose the ability to tightly integrate a feedback loop into your context engine (because, context engine of which agent?) and, therefore, can never build a flywheel of improvement and user satisfaction.

As any good product manager will attest - to delight users, it is not enough to paint with broad strokes but really focus on a few user personas that really obsess you. And the way to delight these few personas is to think of (and encode) the jobs that they really have to do, instead of the smallest atomic units to get there.

Let’s make this proposal concrete with an example agentic workflow that sees its capabilities compound over time.

SOC2 compliance agent for mid-size scale-ups

A B2B SaaS company (~200 employees, Series C) is preparing for its first SOC 2 Type II examination, having already undergone an ISO 27001 audit the previous year. The CISO has four weeks, a two-person security team, and a stack of 100+ policy documents, risk assessments, and evidence artifacts from last year’s audit.

What the workflow-builder approach looks like

Atomic agents serving as building blocks:

1. Document classifier — sorts all the 100+ documents into categories (policies, procedures, evidence, risk registers)
2. Control mapper — maps ISO 27001 controls to SOC 2 criteria, resulting in a cross-reference matrix
3. Gap finder — compares current policy documents against control requirements, flags missing keywords
4. Evidence checker — verifies that each control has at least one linked evidence artifact

The expectation is that the platform user (CISO) can build their own workflow using the building blocks. The output of a typical built workflow: a multi-page cross-reference matrix with hundreds of ISO controls mapped to some SOC 2 criteria, some “gaps” flagged, and a final list of criteria requiring evidence. The CISO now has to manually verify every gap, figure out which ones are real, and address those with new evidence.

What the job-level agent actually does

The fundamental misunderstanding is that the job of the CISO is “map controls and find gaps.” However, their job actually is: produce an audit-ready evidence package that shows exactly what’s covered, what’s missing, and what needs remediation before the audit.

We transfer therefore the core workflow of a CISO into “agentic” units as follows:

Step 1 — Control mapping with contextual understanding (not keyword matching)

The agent loads last year’s ISO 27001 control mapping as its starting point. It already knows, e.g., that one of the available documents was used as evidence for cryptography control, and was validated by the auditor. Therefore, instead of re-mapping all the ISO 27001 controls from scratch, it only asks “what has changed functionally from last year’s ISO audit?”

1. If the change is in the policy document itself, that’s the only delta that needs to be handled by the agent.
2. If the change is in the SOC2 criteria definition, such that it cannot be mapped to existing and audited ISO 27001 controls, that’s a new requirement in terms of documentation that the agent should flag.

A job agent designed in this way will build an improving flywheel of up-to date document evidence for both audits, and gets more and more useful over next audits. An atomic agent using embeddings for classification, on the other hand, will likely miss the fact that the document “Use of Cryptography” from ISO 27001 audit can also fulfil the SOC2 criteria of “Logical access security”.

Step 2 — Validation of evidence

While the workflow builder will check if each ISO 27001 control has a linked evidence - and map the evidence to the corresponding SOC2 criteria, it will miss the remediation applied on any gaps during last year’s audit because there’s no “learning from experience” involved.

A job-level agent won’t just check for what’s missing. Instead, for every linked evidence that was flagged for remediation last time, it has recorded

1. the fact that it was flagged by the auditor
2. the remediation applied to clear it

The agent then tries to replay the remediation step pro-actively. E.g. Say, last year’s audit flagged a Github repo not having dependabot or another vulnerability scanner turned on. If, since last year’s ISO 27001 audit, there have been new repos created in the account, a job-level agent will double check if dependabot is enabled for those before the auditor arrives. This builds another flywheel that strengthens the agentic system the more it gets employed.

Step 3 — Prioritized remediation plan

While the gap-finder step of workflow builder does produce a flat list of gaps, it doesn’t prioritize the gaps at all, other than having a rough estimate of the step-level difficulty.

A job-level agent, on the other hand, prioritizes the gap list, ranking those items higher that pattern-match recurring gap(s) from past audits, or those that, when fixed, would simultaneously address multiple gaps in SOC2 criteria. E.g. If since the last audit GCP was added as a new CSP to the stack, then the job-level agent will flag cloud security standard gap as “CRITICAL”, just because it remembers from past audits that a similar gap on Azure was flagged by the auditor.

Job-level agents are already at an advantage by this step, as they have gathered a contextualized list of gaps compared to an atomic agent. As you can see from this concrete example, a job-level agentic system, while requiring upfront investment in encoding real workflows, compounds its value over time and makes itself indispensable at a time when all the chatter is about replacing CRUD SaaS applications with “vibe-coded” in house alternatives.

Closing the Arbitrage Gap

When employees report that they’re using commercial chatbots at their own expense, it’s clear that it is the intelligent core of the chatbots that they’re after - not a GUI. The big chasm between individual-level and enterprise-wide adoption is the reliability of an experienced employee - the drag-and-drop workflow builder is never going to close it. It’s the tricky decisions that enterprise employees make that don’t follow a rule-book, but are nonetheless their own kind of implicit pattern, how employees make themselves indispensable, not the amount of time they spend grunt working through documents. If the product roadmap choice is between - a workflow builder UI with “atomic” agentic steps offered as building blocks vs. consciously sketching out core workflows, the shortcut of the former is not a wise choice at all.

Encoding step-by-step decision processes, tasks and transformations as agentic logic, but crucially also tracing actual workflow runs in practice, recording all unsuccessful workflow runs and manual overrides to inform subsequent decisions gives the builder an unmatched context engine that keeps their customers from churning.

Build what Compounds

The moat is a continuously learning system of domain-specific decision patterns that no competitor can replicate without running through the same volume of real cases. In building with AI in 2026, your product is either getting measurably smarter with every interaction, or it’s a feature waiting to be vibe-coded away.

While there’s a lot to unpack and opine subjectively on the study (especially considering that the sample used in the study is only 52 companies), I’m going to use this single finding that I find the most interesting, as a jumping-off point to this series of articles

“While only 40% of companies say they purchased an official LLM subscription, workers from over 90% of the companies we surveyed reported regular use of personal AI tools for work tasks.” State of AI in Business 2025, MIT NANDA

That should not be surprising to any of us who are outside research settings. Anyone who has worked in a company larger than 20 employees has, at some point, run into this scenario - there’s a new LLM or coding agent in town, you’d like to put a credit card on file to start and feel around the vibe of the tool before making a decision to switch, but getting your request approved by management is so cumbersome that you end up using your personal CC for trying out. You might defer the official request until later, if you even expect that the request won’t be turned down eventually due to data provenance reasons.

But what is remarkable about this finding is the stark contrast it puts against the official initiatives that enterprises undertake with generative AI in general, and LLMs in particular. In addition to the 40% figure of companies purchasing official licensing, there’s of course the famous 5% figure that refers to companies that report profitable and sustained production implementations with the technology.

In this article, we will use the MIT study itself, but with a quantitative breakdown, to answer the question

In particular, we will examine three critical aspects related to enterprise generative AI adoption -

1. Why the inference economics actually favour model providers at the current pricing already?
2. Where the real adoption of generative AI is happening?
3. What capability gaps exist that explain the divide between individual and enterprise-level AI adoption?

In the follow-up articles in the series, we will then go on to deduce how enterprises can assess whether their planned generative AI POCs are likely to succeed or fail, based on the use-case categorization of the MIT Nanda study.

The Silicon Floor

When we distinguish between “consumer” and “enterprise” use-cases of LLMs, the temptation is to compare ChatGPT-like applications to the early days of Uber and Zomato - that the main objective must be to capture market segments at all (VC’s) costs, avoid commoditization and only then aim for profitability. However, one only needs to work through the economics of LLM APIs to see that what we’re witnessing today is anything but comparable to the gig-economy days. In this section, we will quantitatively show that model providers are, in fact, well on their path to profitability on their consumer products, if not already there.

The capex view of Llama3’s training costs. For full analysis can be found here.

While training costs for LLMs are substantial - our analysis shows Llama 3 herd of models required between $197M-$748M in total development costs when including experimental runs, infrastructure, and electricity costs - these represent one-time expenses. For API providers, the inference costs far outweigh training costs. This has been corroborated directly by several credible sources, such as Yann LeCun who said in context of the erstwhile media frenzy over Deepseek

“The huge sums of money going into US AI companies were needed primarily for inference, not training AI. Most of the infrastructure cost for AI is for inference: serving AI assistants to billions of people.” Yann LeCun, Chief AI Scientist at Meta

With this in mind, in the rest of this section, we’ll just go ahead and assume that the cost of inference (runtime serving costs - GPU rental or own-cost amortization, power, cooling, datacenter cost) is the main driver for deciding operating margins for model providers, such as OpenAI and Anthropic, and not training. This may, of course, not hold true for business models other than model-as-an-API, but we’ll come to alternative business models for foundational companies at a later point.

OpenAI’s estimated profit margins on ChatGPT consumer app alone. The costs are for COGS only. For details refer to the full breakdown.

As for the economics of LLM inference, a definitive answer as to the model providers’ economics is hard to come by. Various sources claim different numbers on total cost of ownership of models and serving infrastructure, and the major sources of contention are

1. Whether there are enough paid monthly subscribers to cover the inference cost for free users
2. Whether there are enough low usage paid subscribers subsidizing the costs for heavy users
3. Whether there are enough consumption-based API users (e.g. coding agents) where the costs and earnings are easier to attribute than monthly subscriptions.

Our own calculations, using Deepseek-v3.1 MoE (37B active params) as proxy for SOTA closed models, paint an ambiguous picture about potential revenues and margins for top model providers such as OpenAI and Anthropic. Assuming a reported ~190–200M DAU for ChatGPT, we estimate that OpenAI may be spending between 300 to 700M USD per month on inference for their chat app users. Assuming 10% of those DAUs are paid users, they might be earning a monthly revenue between 350 to 400M USD. This indicates that, with tailored optimization strategies per user-segment, OpenAI might either already be profitable on ChatGPT app, or close to getting there.

For API customers, the economics are somewhat different: developers and enterprise clients paying ~$10 per million input tokens and ~$20 per million output tokens may provide gross margins ranges between -50% to 70%, making the API business a lever for OpenAI and Anthropic’s to cross-subsidize their consumer application business, if needed.

A detailed breakdown of all our calculations may be seen here. Additional sources of non-service revenues that we haven’t included in our analysis are the revenue share that OpenAI and Anthropic might earn on their enterprise inference deals with Azure (Azure OpenAI), AWS (Bedrock) or Google (Vertex AI Partner Models).

Therefore, even assuming considerable deviations in the reported usage data and model details, the economics of GA inference currently favour the market leaders in generative AI. OpenAI, Anthropic, Google Deepmind and such, for all we can observe, have not made any major moves to squeeze their margins yet, which should indicate how different these dynamics are to the gig economy days.

The “Shadow Economy” Paradox

As we have seen above, the major foundation model providers can already provide access to generative AI technology profitably to millions of users worldwide. In fact, our calculations reveal that had it not been for the incredible demand for these model APIs, the model providers may never have been able to operate profitably, i.e. the economy of GPU utilization works out for them only due to the scale.

It would be fair to say that a major chunk of the daily active users of these chat-style applications are employees of the very enterprises that report little to no gains in efficiency with generative AI (more on that soon).

What I find remarkable about this figure is that a significant share of employees reporting productivity boost with tools such as ChatGPT are using their private subscriptions to these services, for professional purpose (the “shadow economy”). The reason this fact is remarkable is that these employees have wildly different feedback for the task-specific generative AI tooling and solutions that their own companies were developing at the time.

“A significant number of workers already use AI tools privately, reporting productivity gains, while their companies’ formal AI initiatives stall.” State of AI in Business 2025, MIT NANDA

In summary, the foundation model providers are already profitable off the back of the day-to-day productivity increase of employees of the same companies, whose own custom AI tools largely suck.

So, why don’t these enterprises just let their employees use company credit cards for Claude, instead of sinking millions into failed custom generative AI tooling?

The Real Adoption Barriers

It should be clear to the readers that it is not due to a mismatch in the fundamental model economics, training-time or inference-time, that only 5% of the enterprises deploying generative AI pilots end up extracting regular and sustained business value out of them. The MIT study itself points to technological gaps that are, in fact, to blame.

The study assigns an overarching term to this identified gap in LLM-based applications - “The Learning Gap”. Basically, the LLMs - and precisely not the chat apps - suffer from the following glaring insufficiencies that make them unsuitable to be used as trustworthy task-specific companions, experts or - in terms that we’ve all come to accept - “copilots”:

1. The LLMs themselves don’t learn over time from the users’ feedback.
2. As a corollary to the above, the LLMs require too much context to be supplied every time, and there isn’t a straightforward and effective way for the right context to be dynamically chosen based on the task-at-hand (👀 vector search).
3. Even if the LLM-based workflows complete tasks without intervention most of the time, they break for edge-cases and don’t learn from these failures. Since, by definition, these edge cases are more complicated to define and expect, the overall trustworthiness of the LLM-based tooling suffers as a result.

“Our purchased AI tool provided rigid summaries with limited customization options. With ChatGPT, I can guide the conversation and iterate until I get exactly what I need. The fundamental quality difference is noticeable, ChatGPT consistently produces better outputs, even though our vendor claims to use the same underlying technology.” - Corporate lawyer at a mid-sized firm quoted in State of AI in Business in 2025, MIT NANDA

Enterprise employees, being well-versed in current SOTA tools and models, are able to successfully augment their own job functions precisely because they don’t expect ChatGPT et al. to retain feedback, or improve over time. We could go as far as to suggest that employees don’t consider AI chatbots to be replacements for any level of expertise in their job functions - not even interns.

This is in stark contrast to ambitious enterprise generative AI pilots, whose stated aim often is to directly augment their workforce. Such pilots then, obviously, lead to total disenchantment since the technology clearly is not able to accumulate knowledge over time, retain relevant context (and, importantly, decide which context needs to be chucked away), and basically train itself on the job like a junior or associate-level employee would.

As it stands, SOTA LLMs don’t stand a chance at getting promoted in the next appraisal cycle.

The Opportunity

So how are enterprises and startups going to respond to these key challenges (profitable TCO not being one of them) that make it difficult for generative AI initiatives to succeed? In the next articles, we will discuss some concrete failure patterns that companies regularly run into such as lost opportunity costs of fine-tuning LLMs, and applying LLMs only for low-leverage job functions. Then we will make direct suggestions based on current research and available enterprise adoption data, as to how one should prioritize use-cases that are well-suited to be augmented with SOTA LLMs.

“What can we engineer that makes us the most money and sustain?” vs. “I love this thing I made, I’m sure there’s someone out there that finds it cool”.

I’m probably being unfair with the “makes money” part (disclosure: I work on commercial software all day), but you get my drift - feel free to replace it with “gets the most users to stay” or “gets the most word out” etc.

However, all that is not to say that one culture of development is better than the other, but I do think that acknowledging the difference is important for developers and aligned personas to appreciate different motivations better. While the former leads to coherent product experiences, the latter leads to crazy (good) experiments, creative masterworks and worthwhile alternatives to drab experiences.

This article won’t go into any business use-case specific assumptions, obviously, but the following are the bare minimum in terms of data quality metrics that you should put in place, and automate, at the end of your ETL pipelines and inference endpoints.

1. Null values: Whether there are missing values in fields where there shouldn’t be any.
2. Casting of values: Whether the input data flows in in a format that your casting operations can’t handle, e.g. string “1.0” can be cast into floating point, but “1 point something” cannot be.
3. Fill rates: For sparse feature matrices, an overview of column fill rates is important, especially how it has evolved over the time since your model was last trained.
4. Timeliness: If models are trained periodically upon availability of new ground-truth data, then a timeliness check is what allows data scientist to track whether all the expected data was updated, and to what degree, at the expected intervals.
5. Historical consistency: As a final check, historical consistency should give an indication of whether any qualitative aspects of the data have changed over time, e.g. has a numerical field always been delivering integer values or have the sources been recently delivering floating point values instead - denoting certain new assumptions about the data.

Security, in this article, is probably a catch-all for a lot of related but, theoretically speaking, distinct concepts such as robustness, safety, and adversarial-proof machine learning systems. If we use the artifact-based approach to software engineering, security for machine learning systems should focus on these main artifacts -

1. Training data
2. Trained models
3. Inference endpoints or APIs

Training data, especially when sourced from ELT pipelines and automatically labeled, can be the first source of poisoning if, either meaningful data quality metrics are not set-up and visible (more on this in a later post), or if active-learning is set up where adversarial edge-case inputs are added to the training datasets without correcting the labels first.

Trained models can further add to the attack surface of an ML-system when it is not updated over the course of business use-case serving, and they drift due to the initial assumptions about the independent variables or problem statements not being valid anymore. Moreover, it can be argued that deep models whose outputs cannot be sufficiently explained, can be hard to debug and are a compliance and security liability, in themselves.

Inference endpoints, typically in the form of Rest or GraphQL APIs, may, in addition to being vulnerable to common software vulnerabilities, also be susceptible to being abused by, e.g. training proxy models by attackers or inferring on adversarial inputs.

“a design concept that serves as an integrated layer (fabric) of data and connecting processes”

– Gartner

It even places itself as a sibling to the data virtualization idea - that proposes a “logical” data layer on top of disparate sources, where data resides in varying formats. While most data fabric providers promise the world at the click of a button, it remains the case that most businesses need to use a semantic engine on top of their original sources, in order to run meaningful data analytics. These semantic engines are what ultimately often plug into an org’s data lake pipelines and feed into the data fabric, that is able to keep the data fresh for quick analytics.

Creating a domain- or org-specific AI-driven data integration strategy from scratch (and it often need to be from scratch) sounds frightening, especially given how prolific the development in vector-search space has been recently. For D&A teams, this often means top-down mandates and project charters talking about digital transformation, breaking of department-silos, machine learning capabilities, question-and-answer capabilities yada, yada, yada.

But I’m here to tell you - you’ve got this. And the reason I say this is because, unlike what the hype tries to make you believe, most data integration layers are built using domain-specific, time-consuming and heavy transformations to even bring their original sources to a state that they can index it in a Lucene-based text search engine. And while that might not seem impressive if you’re on data management LinkedIn too much, it is enormous when it comes to solving your organization’s specific needs and maybe even create new business models.

It isn’t enough that historical data is digitalized and suitably archived - what matters much more is whether the data is activated. Activated data is fresh (despite being old), malleable, and vocal. Activated data knows what it is.

Semantic web is already a magnificent achievement, in terms of categorizing and standardizing data on the internet. Domain knowledge graphs can even further build upon the semantic web idea to activate data, and enable organizations to make decisions and generate value.

For a discipline whose fundamental building tools are (programming) languages, we, software engineers and statisticians, are notoriously bad at putting metaphors to work - if for nothing else, then to tell better stories with and about (not TO) our products.

“Steam engines increased global productivity by many orders of magnitude…(while)…1970s saw a decline in American national productivity, seemingly reflected in the kind of innovations such as replacing window room air-conditioners with central building air-conditioners.”

– The Second Machine Age: Work, Progress, and Prosperity in a Time of Brilliant Technologies, Andrew McAfee and Erik Brynjolfsson

The quote kept me up a while trying to think of similar examples

“An innovation like eBay, not Facebook”

“An innovation like lamp shades, not Nest”

…