The Product Is Not the Model

Introduction

"But if Claude can generate a PDF with images, why can't ours? We're using Opus 4.8."

This sentence — or some version of it — has been spreading fast. And it carries more weight than it seems.

Three Entities, One Confusion

In that sentence we can identify three distinct entities:

• PRODUCT: Claude, Gemini, ChatGPT, Grok, or any other
• ACTION: "generate an Excel", "create a Doc", "produce a PDF", "execute code", etc.
• MODEL (the brain behind the agents): opus-4-8, sonnet-4-5, gpt-5, etc.

The pattern is always the same — only the values change. And the confusion is always the same too: conflating the product with the model.

Problem 1: A Conceptual Misunderstanding Disguised as a Technical One

Using Opus 4.8 in an internal product does not mean that product can do everything Claude can.

Claude — like ChatGPT, Grok, or Gemini — is a product built on top of a model, with specific tools integrated: file generation, code execution, web browsing, and more. An internal development using the same underlying model does not inherit those capabilities. It will only have access to those tools if they are built in-house or via a framework that provides them (Anthropic SDK, LangChain, CrewAI, etc.).

The model is the brain. The product is the entire system built around it.

Problem 2: Optimistic Estimates

This conceptual gap leads directly to the second problem: estimates that don't account for the actual complexity.

Every capability that users take for granted in a commercial product — because they use it every day for free — requires real engineering effort in an internal build: designing the tool, integrating it into the agent's flow, and validating it end-to-end.

There's an additional detail that's rarely evaluated upfront: some available solutions that could be integrated carry an AGPL license, which requires distributing the code as open source. That rules them out for any proprietary internal development, turning what looked like a quick integration into a build-from-scratch effort.

When this isn't analyzed carefully before the project kicks off, the estimated timelines fall short right when the team has already committed to a delivery date.

Problem 3: Misaligned Expectations

The third problem is what triggers the original sentence in the first place.

Users unconsciously set their quality bar based on the commercial products they already know and use daily. They won't accept something that falls significantly short of that reference — and that's fair. The issue isn't that the team missed something. It's that nobody aligned expectations before starting: no acceptance criteria, no agreed quality standards, no shared definition of what "good enough" looks like for this context.

🎯 Final Thoughts

All three of these problems are completely avoidable — but avoiding them requires a prior diagnosis: understanding what the AI needs to do, what capabilities that actually involves building, and how success will be measured.

That diagnosis is what separates a project that generates real value from a PoC without a future that burned through resources.

If you're evaluating whether to build an internal AI product, or you're already in the middle of one that's starting to drift — it's a good time to talk.

📚 Resources

Original LinkedIn Article (Spanish) 👉 Post & Article: El producto no es lo mismo que el cerebro