The expert's operating layer

Someone said something to me recently that I have not been able to stop thinking about. We were talking about the AI vertical space; patent drafting, legal review, compliance, clinical documentation, the usual list. And the argument being made was that foundation model companies would eventually win most of these verticals simply because they had the best models. The vertical startups, the argument went, were building on borrowed time. The infrastructure would catch up with the application. The moat was temporary.

I want to be honest: there is something to that argument. It is not obviously wrong. The models are getting better very fast, and a better model genuinely does change what is possible in most domains. I have watched enough early demos of vertical AI products to know that a very large fraction of them are, in fact, doing exactly what the sceptics describe. Same model. Different prompt. Different logo. A horizontal capability wearing a vertical disguise. I thought I shall push back on this more carefully than I usually do. So here we are.

But I think the argument misidentifies what the hard problem actually is.

In most expert, high-stakes, regulated workflows, the hard problem is not generating text. The hard problem is knowing the sequence of judgment. When to ask. When to pause. When to warn. When to defer. What to surface and in what order. When to offer a draft and when to say: I do not have enough information yet to draft anything.

That is a product philosophy, not a model capability. And the two are not the same thing...

I work on eety, which is a patent drafting product. And I can tell you from direct experience that the most important design decisions we have made are not about which model to use underneath. They are about what the product does before it drafts anything. It asks for the missing invention details. It tries to identify the inventive concept. It separates what the inventor did from what they want to protect. It warns when a claim may be becoming too narrow to survive prosecution. It remembers how a particular attorney writes. It drafts, but it expects review. It does not pretend to be the final authority.

That is a very specific product philosophy. It says: the AI should behave like a very strong junior associate, not like an autonomous genius. The attorney remains central. The workflow is rebuilt around intelligence, but the intelligence serves the workflow. It does not replace the judgment at the centre of it.

The distinction matters enormously, and I do not think it is well understood outside of the people actually building these products. There is a version of "AI for patents" that is impressive in demos and actually quite dangerous in practice; the one where the system confidently determines claim scope, chooses what to include or exclude, and presents a finished draft as if the hard intellectual work has been done. Attorneys I have spoken to describe this as the product that makes them nervous. Not because the quality of the output is poor, but because they cannot always see where the confidence is coming from. They cannot tell what the system decided and why. And in patent prosecution, the decisions matter enormously. A claim that is slightly too narrow in the wrong dimension can undermine years of R&D protection. The attorney needs to be in control. The tool needs to know that.

This is what I mean when I say autonomy is not always the feature. Sometimes autonomy is the risk...

A founder building a consumer product absolutely wants an AI agent that can book meetings, summarise emails, and make reasonable decisions without being asked every time. That autonomy is the product. But a patent attorney does not want an AI independently deciding claim scope. A CFO does not want an AI autonomously interpreting tax positions. A doctor does not want an AI casually arriving at treatment decisions. In these cases, the winning product is not "do the whole job." The winning product is "make the expert dramatically better without removing their judgment from the loop."

That is a genuinely difficult product to build. Not because the AI capability is hard, but because you have to understand the workflow at a level of granularity that takes a long time to develop. You have to know where the expert feels safe delegating and where they feel exposed. You have to know what they notice that the AI misses, and what they wish the AI would notice that they currently have to check manually. You have to understand the anxiety of the domain, not just the mechanics of it...

A colleague at a startup in Bangalore told me they had spent eight months building what they were quite casually calling an "AI for finance teams." The product was genuinely impressive technically. The model was good. Rs 2 crore of engineering time. But their first three enterprise customers all told them the same thing: they could not explain to their CFO why the system reached a particular number. That was not a model problem. That was a complete rethink.

I remember the first time a patent attorney sat with an early version of eety and said, after about twelve minutes, something that has stayed with me: "It's helpful. But I'm not sure it knows what it doesn't know." That sentence rewrote six months of our product roadmap. Not because the model was wrong. Because the product wasn't giving the attorney enough visibility into the system's uncertainty. The confidence was opaque. The product did not know how to say: I am less sure about this than I appear.

She was right. It was a problem. And it was not a model problem. It was a product philosophy problem. We had not built the product to communicate its reasoning. We had built it to produce an output. Those are not the same thing, and in a high-stakes expert workflow, the difference is everything.

Actually, I want to come back to something before I move on. The attorney's phrase was not just about uncertainty communication. I keep coming back to it because it is suppose to be the job of the product designer, not the user, to figure out where confidence should be displayed and where it should not. That seems obvious when I write it out. It was not obvious to us at the time.

Now, back to the original argument. Foundation model companies will undoubtedly be very strong in horizontal functions: coding assistants, general summarisation, broad document analysis, first-draft generation of most content types. They have scale, infrastructure, and genuinely improving capabilities across the board. I would not bet against them in any domain where the task is broad, conversational, and weakly integrated with existing systems and workflows.

But I would push back on "undoubtedly" even there. Because even coding is not horizontal anymore, not really. It has already split into IDE-native tools, repository-aware agents, DevOps automation, security review, test generation, and enterprise engineering platforms. Each of those has workflow specificity that a general model, pointed at the task, does not automatically know. The same is true for HR, which has compensation data, compliance obligations, culture and interview considerations, and ATS integrations that matter enormously. Customer support depends on product knowledge, escalation logic, SLA structure, CRM integration, and brand tone in ways that a general model does not automatically get right.

The better version of the thesis, I think, is this:

That is the real dividing line. Not "AI company versus domain startup." The question is: how much of the product is the model, and how much of the product is the workflow, the data model, the domain judgment, the integrations, the review loops, and the customer-specific memory? As that second list grows longer and more specific, the model becomes a smaller fraction of the total product. And when the model becomes a smaller fraction of the total product, the advantage of having the best model diminishes accordingly.

There is a phrase I keep coming back to, which I think captures this dynamic well: foundation model companies are pushing their models up the stack into workflows, while vertical startups are already embedded in the workflow and pulling models down as utility components. Those are two very different starting positions. The foundation model company has to learn the workflow from outside. The vertical company already lives inside it... and has usually been living inside it long enough to know which parts of it are genuinely broken.

That is a genuine structural advantage, if you use it correctly. The risk for vertical companies is confusing access to the workflow with understanding of it. You can have deep customer relationships and still build a product that treats the AI as the point of the exercise rather than the instrument. I have seen this. The AI capability is impressive, the demo is compelling, but the product has not actually reduced the cognitive load on the expert. It has just created a new kind of work: reviewing AI output instead of doing the original task. That is not a win. That is a substitution of labour, not an augmentation of it.

The framing I find most useful, and the one I try to keep coming back to when we are making product decisions at eety, is this:

That framing matters. "AI for patents" tells you what the tool is. "The expert's operating layer" tells you what relationship the tool has with the expert. The professional remains central. Their judgment remains in the loop. But their workflow becomes faster, their blind spots get flagged, their style gets remembered, their time gets protected, and the decisions they make are better informed than they would have been without the tool. The AI earns trust by knowing where it should act, where it should pause, where it should ask, and where it should simply defer...

The cake shop analogy came up in the conversation that prompted all this thinking. The wheat matters, clearly. A bakery without good wheat does not get very far. But the recipe, the kitchen, the chef, the oven, the customer taste, and the reputation built over years of serving specific people in specific ways, those are what decide who actually sells the cake. The wheat supplier does not win the bakery market just by having better wheat. The moat is not in the ingredient. The moat is in what you know how to do with it.

I think the future of enterprise AI will be decided not by the company with the biggest model alone. It will be decided by the company that genuinely understands where the model should act, where it should pause, where it should ask, where it should defer, and how the human expert actually gets their work done. That understanding is hard to acquire, slow to build, and very difficult to replicate from the outside. I am not sure I have fully worked out all the implications of this yet. But I find myself thinking about it quite regularly now.

That is the cake shop. And the wheat, for all its importance, is not the story. :)