Models, products, and platforms

“We should use AI for X” can mean three different things, and people in the same meeting are usually meaning three different ones. The clearest distinction in this whole landscape is the one between the model, the product wrapped around it, and the platform that hosts it. Once the distinction is clear, half the noise in the category sorts itself.

The three layers

A model is a brain. GPT, Claude, Gemini, Llama, Mistral, DeepSeek. These are the actual AI — pattern-matching machines, the thing Module 1 was about. On their own they do nothing. They need to be hosted, served, given an interface.

A product is a brain in a box. ChatGPT, Claude.ai, Gemini, Perplexity, Copilot, Cursor, Notion AI. These wrap a model in a usable interface — settings, chat history, file uploads, accounts, billing, integrations. Using ChatGPT means using a product that happens to use a model.

A platform is the box-making kit. OpenAI’s API, Anthropic’s API, AWS Bedrock, Azure OpenAI, Google Vertex AI. Raw access to models, so developers can build their own products and tools on top.

Why the distinction matters

When people compare ChatGPT, Claude.ai, and Gemini, they’re comparing products. Each happens to use a different model, but a lot of what makes one feel better than another is the product layer — chat history, file uploads, projects, workspace, search integration, mobile app. The underlying models are close enough that the wrapper often decides the experience.

When engineers compare “GPT vs. Claude,” they’re comparing models at the API level. The product wrapper is gone. They’re choosing what to build on top of. When the comparison is between tiers within a family — Claude Sonnet against Claude Opus, or Gemini Pro against Gemini Flash — that is still a model comparison, just at a finer grain.

When IT compares “OpenAI direct vs. Azure OpenAI vs. AWS Bedrock,” they’re comparing platforms — different hosting environments for the same (or similar) models, with different security postures, compliance certifications, billing relationships, and integration with the rest of the cloud stack.

The same model can show up at all three layers. GPT is a model family; ChatGPT is a product that uses it; Azure OpenAI is a platform that serves it. “Using GPT” doesn’t say which one.

The same use case at all three layers

A sales team wants AI help with email drafts. “Use AI” could mean:

• ChatGPT Team licenses for everyone — product, off-the-shelf.
• A sales-specific AI tool that lives inside the CRM — product, vertical, built on a model under the hood.
• A custom internal tool talking to the OpenAI or Anthropic API — platform, built in-house.
• The same custom tool, but hosted on Azure or Bedrock so IT controls the data path — platform, with enterprise governance.

All four are “using AI.” The cost curves are different. The data-flow stories are different. The time-to-running is different — weeks for a license, months for a custom build. The lock-in shape is different — a product is hard to migrate off; an API call is one configuration line.

When the conversation moves between these without naming them, decisions get made on mismatched assumptions. The IT lead is thinking platform; the sales lead is thinking product; the finance lead is comparing them on price as if they were the same thing.

The wrapper economy

A large share of the AI tools landscape — including most of the “AI for [industry]” pitches in your inbox — is built at the product layer on top of someone else’s model. The vendor is not training their own frontier model. They’re calling the same APIs an in-house team would call, with their own wrapping around it.

That wrapping can be substantial: a workflow that fits a specific job, integrations into the systems already in place, domain-specific prompts and evals tuned over many customers, a support relationship, a UI built for non-technical users. For many jobs, that wrapping is most of the value.

It can also be thin: a generic chat UI, a prompt template, and a markup over the underlying API price. Both exist in the same category and often look similar from the outside. The distinction shows up under questions like what does this do that the platform alone doesn’t?, what happens to our data on the way through?, and can the underlying model be switched when a better one ships? — which are factual questions about how a given product is built.

The layers are not a ranking. Most operations end up with a mix — products for off-the-shelf jobs that already fit, platform builds for the workflows that are specific enough to be worth the effort, and sometimes a vertical product in the middle. The useful move is to know which layer any given decision is at.