Model, Agent, Application

A diagram that separates the three layers. Confuse them and you'll treat a product problem as a model problem.

"It's the AI's fault" — you hear it almost every day. Most of the time it's wrong, because "AI" isn't one thing; it's three layers stacked together. llm-wiki

Symptoms you'll recognize:

• The feature doesn't work, and the team's first reaction is "we need a stronger model."
• At acceptance time everyone stares at the model's output and nobody checks the pipeline for bugs.
• A stakeholder says "our AI isn't good" but can't say where.

What each layer does

Model. The bottom layer. It does exactly one thing: predict the next token from its input. It doesn't do work, go online, remember you, or decide what to do next. It's just a capability — a text-in, text-out engine that only knows what's in front of it.

Agent. The middle layer. It wraps the model with the things that let it act: tools, a loop of "think, act, observe, think again," memory, skills, and permission boundaries. The model is the engine; the agent is the cockpit. agent-wiki

Application. The layer users see. Interface, flows, permissions, data, operations, copy — the entire user experience lives here. Customer-service bots, copywriting tools, and knowledge-base Q&A are all applications. Users never see the two layers below; they only see this one.

One sentence to remember: the model produces text, the agent produces actions, the application produces a product. All three have to work together before the user feels the system is any good.

The most common mix-up

The value of separating layers is assigning blame correctly. In practice, the most common mistake is charging everything to the model when the real problem sits in the application or agent layer.

• "A stronger model will fix it." The chatbot answers wrong — check first whether your knowledge base is fed correctly, the prompt is clear, and the flow is missing a step. A stronger model rarely fixes any of those; it gets stronger but still holds the same wrong materials.
• "AI will get it done by itself." The model won't act on its own, and the agent doesn't exist automatically. What looks automatic is the orchestration, fallbacks, retries, and timeouts written in the application layer. You wrote that code; it's not the AI's doing, and when it breaks it's not the AI's fault either.
• "It's hallucinating." Before calling it a hallucination, check whether the data source, chunking, or retrieval failed first. For knowledge-base mistakes, most of the time the model step is never even reached.

Where to pin the problem

When a report says "the AI is bad," run this sequence. It takes seconds.

• First question: is the flow buggy? Tools not called, context not passed, permissions blocking the wrong thing — engineering problems in the application and agent layers, nothing to do with the model.
• Second question: is the material right? Correct retrieval recall, clear prompts, complete memory injection — still engineering.
• Third question: materials are right and the output is still bad? Now, and only now, it's the model's turn. This is when you consider a different model, tuning parameters, or fine-tuning.

The point of this order: fixing the first three questions is much cheaper and faster than swapping models — and most "AI is bad" reports have their answer there. A model swap is the most expensive and least common fix.

The bottom line: the model only takes the blame for "the materials were right and it still answered badly." Before that, clean up your own layers first.