Part 1 starts with the basics: what AI actually is, where it differs from normal automation, what tokens, model weights and context really mean, and whether you actually need to “train AI on your data.”
The goal is to clear away enough of the terminology and hype so the rest of the AI conversation starts making sense.
Do you need AI or merely automation?
The 2 are often conflated and everything is suddenly packaged in an AI wrapper those days.
It’s important to tell the difference because automation is plain vanilla software (e.g. cheap) while a real AI workflow is way more complex and will just cost more (not because of AI itself but all the apparatus that goes around it, as you shall see as you read the entire post).
The distinction is subtle but can cause some confusion.
Here’s an example: guess if you need AI or only automation for this process.
A customer submits a request on an online form with drop down list options but no free text. Based on that, someone must categorize the request based on the input in the ticket system, create a record in another system, send a personalized email back to the customer to acknowledge receipt and assign the task of following up to someone else.
You guessed it, the entire process can be automated with plain vanilla software.
There is very little ambiguity as to what should be done, and can be thought of as “if X, do A. Else, do B” where both inputs and outputs are predictable (eg the customer can only select from a few options in the drop down list and we know them all. We also know what to do for each option).
Some people may think you would use GenAI to write the email back to the customer. But to the extent that it’s the same for every customer, a template will do.
Now here is another example.
Every time you attend events, you end up with a pile of business cards. You want to automatically have the details of everyone directly into your phone without manually going through them. Can you automate with plain software or do you need AI?
The answer: you would use plain vanilla code to automate the whole process, with a pinch of AI just to handle the reading of the cards.
The reason is as follows: the inputs will need some interpretation, because not all business cards look alike (exotic names may sometimes be taken for company names, job titles may have special characters or even be in a different language, etc.). GenAI can handle all the variations in one go very effectively.
Here’s how you would proceed:
- Take a picture of all the cards and throw them on your favorite cloud (let’s say you are using Google Drive)
- Write an automated script to read such files one by one,
- Send that to an AI API for extraction with a pre-determined structure (eg you always want first name, last name, email, title, phone number etc),
- Get the data back,
- Programmatically add them one by one in your Google Contact lists (which hopefully you have sync’ed with your phone list). If you prefer, you can send that to a spreadsheet, a CRM, etc.
Everything except the reading is deterministic. You don’t need an AI to “guess” where “first name” goes into your CRM or contact list. That’s something that can be programmed in code.
These 2 simple examples illustrate a simple rule of thumb when it comes to AI vs Automation:
- If the mapping between input and output is known and doesn’t need further interpretation, plain automation will work and there is no AI required
- Conversely, if some interpretation is required, GenAI can do that part. But the rest around that AI task should stay plain vanilla code
Which brings the question: are there cases where AI should handle the whole process and where you have no deterministic code at all?
Barely, at least in a business context. But I am getting ahead of myself, for this deserves a bit more explaining. More on this later.
For now, please don’t pay an AI price tag for a simple automation, and don’t look to AI to solve deterministic problems.
What the hell is a token?
Sooner or later, someone discussing AI costs with you will start talking about tokens, so you need to know what this is.
AI models do not read your prompt as words in the way you do. Before the model processes the text, it gets broken into small pieces called tokens. A token can be a whole word, part of a word, punctuation or even a small piece of formatting.
For English, a useful rough approximation is this: 750 words is roughly 1,000 tokens. It varies by language, model and type of content, so this is just a heuristic to keep in your back pocket.
What this means is that if your prompt is a full A4 word doc (~400 words), it will be about 500ish tokens. If you’re sending a whole contract, it’d be trivial to get the total word count and calculate the approximate equivalent in tokens.
We don’t need to get into the weeds of “But why use tokens and not words?”. What truly matters about these tokens is that you will pay based on the amount of token you use, and this is where it gets a bit confusing.
Every AI API call will quote a price for INPUT TOKENS and a different price for OUTPUT TOKENS, generally quoted as ‘x dollars per million token (Mtok)’. What you pay is of course the sum of both input and output tokens.
Here is why.
When an AI model receives your prompt, it will process them in parallel (not token by token). In terms of compute, that’s cheap and fast.
Generating an answer is different. It will produce tokens one after the other (just like we write one letter after the other), with each new token depending on what came before it. Producing 5,000 tokens therefore consumes materially more resources than simply reading another 5,000 tokens.
Hence, input tokens are always cheaper than output tokens. It’s just a function of the resources required to process those things.
Therefore, you can guess that every interaction with an AI model will have a different price tag (even for similar prompts, although the difference will be small). Not to mention that under the hood, the AI model might do different things (e.g. perform a web search to verify something live for example) that adds more tokens.
This is also why “$X per million tokens” tells you little about what an AI application will actually cost to operate. You have to know the type of workload you will need AI to process, build it, test it and check the cost. One can guesstimate, but the best estimate with AI is to try the thing out.
Open AI token pricing:
Anthropic token pricing:
Putting on your CFO hat, you will then ask “How do we don’t blow up the budget with all this AI stuff?”
The answer is that there are plenty of ways to manage this. Good AI engineers can control how much information is sent to the model, limit output length, cache information that doesn’t need to be processed repeatedly, use cheaper models for simpler work and reserve expensive models for tasks where they actually make a difference.
So don’t despair at the lack of predictability in cost.
No one would use it if it was really impossible to limit unexpected costs. And if you suddenly see an alert on your AI bills, AI is probably not to blame. It’s probably because someone forgot to engineer the right boundaries around AI.
Model weights and the concept of machine intelligence
You will hear of AI models having 7 billion, 70 billion or trillions of “parameters”, often more loosely referred to as its “weights”.
You do not need to understand the mathematics behind (although it’s fascinating) but understanding how intelligence is produced from these weights is actually useful.
At its core, an AI model is just a huge (or many huge) file(s) with lots of numbers inside. Those numbers are the result of training, where the model was exposed to a large amount of data (essentially, a curated version of the Internet, plus some more) and the training process has encoded such knowledge using numbers.
Then, how does AI reason or behave intelligently based on just a bunch of numbers?
An (imperfect) analogy will help: our biological brain.
It has billions of neurons connected to each other. No individual connection contains our understanding of what a dog is, how to speak Vietnamese or how to calculate an EBITDA margin. What we know and what we can do somehow emerge from patterns of activity across various regions of the brain, which are themselves learned by experience.
Ai models share the same property: intelligence is not sitting inside one particular weight. It results from what the network has learned during training. No weight says “Paris is the capital of France”. However during training it has encoded the understanding of Paris, France, capitals, geography and the relationships between these concepts.
In other words, intelligence is distributed across the neuronal network, and emerges from it. It is not stored in any particular weight.
One last important thing about model weights: these numbers in the AI model are fixed after training is completed and the model deployed for us to use.
So when you send a prompt with some data, it is not “ingesting” this new knowledge into its weight in order to reuse it later. People have this fear that using AI will expose their proprietary data (which is definitely a risk). But it just doesn’t happen as “I give my data to AI, and AI incorporates it in its knowledge”.
We will talk about “training on your data” in a bit. For now, all your need to remember about AI model weights is that:
At the core, it’s just a file with numbers, which are encoded representation of everything a model has learned
Intelligence is not encoded or pre-programmed, but emerges from these representations.
AI models don’t incorporate your data and prompts into their own weights just because you sent it. Its weights are fixed
“AI is a prediction machine.” Yes, but there’s more.
You will often hear that AI is “just predicting the next token”, usually followed by the conclusion that it cannot really reason and therefore cannot be trusted.
The first part is technically true. The second does not follow from it.
At the very bottom of a language model, generating an answer still involves predicting one token, then another, then another. But describing AI that way tells you very little about what the resulting system is capable of doing.
There are a few reasons for that.
First, the model you use today is not simply the result of pre-training on a large pile of data. It has also been “post-trained”.
A useful (simplified) way to think about it is that pre-training builds a corpus of knowledge, while post-training shapes how the model behaves.
For example, post-training can teach the model to follow instructions, reason through particular classes of problems, respect certain constraints and learn how and when to use tools (like web search, browsing a website, writing some code, etc.).
As a result of pre and post training, you get a model who is intelligence and capable of doing stuff.
Which brings us to another concept you will increasingly hear about: the harness.
A harness is the software sitting around the model that lets it do more than simply receive a prompt and return an answer. As the name implies, if the AI is a horse, the harness allows you steer it towards where you want to go.
OpenAI describes the agent loop inside Codex (its harness for coding) as:
The harness is the core logic … responsible for orchestrating the interaction between the user, the model, and the tools
In other words, traditional software wraps around the AI model.
So when you ask Codex to fix a bug, the model is still generating tokens somewhere underneath all of this. But the overall system can now perform a loop that looks roughly like this:
read the problem → inspect the code → decide what to change → edit files → run tests → observe what happened → correct mistakes → repeat
Calling that whole thing “a next-token prediction machine” is therefore incomplete.
This also explains why the same underlying model can behave very differently depending on the harness you put around it.
Give a model a prompt and no tools, and it can produce basic answers.
Give it access to your documents, databases and APIs, a way to remember where it is in a task, rules about what it may or may not do, retries when something fails and a loop that lets it inspect the consequences of its actions, and you have built something much more powerful.
You can build these kinds of harnesses for your own business processes too.
For example, an insurance-claims harness might give the model access to claim documents, policy records and internal procedures, let it request specific checks, define when a human must approve something, limit what systems it may change and keep track of where each claim sits in the workflow.
The model provides the reasoning engine. The harness enables you to use the engine towards a goal.
For a non-tech CEO, it doesn’t matter much that there is a token prediction mechanism inside the engine. What matters is understanding what needs to be done using the engine, determine what harness should be used or built around it, and steer it towards the goal.
Demystifying “context.”
It is one of those simple words that became complicated once the AI industry discovered it could put the word “engineering” after it. Context engineering sounds fancy indeed.
But the basic idea is dead simple.
You now know the AI model weights are fixed. It has knowledge, reasoning abilities and access to tools. But it doesn’t mean it already knows all the things it needs to know to perform the task you need it to do.
That additional, specific information (along with the prompt) is called “context”.
Imagine asking a new employee: Please review this proposal and tell me whether we should accept it.
Unless they know who the customer is, what you are trying to achieve, your pricing rules, previous negotiations, what your CFO has already approved, what risks matter etc, they will probably give you the wrong answer.
AI is no different.
If you send it a contract and ask: Should we accept this contract as-is?,
the model may understand contracts very well. But it does not know your company’s risk appetite, your standard clauses, what was previously negotiated with this customer, etc.
All of that is context.
Context can therefore include almost anything useful for the task:
- your prompt;
- the conversation so far;
- documents;
- company policies;
- database records;
- previous decisions;
- examples of good answers;
- output from other AI;
- results from a web search;
- instructions about what the AI is allowed to do and forbidden to do;
- etc.
Can you give infinite context? Of course not. The limit is called the “context window”.
Many recent frontier models have a huge context window of about 1 million tokens. Using the rule of thumb of 500 tokens per A4 page, that’s a whopping 2,000 pages! That’s not exactly true (there are other system instructions, tools etc that also eat up tokens) but you get the idea.
There are wrinkles in the way AI models use their context. Shoving in 1000 pages of documents and asking AI very specific questions is probably not going to yield the best results (there is a phenomenon literally called “lost-in-the-middle” where AI models struggle with information in a large context, especially when buried in the middle).
This is where “context engineering” comes in.
Despite the grandiose name, the question of context engineering is basically: What does the model need to know to do this job properly, and how do we reliably put that information in front of it at the right time?
Doing that once in a chat session with ChatGPT is easy. Doing it systematically within an automated process, securely and consistently across thousands of requests takes some real engineering muscle.
But there is no magic, it’s just a data/software engineering problem with a fancy name.
So when some consultant tries to dazzle you with “context engineering”, you’ll know they’re probably trying a little too hard.
Do you really need to “train AI on your data”?
Sooner or later, someone will tell you that to make AI useful for your company, you need to “train it on your data”.
Your first reaction should not be “great”. It should be: What exactly do you mean by training?
Because people use that phrase to describe several completely different things, with very different levels of complexity, cost and usefulness.
You already know from the section on model weights that actual training means changing or adapting those weights. A model is exposed to data, the training process adjusts its internal parameters, and the resulting model behaves differently because of it.
Now imagine you upload your employee handbook to ChatGPT and start asking questions about it.
No model weights have changed. The model has not “learned your company” in the training sense. You have simply given it information to work with.
That is context, not training.
A slightly more sophisticated version of the same thing is something called RAG, or Retrieval Augmented Generation. Instead of putting your entire employee handbook, pricing manual, SOP library and every policy you have into the prompt every time, you keep those documents somewhere outside the model.
When someone asks a question, the system searches for the pieces that appear relevant and puts only those pieces into the model’s context. Then it answers based on that.
Again, no weight has changed, and RAG is not AI training (it’s just called “retrieval”).
You will hear “vector database” mentioned a lot in these retrieval conversations. All you need to remember for now is that it’s a different kind of database.
Then the last version of “AI is trained on your data” which is actually not training is as follows.
A vendor may build an application around GPT, Claude or another frontier model, add some permanent instructions, connect it to your company documents, perhaps store some information about previous interactions, and suddenly the AI appears to “know your company”.
That’s usually how they pull off demos within a few hours. It’s still not training on your data, although from the user’s point of view, it can certainly feel as though the AI has been trained.
But configuring instructions is not training either.
For a C-level executive, understanding these nuances is important so that you don’t get misled when vendors quote you an AI training price tag for work that is actually much simpler (relative to real AI training).
Now, there are cases where they may actually mean “AI trained on your data” and it may be necessary for your business case.
The most common method is fine-tuning.
Fine-tuning changes (or adapts) a model’s weights using additional examples so that it becomes better suited to some particular task or behavior.
Suppose you have a highly specific classification problem and thousands of good historical examples showing how experienced employees handled it. You give a general model clear instructions and relevant context, but its behavior is still inconsistent in ways that matter to you.
Fine-tuning can solve that problem. By adapting/changing the model weights, you are essentially baking in a new behavior inside the AI model itself, which it will use consistently on every task that requires such behavior. If finding factual knowledge is more important than behavior, RAG / retrieval is generally a better approach.
The harder question is whether you should bother with fine-tuning, as this can come at a steep price tag. You’d also need:
- Enough high-quality data to train on,
- A clear idea of what behavior you are trying to improve,
- and some objective way to prove that the fine-tuned model is actually better than a plain-vanilla AI model
Otherwise you may simply spend money creating your own slightly different version of a model that was already good enough.
A useful rule of thumb is this. Consider fine-tuning when
- you have a recurring, well-defined task, enough high-quality examples of the desired behavior,
- and prompting and context alone are not getting you where you need to be,
- and there is enough economic value to justify the additional complexity.
So next time you hear “train AI on our data”, you will be able to mentally separate 4 possibilities:
- Give the model your information as context. Not training, pretty standard engineering skills required.
- Retrieve relevant information from your company systems when needed. Usually RAG or some other retrieval architecture. Still not training
- Store useful information over time and retrieve it later. Using standard memory. Still not training.
- Change the model’s weights using your examples. Now you are actually training on the company data usually with fine-tuning techniques. This takes more specialized skills than standard engineering
All 4 can be useful for different use cases. But just make sure you don’t end up paying the price of “AI training” for any of the 3 basic cases.
Here is a simple bullshit detector when a vendor is talking about this with you.
If someone says:
“We need to train the AI on your data.”
ask:
Are you actually changing or adapting the model’s weights?
If the answer is no, fine. Ask what they are really doing instead.
If the answer is yes, ask:
What problem requires changing the weights rather than using other techniques?
Then listen carefully to what they have to say and decide for yourself if the vendor is trying to bullshit you, or if they have a genuine reason to believe you really need AI to be “trained on your data”.