Almost every frustrating afternoon with these tools ends the same way: someone is changing the wrong layer. The stack below is not a diagram to memorise. It is a diagnostic, and it works for anything from a spreadsheet assistant to a livestock dashboard.
From a problem to a working system
-
Real problem or goal
What needs to become easier, faster, clearer, safer, or more useful? If you cannot state this in a sentence without naming a technology, start here and stay here.
-
Application or workflow
The thing a person actually uses: a dashboard, a research tool, a member portal, an alert, a map, a report, or an assistant. This is what you show someone. Everything below it is plumbing.
-
Harness or agent
What coordinates the model with instructions, memory, files, permissions, and tools. A harness is the frame; an agent is a model working inside that frame toward a goal, often over several steps. This is the layer most people skip past, and it is where most of the practical control lives: what the AI can see, what it may change, and when it has to ask.
-
Model
The language or multimodal model doing the inference. Different models trade off capability, cost, speed, and openness. Swapping the model is usually the easiest change in the stack, which is worth knowing before you rebuild something to get a better answer.
-
Tools and data
APIs, documents, spreadsheets, databases, sensors, maps, web search, code, and organizational knowledge. This is where your own knowledge enters the system, and it is usually the layer that determines whether the result is actually useful.
Which layer is the problem?
A short version of the question that ends most stuck afternoons. Read the symptom, look at the layer.
| What you are seeing | Layer worth checking first |
|---|---|
| "It is not doing what I want." | The goal. It was probably never stated precisely enough, including what you did not want. |
| "It forgets what I told it." | The harness. Context, memory, and files are harness concerns, not model quality. |
| "The answers are shallow or generic." | Tools and data. It has not been given your documents, your records, or your definitions. |
| "It is slow, or it costs more than expected." | Model, and tokens. A smaller model, or less material per request, often fixes both. |
| "It changed something it should not have." | The harness permissions, and your revision control. Both are fixable; the second one is why you can undo it. |
| "Nobody is using it." | The application layer. The tool solved a problem someone had, but not the way they work. |
Two environments, and why the distinction matters
| Development | Production |
|---|---|
| Your workshop space: experiment, learn, break things, iterate quickly. | The live system people, data, or equipment rely on. |
| Use sample or non-sensitive data where you can. | Use real data, carefully managed. |
| Changes are cheap and reversible. | Changes should be deliberate, tested, documented, secured, and recoverable. |
| Ends with: "this works, and I know how it fails." | Starts with: a limitation on who can change it, and a plan for when it stops. |
Most workshops and most tutorials happen entirely in development, which is why the transition surprises people. The workshop's phrasing is worth keeping: experiment in development, deliver in production.
Tokens, in one slide
Models do not read words. They read tokens: small pieces of text that can be a word, part of a word, a number, or a symbol. The workshop's example:
Goats build a better future. Goats | build | a | better | future | . = 6 tokens
Two things follow from that, and both show up in your daily work. Longer inputs and longer answers cost more and take longer, so "paste in everything" is usually the wrong instinct. And because a model can only consider so much at once (the context window), what you leave out matters as much as what you include. For the detail, OpenAI's explanation of tokens is a good reference.
Three ideas that cut across every layer
- Tokens. A practical way to estimate context size, latency, and cost, whichever layer you are working in.
- Openness. Open-source software and open-weight models can increase portability, inspectability, and autonomy. A model whose weights are available is not automatically open source in every part, so the licence still matters.
- Human judgement. Agents can act, but people still set goals, choose evidence, approve consequences, and remain accountable.
If you take one working habit from this page, take this one: when something goes wrong, name the layer before you start changing things. It turns a bad afternoon into a small question with a findable answer.