What is AI?

Artificial intelligence (AI) is the field of building computer systems that perform tasks we associate with perception, language, prediction, planning, or decision-making. Unlike conventional software, whose behaviour is fully spelled out in rules a programmer wrote, many AI systems derive their behaviour from data, but not all AI is machine learning: search, planning and rule-based expert systems count too.

Familiar artificial intelligence examples include a spam filter, a chess engine, a route planner and a language model drafting a reply. A spam filter shows the difference. A conventional program blocks mail containing the phrase "free prize", and misses every wording its author did not list. A learned filter is trained on thousands of messages labelled spam or not spam, and it picks up patterns nobody wrote down, at the cost of sometimes being confidently wrong. The definition is deliberately about the task, not the technique: a chess engine searching a game tree, a route planner, a spam filter and a language model drafting a reply all count. A product that uses AI is almost never just a model; it is a model embedded in ordinary software that supplies data, checks outputs and takes actions.

Most of what people call AI today is machine learning; how it relates to deep learning and generative AI is covered in ML vs Deep Learning vs Generative AI.

The practical consequence is the question this chapter keeps returning to: for a given piece of behaviour, should the system compute an answer from rules, predict one from learned patterns, generate one, or look one up? The four are not ranked. They fail in different ways, and a competent engineer chooses per task.

An online store receives a few thousand messages a day. Someone must route each to refunds, fraud, shipping or cancellations, and one message in particular matters: "I paid twice but have not received the money back." It describes a duplicate charge awaiting a refund, and it should reach the billing team quickly.

Attempt 1: hand-written rules

The first engineer writes if "refund" in message.lower() and routes to refunds, adds "stolen" for fraud, "where is my" for shipping, and so on. It is fast, free to run, trivial to test and completely explainable: any decision can be traced to a line of code. It also fails immediately on the sentence above, which never contains the word "refund" ("the money back"), and it misroutes "What is your refund policy for gift cards?", which contains the word but concerns no charge at all. Each failure is fixed by another rule, and the rule list grows until nobody dares edit it.

Attempt 2: a classifier learned from labelled examples

The second approach collects, say, twenty thousand past messages that agents already labelled, and trains a model to map message text to a category. It never sees "refund" as special; it learns from data that phrases like "paid twice", "charged again" and "money back" co-occur with the billing label. It can route messages phrased in ways nobody anticipated. In exchange, you give up traceability (there is no single line that explains a decision), you inherit the quality and bias of the labels, and it can be confidently wrong in a way a rule never is.

Attempt 3: a generative assistant

The third approach asks a language model to read the message and write a reply. This adds a capability the other two lack: producing fluent, tailored text. It is also the least constrained. Fluent text is not verified text; the model can write "your refund of $42.10 was issued yesterday" without any refund having happened, because writing the sentence and performing the action are different things. We return to that distinction below.

None of the three dominates. The rule is the right tool for a policy such as "orders over a fixed amount need manager approval", the classifier for fuzzy language, the generator for drafting. A real support system uses all of them, each where its failure mode is tolerable.

The field's definition has shifted over time. Tasks that once seemed to need intelligence, such as playing strong chess or recognising printed characters, become routine software once solved, and people stop calling them AI. This is why a useful definition is task-based and why it includes methods that involve no learning: symbolic reasoning over hand-built knowledge, search and planning algorithms, and constraint solvers are AI techniques as legitimately as neural networks are. Learning-based methods came to dominate because, for perception and language, nobody can write the rules down.

Three words are routinely blurred, and separating them prevents most confusion about what "the AI" did:

• A model is a function with parameters. After training, those parameters are fixed numbers, and the model maps an input (text, an image, a feature vector) to an output (a category, a score, the next token). It has no database, no credentials, no memory of yesterday and no ability to act.
• An application is the code that prepares the model's inputs, interprets its outputs and connects them to the world: validation, prompt assembly, retrieval, calls to other services, formatting.
• A system is the application plus everything it runs on and depends on: data stores, permissions, monitoring, human reviewers, policies and the people who operate it.

When a team says "the AI approved the refund", the sentence is usually wrong in a useful way. A model produced a score; an application compared it to a threshold; a workflow, with permissions, performed the refund. If something goes wrong, the fix may belong to any layer, and you cannot find it if you only have one word for the whole stack.

A rule encodes a human's explanation of a decision. A learned model encodes what survived contact with examples. Put side by side on our inbox:

def keyword_rule(message: str) -> bool:
    return "refund" in message.lower()

keyword_rule("I paid twice but have not received the money back.")   # False  (missed: no 'refund')
keyword_rule("What is your refund policy for gift cards?")           # True   (wrong: not a billing problem)

A learned classifier replaces the hand-written test with a function whose behaviour is set by numbers, called parameters or weights, chosen so that the function agrees with labelled examples. The labelled pairs look like this, as input and target:

"I paid twice but have not received the money back."   → billing_duplicate
"Charged $19.99 two times for one order"               → billing_duplicate
"What is your refund policy for gift cards?"           → policy_question
"My parcel has said 'in transit' for nine days"        → shipping

If the examples are representative, the model generalises: it handles a message it never saw, such as "you took the payment a second time", because that message resembles the billing examples in whatever representation the model uses. Generalisation is the entire value of learning, and it is also why a learned system must be tested. A rule fails in the cases you can read off the code. A learned model fails where its training data did not cover the world, and you find those places only by measuring on data it has not seen. A prediction is a statistical judgement, not a derivation; it is useful precisely because it is usually right, and it needs evaluation precisely because it is not always.

Building a learned component is a lifecycle, and most of it is ordinary engineering. The sequence below is written for a supervised classifier like the support router; other kinds of AI use different parts of it.

1. 1

   Data and labels

   The model can only learn what the data shows. Labels come from people, so their inconsistency, their bias and any personal data inside the messages become properties of the system. This stage usually decides success more than the choice of algorithm.
2. 2

   Representation

   Text must become numbers. A hand-built feature (does the message mention a payment term?) is the simplest form; modern models use tokens and learned vectors, covered in the Tokens and Embeddings lessons.
3. 3

   Training and evaluation

   Training adjusts parameters to reduce error on examples; evaluation measures error on examples the model did not train on. The two are separate on purpose, and the next sections show why.
4. 4

   Deployment, inference, monitoring

   Inference runs the frozen model on live inputs. Monitoring watches inputs, outputs and downstream outcomes, because the world changes after deployment, and feedback becomes the next training set.

Many teams skip the middle of this loop. If you call a hosted pre-trained model, someone else did stages 1 to 5; you still design the representation of your inputs (the prompt, retrieved context), evaluate it on your own cases, deploy and monitor. Software engineering is not displaced by the model; it surrounds it. And a system built on rules or search has no training stage at all, so do not read this loop as the definition of AI. The Training vs Inference lesson examines stages 4 and 7 in detail.

It helps to name tasks by their input and output contract, because the contract tells you what can be evaluated and what can go wrong. Using the store as setting, with deliberately concrete signatures:

// Classification: one label from a fixed set
type Classify    = (message: string) => { label: 'billing' | 'fraud' | 'shipping' | 'cancel'; p: number };

// Regression: a number
type Regress     = (order: { items: number; zone: string; dayOfWeek: number }) => { deliveryDays: number };

// Recommendation / ranking: an ordered list
type Recommend   = (userId: string, n: number) => { productId: string; score: number }[];

// Anomaly detection: how unusual is this?
type Anomaly     = (txn: { amount: number; country: string; deviceId: string }) => { anomalyScore: number };

// Perception: unstructured signal in, structured data out
type Perceive    = (photo: Uint8Array) => { damaged: boolean; boxes: [number, number, number, number][] };

// Search: query in, ranked evidence out
type Search      = (query: string, k: number) => { docId: string; score: number }[];

// Generation: open-ended content out
type Generate    = (prompt: string) => string;

// Planning: a sequence of steps toward a goal under constraints
type Plan        = (goal: string, constraints: string[]) => { step: string }[];

The categories overlap. A recommender is ranking, a search engine uses a ranking model, a fraud detector is usually anomaly detection and classification at once, and a generative assistant may call search and then generate. What matters is that the output type determines how you check it. A class label can be compared with a ground truth; a delivery estimate has an error in days; a ranking has an order-quality measure; a free-text reply has no single correct answer, so it requires rubrics, sampled review or task-level outcomes. The more open-ended the output, the harder the correctness question, which is a main reason generative features need more surrounding engineering than classifiers do.

A classifier returns a category. A generative model returns new content. Neither one changes the state of the world. An action, such as issuing a refund, is something an application does, and it needs authorisation and a trustworthy source of facts. This matters because language models are fluent, and fluency feels like competence.

Suppose the model drafts: "We found your duplicate charge and a refund of $42.10 will arrive in 3 to 5 business days." Every number and every claim in that sentence is text that the model produced because it reads like a good support reply. None of it came from the payments system. For the sentence to be true, the application must have looked up the order, confirmed two captures, confirmed the refund was created, and then inserted those facts into the reply. The language model can phrase them well; it cannot be the source.

The pattern generalises. The model may propose an action; the application decides whether it is allowed and performs it with its own credentials against systems of record. Whether you can mark a proposal as an automated decision or only a recommendation for a human is a product and policy choice, not something the model's confidence can settle. Later lessons treat the mechanics in depth: hallucinations for why fluent text can be wrong, and RAG for supplying retrieved evidence. Note that retrieved evidence is still not verified fact; it is a document that may be stale or wrong.

When a model learns, it is doing statistical optimisation: nudging numeric parameters so that its outputs fit many examples better. Nothing in that sentence requires understanding in any human sense, and nothing in it proves its absence either. Describe behaviour rather than inner life. A model can do things that look like reasoning, such as multi-step arithmetic or following a policy through a conditional, and can fail in ways no careful person would, for example by contradicting itself between paragraphs or inventing a plausible order number. Both observations are true of the same model.

Two claims are tempting and both are wrong. One says the model "just memorises" and so can only repeat training text. Models do sometimes reproduce memorised passages, but their central ability is generalisation: applying learned regularities to inputs that were never seen, which is how the classifier above handles a phrasing nobody labelled. The opposite claim says the model "understands" like a person and therefore does not need to be checked. Fluency is not factual reliability. A system optimised to produce plausible text produces text that is plausible whether or not it is true, and it does so in the same confident tone either way. Reliability has to be measured, task by task, against ground truth, and the claim "it works" should always carry the qualification "on which inputs, at what error rate".

To make "learned parameters" concrete, shrink the router to one question: is this message about a duplicate charge? Replace the whole text with two numeric features. Both are illustrative measurements between 0 and 1: x1 is a payment-term score (how strongly the message mentions payment, paying twice, charges) and x2 is a negative-sentiment score. The model is a linear score:

z = w1*x1 + w2*x2 + b          z: real number (any sign)
p = sigmoid(z) = 1 / (1 + e^(-z))     p: between 0 and 1
flag the message if p >= t           t: decision threshold

The sigmoid squashes any real z into the interval (0, 1), so that large positive scores mean near-certain flagging and large negative scores the opposite; z = 0 is exactly p = 0.5. Take the illustrative weights w1 = 2.5, w2 = 1.5, b = -2.0. They are chosen for the example; in a trained model, an optimisation procedure would have found numbers like them. Score three messages.

A: "I paid twice but have not received the money back."  x1 = 1.0, x2 = 0.8
   z = 2.5*1.0 + 1.5*0.8 - 2.0 = 2.5 + 1.2 - 2.0 = 1.70
   p = 1 / (1 + e^-1.70) = 1 / (1 + 0.1827) = 0.846      -> flagged at t = 0.5

B: "Charge looks fine, thanks"                            x1 = 0.9, x2 = 0.1
   z = 2.25 + 0.15 - 2.0 = 0.40       p = 0.599          -> flagged (wrongly)

C: "This is useless, I am furious"                        x1 = 0.0, x2 = 0.9
   z = 0 + 1.35 - 2.0 = -0.65         p = 0.343          -> not flagged

import math

W1, W2, B = 2.5, 1.5, -2.0   # illustrative weights, not learned from real data

def score(x1: float, x2: float) -> tuple[float, float]:
    z = W1 * x1 + W2 * x2 + B
    return z, 1 / (1 + math.exp(-z))

for x1, x2 in [(1.0, 0.8), (0.9, 0.1), (0.0, 0.9)]:
    z, p = score(x1, x2)
    print(f"x1={x1} x2={x2} z={z:.2f} p={p:.3f} flag={p >= 0.5}")
# x1=1.0 x2=0.8 z=1.70 p=0.846 flag=True
# x1=0.9 x2=0.1 z=0.40 p=0.599 flag=True
# x1=0.0 x2=0.9 z=-0.65 p=0.343 flag=False

Message B was flagged even though nothing is wrong, because the crude payment-term score was high and the model has only two features to go on. That is a property of this toy representation, not of classifiers in general, but the lesson transfers: a model can be no better than what its representation lets it see.

The geometry explains the behaviour. The flagging rule p ≥ 0.5 is the same as z ≥ 0, which is 2.5·x1 + 1.5·x2 ≥ 2: a straight line in feature space with flagged messages on one side. Training, in this model, means moving that line (by changing the weights and bias) until it separates the labelled examples as well as possible. More expressive models draw curved or very high-dimensional boundaries, but the idea of a boundary learned from data is the same.

The threshold is a business decision, and probabilities are not guarantees

The threshold t is separate from the model. Raising it to 0.7 means z ≥ ln(0.7/0.3) ≈ 0.847, pushing the boundary right and up; lowering it to 0.3 means z ≥ −0.847, pulling it left and down, as the dashed lines show. A higher threshold flags fewer messages, so it produces fewer false positives (needless escalations) and more false negatives (missed duplicate charges). Which error costs more is a product question: a missed duplicate charge leaves a customer unrefunded and angry, while a false alarm costs a minute of a human's time.

Also resist reading p = 0.846 as "84.6% likely to be right". The sigmoid always outputs a number between 0 and 1 whether or not the model is any good. A calibrated model is one where, among messages scored near 0.85, about 85% really are duplicates; that is a property you check on held-out data, and many models are over- or under-confident until adjusted. Treat an uncalibrated score as a ranking signal, not a probability.

A model that is evaluated on the same examples it trained on only tells you how well it remembered them. So data is split three ways: a training set that the parameters are fitted to, a validation set used while building (to choose the threshold, compare models, stop early), and a test set touched rarely, to give an unbiased final estimate. If you tune against the test set until it looks good, it has quietly become validation data and the estimate is optimistic.

Suppose we hold out 200 messages, of which 40 really are duplicate charges. At threshold 0.5 the classifier flags 44 messages: 32 correctly and 12 incorrectly, and misses 8 real cases.

precision = TP / (TP + FP) = 32 / 44  = 0.727   of the flagged messages, how many were real
recall    = TP / (TP + FN) = 32 / 40  = 0.800   of the real cases, how many were found
accuracy  = (TP + TN) / 200 = 180/200 = 0.900
F1        = 2PR / (P + R)  = 0.762

Always predict "not duplicate":  accuracy = 160/200 = 0.800  (recall = 0)

Accuracy of 0.90 sounds excellent, and it hides the problem. Duplicate charges are only 20% of this test set (class imbalance), so a model that never flags anything already scores 0.80 while catching no duplicates at all. Precision and recall answer the questions a support lead actually asks: how much of the escalation queue is noise, and how many real cases slip past? Moving the threshold trades one against the other:

t     TP   FP   FN   TN    precision   recall
0.3   37   40    3  120      0.481      0.925
0.5   32   12    8  148      0.727      0.800
0.7   26    4   14  156      0.867      0.650

Figure: the same three rows as bars, so the trade-off is visible at a glance.

No threshold is correct in the abstract. A team that reviews every flagged ticket by hand can afford 0.3; a team that auto-sends a template reply must not, and may choose 0.7 and accept missing more cases.

Why the test score does not promise production performance

Test numbers describe the test distribution. The live distribution differs in at least three ways. First, distribution shift: after a pricing change, a new payment provider or a viral outage, the messages customers send are different from the ones the model was trained on, and the errors appear exactly where you have no data. Second, the class balance in production may differ from the test set; with the same recall and false-alarm rate, a rarer positive class makes precision drop, because the same number of false alarms now outnumbers the real cases. Third, a test set drawn from past tickets cannot contain the new kinds of messages that tomorrow brings. This is why monitoring is a lifecycle stage and not an afterthought: compare input statistics with training data, sample live predictions for human labelling, and track the downstream outcome (did the case turn out to be a duplicate charge?).

The class-balance effect is easy to underestimate, so try it: the figure keeps this model's recall and false-alarm rate fixed and changes only how common real duplicates are.

Each risk below is concrete in the support setting and none of them is solved by a better model alone.

Biased labels. If past agents routinely escalated complaints written in certain dialects or by customers in certain regions more slowly, and those decisions became the labels, the model learns to reproduce that slow-down; accuracy against the labels would even look good. Detecting it requires evaluating per-group error rates, not one aggregate number, and fixing it can require changing the labels or the process that created them, not the algorithm.

Personal data exposure. Support messages contain names, addresses and partial card details. Those may end up in training sets, logs, prompts sent to a hosted model, or in a model's memorised output. Redaction before storage, access control, retention limits and a clear record of what goes to which provider are application and system decisions.

Hallucinated responses. A generated reply can state a refund policy that does not exist. The controls live outside the model: ground the reply in retrieved policy text, restrict claims that need verification to values inserted from systems of record, and sample outputs for review.

Inappropriate automation. Whether to automatically deny a refund is a risk and accountability decision. Deterministic guardrails, such as hard limits on refund amounts, allow-lists of actions, schema validation of model output and rate limits, bound the damage of any single wrong prediction. Human review is a design element for cases that are high-impact, low-confidence or novel, and its value depends on reviewers having the context and time to actually disagree. See AI Security for the threat model of deployed AI systems.

An honest engineering answer is often "no model". If the behaviour is a fixed business rule ("free shipping above a threshold"), a straightforward calculation (an invoice total), an exact lookup (the status of order 8841) or low-risk routing with a handful of clear signals, deterministic code is better on almost every axis that matters in production:

• Correctness: it is exact by construction, while a model is right on average.
• Predictability and auditability: the same input gives the same output, and any outcome can be explained by pointing at a line and a version of it.
• Maintenance: a policy change is a code change and a test; for a model it can mean new data, retraining, re-evaluation and a rollout.
• Cost and latency: a string comparison costs microseconds on a CPU; a model call adds compute, latency and, for hosted models, per-request fees.

AI becomes worth its costs when the target function is too fuzzy or varied to specify, when examples are plentiful, and when an imperfect answer is acceptable or can be checked. The strongest designs combine the two: rules for what must be exact, a model for the fuzzy front door (read this message, extract these fields), and rules again around the output.

For each task, decide between deterministic code, a learned classifier, a generative model or a hybrid, and justify the choice before reading the reference solution.

1. 1

   Invoice total calculation

   Deterministic code. The total is sum(quantity × unit price) plus tax and discounts, defined by arithmetic and law. A model would be approximately right on average, which is a defect in accounting. The solution is exact, unit-testable and auditable, and its failure mode (a bug) is fixable and visible.
2. 2

   Spam filtering

   A learned classifier, wrapped in rules. Spammers adapt, so a fixed keyword list decays, and examples of spam and not-spam are abundant. Keep deterministic layers for known-bad senders and authentication checks, evaluate precision first (a false positive loses a real email), and monitor drift because adversaries change behaviour.
3. 3

   FAQ response

   A hybrid. If the FAQ has a few dozen stable answers, search or rules that return the approved text verbatim may be enough and cannot invent policy. For a large, varied knowledge base, retrieval plus generation can phrase a tailored answer, but it must quote or cite the retrieved source, and the application should decline when no source supports an answer.
4. 4

   Refund execution

   Deterministic, authorised code. A model may help identify the intent or draft the message, but creating a refund moves money, so it requires identity, permission, policy checks, idempotency (so a retry does not refund twice) and an audit log. If a model proposes the action, the application validates and performs it, and above a risk threshold a human approves.

Notice that three of four answers contain deterministic code and only one is purely learned. That ratio is typical. The skill is not choosing "AI" or "no AI" once but drawing the boundary between them for each piece of the system, so that the model's imperfection lands where it costs least.

This is the first lesson of the AI Foundations track, and the vocabulary it sets up carries through the rest. With the boundary between rules, learned models and applications in place, the next question is how the learned part itself is organised. The words machine learning, deep learning and generative AI describe overlapping approaches rather than a ladder, and which one fits depends on the data and the task, which the next lesson covers. After that, Training vs Inference opens the two lifecycle stages treated here only as boxes: how parameters are learned, and what running a frozen model in production involves. When you reach language models, Tokens Explained shows how text becomes the numbers that a representation step like the one in our toy example provides.