The AI product moat is workflow state

In March 2025, our first M&A-native AI product instinct was an "Assign to AI" button.

The user would upload documents, create diligence tasks, and click a button when they wanted AI help. It sounded reasonable because it preserved the product model we already had. It also exposed the flaw. We were designing around the machine's action instead of the buyer's job.

A deal team does not want to assign 300 little tasks to AI. They want the room read, the gaps surfaced, the issues organized, and the evidence attached.

The defensible AI product is the one that owns the state around the model.

The model matters. It just is not the moat by itself.

A model answer is not a workflow

Most AI product demos still collapse to the same shape. Upload a file. Ask a question. Get an answer.

That can be useful. It is also fragile. The answer exists in the moment, detached from everything a real team needs to do before and after it. Who uploaded the file? Which folder did it come from? Has the document changed since yesterday? Which request-list item does it cover? Which reviewer accepted the conclusion? Which workstream needs to see it? Which parts of the room can a clean team access? Which findings should become an issue matrix instead of a chat response?

That is where the product begins.

In diligence, a general model can summarize a contract. The workflow needs more. It needs document inventory, folder context, request-list coverage, issue rows, source citations, review status, permissions, audit history, and exports that match the way legal, finance, HR, IT, and corp-dev already work.

The buyer does not need a smarter paragraph. The buyer needs a system of record for what the AI saw, what it concluded, what a human checked, and what still needs attention.

Workflow state is what the buyer cannot paste into chat

The easiest way to test whether an AI product has a moat is to ask what disappears when the user opens Claude, ChatGPT, or Copilot.

If the answer is "the prompt," there is no moat.

If the answer is the entire operating context of the job, there may be one.

For Colabra, the important state is not a single document. It is the room:

• the file inventory
• the folder structure
• the request list
• the workstream map
• the buyer's review status
• the source evidence behind each finding
• the permission model
• the history of what changed
• the issue matrix the team will actually use

That state is what makes the model useful. It also makes the product harder to replace with a blank chat window.

The blank chat window has to be re-taught the job every time. A workflow product compounds context.

Permissions are product behavior

Enterprise teams often talk about permissions as procurement paperwork. That is too shallow.

Permissions are product behavior.

If an AI system sees a document the user should not see, the product failed. If it produces a summary that crosses a clean-team boundary, the product failed. If it cannot explain which source supported a material claim, the product failed. If it stores sensitive context in a way the buyer cannot govern, the product failed.

The permission layer is part of the user experience because it changes what the AI is allowed to know and what the human is allowed to trust.

That is especially true in diligence. A legal reviewer, finance reviewer, HR reviewer, outside counsel, advisor, seller, and buyer may all participate in the same transaction with different access rights and different accountability. The product has to understand that boundary before it generates the answer.

This is why "bring your own API key" has always made me uneasy as a serious enterprise answer. It sounds flexible. It can also weaken quality control, data handling, cost discipline, and supportability. The product company still owns the user outcome. It cannot outsource the hardest parts of the trust model to a settings page.

Memory has to be operational

AI people use the word memory too loosely.

Memory is not a transcript stuffed into context. Memory is a representation of the job that can survive time, handoffs, model changes, and human correction.

In my own founder workflow, this shows up as durable skills, connected tools, transcript-grounded drafts, and explicit review steps. I wrote about that in The founder's AI stack. The lesson carries directly into enterprise product.

A useful diligence agent should remember which request-list items were answered yesterday. It should know which files were added overnight. It should preserve reviewer corrections. It should know that a standard vendor clause should not be escalated as a deal-breaking risk next time. It should keep track of what was accepted, rejected, ignored, and exported.

That kind of memory is not vibes. It is product architecture.

The moat has to show up in the buyer's work product

I do not believe in moats that only appear on a strategy slide.

The workflow-state moat has to show up in the artifact the buyer uses. In diligence, that means the product should produce things like:

• request-list coverage
• missing-item lists
• source-cited issue rows
• severity-calibrated red flags
• workstream-specific reports
• disclosure-schedule support
• reviewer status
• exports into the buyer's existing templates

This is why the best language for Colabra is not "AI-powered." It is "full-room coverage," "source-cited issues list," "request-list completion," and "shared review state."

Those phrases describe work the buyer already recognizes. They make the data layer visible.

The model provider threat is real

Model providers will keep moving up the stack. Enterprise customers will keep getting access to better general tools. Internal teams will keep trying to build their own systems.

That pressure is healthy. It forces the startup to answer the only question that matters: what does the product own that the model provider does not?

For some products, the answer will be distribution. For others, proprietary data. For others, regulatory trust. For Colabra, the answer has to be diligence workflow state: the room, the requests, the evidence, the review history, the permissions, and the final outputs.

If that layer is weak, the buyer is right to use a general model.

If that layer is strong, the general model becomes an ingredient instead of the product.

What I would ask before building any AI product

I would start with six questions:

1. What state does the workflow accumulate?
2. Which parts of that state are hard for a user to recreate in chat?
3. What evidence does the user need before acting?
4. What permission boundaries change the answer?
5. What human review step creates trust rather than friction?
6. What final artifact does the buyer already know how to use?

If the team cannot answer those questions, it probably has an AI feature. It does not yet have an AI product.

The model is powerful. The product is the workflow around it.

That is where the moat lives.