Essay
Is a System Prompt a Moat? When Encoded Expertise Is Defensible
Short answer: usually not. A prompt over a foundation model is one of the most copyable artifacts in software — its behaviour shows up in every output, and anyone with the same model can get close. It becomes a moat in one specific case: when the instructions encode the judgment of a genuine authority, in a domain where being right matters and wrong answers are expensive, so a competitor on the same model and the same architecture still ships a worse product. That moat is real, it is time-limited, and it is the most commonly missed one in early-stage software.
"It's just a wrapper" has become the default dismissal of any AI product. It is right most of the time, which is exactly why it is dangerous: the cases where it is wrong look identical from the outside. This post is about telling them apart — for your own product, and for a product you are thinking of integrating with.
Why most system prompts are not a moat
Start with the uncomfortable part. A system prompt has every property a moat should not have:
- It leaks through its outputs. You do not need to extract a prompt to approximate it. Run a few dozen inputs through the product, read what comes back, and a competent builder can write instructions that behave about the same.
- It runs on a model everyone can rent. The intelligence underneath is a commodity, priced per token and available to your competitor on the same terms.
- It is cheap to iterate on. Anyone's coding agent can stand up the surrounding app — upload screen, results view, billing — in a weekend. Conceding this is the honest starting point: building the ordinary parts of a product is no longer the hard part, and arguing otherwise is arguing with arithmetic.
So the useful question is not "is this AI?" but "is there anything here that a capable team with the same model could not produce?" That leads to the principle the rest of this post hangs on.
AI is a carrier for defensibility, not a category of it
AI does not make a product defensible, and it does not make it indefensible. It carries whatever defensibility the business already has — a network, a dataset, a right, or someone's judgment — into a form customers can use. Strip the AI away and ask what is left. If the answer is "nothing anyone else couldn't assemble", the AI was never the moat.
The cleanest version of the test is one question:
Does this model get better with each additional customer, or does it just get used more?
If it only gets used more, it is a feature, and features get cloned. If every customer's usage makes the next answer better — because corrections, outcomes or labelled cases are flowing back into it — then it is turning usage into data that nobody else has, and that compounds.
Most AI features fail this test. But one kind of product fails it and is defensible anyway, and that is the interesting case.
What is encoded expertise?
The familiar moats are networks, licences and proprietary data. There is a fourth, and it is easy to miss because it looks like nothing: encoded expertise — a practitioner's judgment written into the product. The rules, the taxonomy, the thresholds, the prompts, and above all the definition of what a correct answer is.
Picture a compliance-audit tool for a regulated care sector, written by one of the most respected inspectors in that field. It has no usage data to speak of. Technically it is "just a system prompt" plus a form. Anyone can copy the architecture in an afternoon. Nobody else can write those instructions — because the instructions are a career's worth of knowing which findings an inspector actually acts on, which evidence satisfies them, and which plausible-sounding answers get a provider marked down.
A competitor using the same model, the same retrieval setup and the same interface will still ship a worse product. Not slightly worse in a benchmark — worse in the way a customer notices when the real inspection happens.
How to tell if a prompt encodes real expertise
The test is never how the product is built. It is whether someone else could produce the same output. Five signals, and you want most of them:
- A real authority wrote it. Standing that exists outside the company — a credential, a track record, a role others in the field defer to. "Ten years in the industry" is not the same thing as being the person the industry asks.
- Wrong answers are expensive. Regulated audits, compliance, clinical, legal, safety, tax. If a mediocre answer costs the customer nothing, a mediocre clone is good enough and the expertise is decoration.
- The output is a judgment, not a transformation. See the table below.
- The judgment lives in the instructions. Thresholds, exceptions, a scoring rubric, a definition of "pass" — not a persona line and a tone guide.
- It is load-bearing on the thing being sold. Expertise sitting in the founder's head while the product does generic summarisation is not encoded anywhere.
| Transformation (copyable) | Judgment (can be a moat) |
|---|---|
| Summarise this inspection report | Which three findings will an inspector act on first, and why |
| Translate this contract into plain English | Which clause a court in this jurisdiction is likely to read against you |
| Extract line items from these receipts | Which of these expenses an auditor will challenge |
| Rewrite this policy in a friendlier tone | Whether this policy actually meets the standard it claims to |
The left column is a feature. Every general-purpose tool already does it, and yours will be matched by the next model release. The right column is where a specific person's knowledge makes the difference between a usable answer and a liability.
Does encoded expertise pass the "better with each customer" test?
No — and that is worth being precise about, because it is the reason this moat behaves differently from the others. A data moat starts weak and compounds. Encoded expertise starts strong and does not compound on its own: the thousandth customer gets the same instructions as the first.
So they are two different tests, answering two different questions. "Does it get better with each customer?" asks whether a moat is growing. "Could a competitor on the same model produce the same output?" asks whether one exists today. A product can pass the second and fail the first, and still be worth building on.
How long does it last?
It is real and it is time-limited. Once the outputs are public, a determined competitor can study them, hire someone almost as good, and distil the difference down over time. It holds for the horizon of a sales cycle or a partnership, not forever. That is an argument for using it now, not a reason to discount it.
How it becomes durable
The route from a time-limited moat to a compounding one is short and specific. Every audit a tool like that runs is a labelled example — a case, a finding, and eventually a customer correcting or confirming it. Nobody else is collecting those. The day the product starts using that record for something — a ranking, a default, a fine-tuned model, a benchmark — it starts to pass the "better with each customer" test as well. Most products never take that step. The ones that do are the ones worth watching.
How to judge encoded expertise in a potential partner
This matters most when you are deciding whether to integrate someone else's capability into your product. An integration costs engineering time and usually a permanent revenue share on what it touches, so you only want to do it for something you could not cheaply reproduce. The founder of the product you are evaluating is the worst person to ask — the ones with genuine expertise tend to describe their work as ordinary, and a self-declared moat reads like marketing copy.
So infer it, and be strict about how sure you are. Three registers:
| Register | When | How to write it down |
|---|---|---|
| Observed | Their own site or materials state it | Cite it: "their methodology page says the rules were written by a former inspector" |
| Inferred | The shape of the business implies it, nothing states it | As the question for the first call: "worth checking — who wrote the scoring rules?" |
| Trajectory | Nothing visible — the common case | A direction with a condition: "every review they run is a labelled case; the day they learn from those, nobody matches them" |
The one serious mistake is promoting an inference or a trajectory to a fact. "They have proprietary expertise" written about a product where nobody said so gets tested in the first conversation, finds nothing behind it, and costs you the credibility of everything else you got right. An admitted gap costs nothing.
And check that the expertise sits on the capability you would actually integrate. A company with a genuine authority behind its audit engine, offering you a generic notifications feature, is a good company with no moat in this deal.
If you are the expert: what to do about your own product
- Stop selling "proprietary AI". Every buyer has learned to discount it. Sell the judgment: who wrote the rules, what standard they encode, what a wrong answer would have cost.
- Make the authority visible. A methodology page and a real bio are the evidence a buyer — or a partner — needs to read your expertise as observed rather than guessed.
- Start keeping the record now. Store every correction, override and confirmed finding in a form you could learn from later. That record is the bridge from a moat with a horizon to one that compounds.
- Move while it holds. If your judgment is the thing others would embed, the time to agree partnerships around it is while the gap is widest.
At Ordana, this is one of the four things we look for when deciding whether an integration between AI products is worth proposing — and we infer it from a product's own public copy rather than asking founders to declare one, for exactly the reason above.
Related reading:
- Startup Moats in the AI Era — the three structural moats (networks, licences, data) that this post adds a fourth to.
- The Three Moats That Decide Whether a SaaS Is Worth Integrating With — the same test, run on a partner before you build alongside them.
- Build vs Buy for SaaS Features — why "can we build it?" is the wrong question once everyone can.