The two AIs — same technology, opposite intent.

A useful exercise: pick the most popular consumer AI product on your phone and the most popular enterprise AI product on your laptop. Imagine someone swaps the model weights between them. The consumer one is now powered by the enterprise model; the enterprise one by the consumer model. Would the experience change? For most pairs, the honest answer is: not much. The personality would feel a little different. Latency would shift. But the shape of the product — what it asks, what it stores, what it acts on without checking — would be identical, because the shape is not in the weights. It is in the wrapper.

This is the load-bearing insight behind the way we think about AI products: the wrapper is the product. The model is interchangeable. The system prompt, the retrieval pipeline, the consent surfaces, the tool permissions, the storage policies, the audit hooks — those are the product. Two teams using the same model can ship opposite products, and they regularly do. We call them the extractive AI and the consenting AI because the words actually mean something in this context.

What "extractive" looks like in practice

An extractive AI product treats the user as a data source. Every interaction is sampled, scored, and added to a corpus. The corpus, in turn, is used to refine future inferences — most of which are directed back at users like you, not at you. Your contribution to the system is mined; your benefit from the system is roughly the same as a free tier user’s. The system is profitable because the cost of attention you give it, in aggregate, exceeds the marginal cost of serving you.

Extractive AI is, on the consumer surface, almost always optimised for one number: engagement minutes. Not because engagement is intrinsically valuable to you, but because it is the leading indicator of the revenue model. Where engagement minutes conflict with the user’s actual stated goal, engagement wins. This is sometimes obvious (a feed that won’t stop scrolling) and sometimes subtle (a question-answering agent that asks four follow-up questions before answering, because each turn is a sample). The subtle version is more interesting. It is also harder to legislate.

What "consenting" looks like in practice

A consenting AI product treats the user as a counterparty. Counterparties have rights: of refusal, of audit, of exit. They negotiate. The system has obligations that survive a re-read of the terms of service. In practice this means a small number of design defaults are inverted:

• Citation is default. If a claim cannot be backed by a retrieved source, the system labels it as opinion or refuses to make it. The user sees the source. They can click through. They can disagree.
• Action is gated by consent. No agent spends money, sends messages, or modifies data without an explicit, scoped permission in the live session. "I assumed you wanted me to" is not a valid posture for systems that affect other people.
• Refusal is a feature. The user can turn off personalisation, recommendation, classification, and inference — and the product still works. A consenting product still works without consent; it just works less.
• Audit is a deliverable. The user (and their organisation) can request the chain of AI actions taken on their behalf. The chain is hash-linked. Nothing is "lost."
• Exit is unpenalised. The user can take their data, their fine-tunes, their evidence chain, and go. There is no economic moat made of switching cost. The moat is the product being good.

None of these are difficult to build. Most of them are mildly inconvenient. All of them are unprofitable at the margin compared to the extractive equivalent. That is why they are not the default. That is why building them, and giving them away as a default, is the project.

The model is interchangeable. The system prompt, the retrieval pipeline, the consent surfaces, the tool permissions — those are the product.

The asymmetry between the two AIs

Here is the structural asymmetry that the policy debate keeps missing: the consenting AI requires more infrastructure than the extractive AI. The extractive AI is what you get if you wire a model to an API and let it act. The consenting AI is what you get if you wire a model to an API, then build the consent vocabulary, the evidence chain, the policy DSL, the refusal surfaces, the audit deliverables. The shortcut produces the worse system. This means market mechanics alone will not get us to the consenting AI. The default outcome of "let the market decide" is the extractive one, because the extractive one is cheaper to ship.

The leverage point is to build the infrastructure once, well, and make it available. That is the bet behind the twenty-module Midcore Charter. We are not asking buyers to choose the harder path because it is virtuous. We are reducing the cost of the harder path until it is the easier path. If we get that right, the consenting AI ends up cheaper to ship than the extractive AI, and the question of which kind of system gets built stops being a moral question and becomes an engineering one. That is the only kind of question that gets answered consistently at scale.

---

Read the third essay in the series: Twenty instruments — Midcore as civic infrastructure.