tl;dr
AI made reasoning, orchestration, and translation abundant. Capability by itself is no longer evidence of a durable company.
The key diligence question is where “correct” lives: in the model, in the customer’s existing systems, or in a record the company is building itself.
The interesting companies institutional memory from durable records that a competitor cannot recreate from the same models and connectors.
I’ve been thinking a lot about grammar recently. Not because of the watermarking or AI checker hoopla, by the way.
It’s actually because I’m realizing grammar is a really useful lens to apply to applied AI startup pitches.
A lot of the language sounds concrete until you ask whether the noun names an actual thing or just work the software performs.
Take this very common premise:
“We are the reasoning layer across the enterprise.”
It is becoming a common description of AI companies, and an increasingly uninformative one. You can pull up an invoice, a claim, a contract, a payment, or a ticket. You can say who owns it, where it lives, which system is authoritative, and what breaks if it disappears. Reasoning has none of those properties. It describes work being performed rather than anything the work produces.
That distinction used to matter less. If a company could reason across several messy systems, normalize their data, resolve inconsistencies, and take action, there was usually substantial infrastructure underneath the claim: integrations, custom logic, implementation work, and people handling edge cases. The capability itself told you something about the company.
So what changed?
Real quick, some awesome news—Forward This is presented by Ambart Law, our newest community partner. Learn more here:
You guessed it. Those two letters. AI.
AI changed the relationship between the capability and what had to be built to deliver it. A company can now perform sophisticated work over systems it barely controls. The product can be useful, the demo can be excellent, and the customer can be happy without the company acquiring much ownership of the workflow underneath it.
So the question I care about has shifted. After the reasoning is done, what exists that did not exist before?
What sits underneath the reasoning
Take a product that handles deduction disputes. It pulls a dispute from a portal, checks it against the order, decides whether the exception is valid, routes the case, and posts an adjustment.
At the top is orchestration: moving work through systems.
Underneath is reasoning: deciding which record to trust, which exception matters, and what should happen next.
Both can be valuable. Both are also increasingly available to another company with comparable models and connectors.
The underlying context is more concrete. The order history, contract terms, payment behavior, prior disputes, and account record all exist somewhere. Usually they belong to somebody else. The ERP owns the invoice, the CRM owns the account, and the retailer portal owns the deduction. The AI company gets permission to read them.
That means a surprising amount of the product can be assembled from things the company neither created nor controls. The orchestration is built through integrations. The reasoning comes from a model. The context comes from read access.
The interesting question is whether anything accumulates beyond those inputs: a durable account of what correct looks like inside this particular institution.
That is different from a policy document. Policies describe what is supposed to happen. The useful record is built from what actually happened: which decisions worked, where practice diverged from the written rule, which divergences were mistakes, which became accepted practice, who made the call, and what happened afterward.
That knowledge cannot simply be fetched from the ERP or inherited from a frontier model. It has to accumulate case by case.
Where the standard comes from
When a product makes a judgment, there are a few places the standard behind that judgment can come from.
Sometimes it comes almost entirely from the model. The company combines frontier-model priors with a prompt and enough context to perform the task. The work may be good, but another team can access the same underlying capability. If the reasoning disappears, it can usually be regenerated. What matters most in that business is execution: distribution, implementation, product quality, and speed.
Sometimes the standard already exists in the customer’s records. The company reasons over policy manuals, contract terms, ERP objects, payer rules, and other material the institution already maintains.
An invoice-to-cash product can have excellent adjudication logic while every important object remains authoritative elsewhere. The invoice lives in the ERP, the remittance comes from the portal, and the ledger entry lands in the general ledger. Switch the product off and no record disappears. The work gets slower and worse, which can still support a good business, but the customer has not lost the underlying record of what happened.
This position also creates dependence on whoever owns those records. With physical assets, that dependence is obvious. Nobody assumes a company can become the software Teslas run without Tesla’s cooperation because the asset is visible and clearly owned. Software obscures the same relationship. A company can look deeply embedded in a workflow while its position still depends on access to objects controlled by somebody else. A dispute record has an owner just as surely as a car does.
Recommended for you:
How a very small product can contain a very large company
tl;dr Transmission separates rituals from habits. A habit dies with the person; a ritual belongs to a role and outlives whoever holds it.
The more interesting case is when the product creates the standard it uses.
Consider a company that captures debriefs after consequential events, synthesizes the participants’ accounts into a structured record, and compares that record with written policy. Each event creates a new piece of institutional memory. Over time, the records show where doctrine and practice diverge, which deviations were mistakes, which were improvements, and how the organization actually responds under real conditions.
Two hundred of those records are more than two hundred transcripts. They describe something the institution previously did not have in durable form. The knowledge lived in people’s memories, spread unevenly across teams, and disappeared with turnover.
If the product becomes the place where that history accumulates, the company owns something meaningfully different from the model reasoning over it. A competitor can connect to the same source systems and use the same models without recreating the record, because the events that produced it have already passed.
That is the case I want to find.
What survives if you unplug it
The easiest screen is still what happens when the company disappears.
If nothing specific disappears, the company is primarily selling a capability.
If the important records all survive in other systems, the company has built a workflow around someone else’s property. That can be valuable, sticky, and difficult to replace, but the source of authority still sits elsewhere.
If an accumulated record disappears, the situation is different. The company may be creating a new system the institution starts consulting because it contains knowledge that exists nowhere else.
That does not automatically make it a good company. A dispatch schedule is a perfectly concrete object with discrete instances and a clear custodian, and the business built around it can still be terrible. The record may be tied to an asset somebody else owns. An incumbent may control distribution. Customers may simply not care enough about it to switch.
A newly created record can also remain peripheral forever. It can accumulate without becoming authoritative. It can be useful without becoming critical. It can sit inside a workflow the customer can recreate elsewhere.
So this is only a screen. Once the object appears, ordinary underwriting begins. Who uses it? Who refers back to it? Does it improve as cases accumulate? Does the institution start trusting it? What becomes difficult to reconstruct if the company disappears?
What the work leaves behind
This distinction matters beyond reasoning products.
Middleware used to derive much of its value from translation. Moving information from one system into the format another system expected required parsers, mappings, connectors, and accumulated integration knowledge. Models are making more of that translation cheap.
The middleware businesses that remain durable tend to own something beyond translation: state, guarantees, audit history, responsibility, liability. Visa does not become irrelevant because a model learns to format a payment message. The important part of Visa is the network and the transaction state, rules, and obligations around it.
The same applies to service-as-software. Performing a service repeatedly becomes more interesting when each performance leaves behind something durable: an adjudication history, an exception record, a prepared file that captures how unusual cases were handled. After two hundred cases, the company may hold something a new entrant cannot reproduce merely by connecting to the same systems.
AI is making capabilities abundant. That does not make every company offering those capabilities identical. One may be selling execution over systems other people own. Another may become deeply embedded without ever controlling the authoritative record. A third may quietly create a record the institution starts depending on.
The pitch tells me what the company can do.
I want to know what is left after it does it.