What Is Machine Learning?

Machine learning is a way to get a computer to do a job by showing it examples, not by writing every rule yourself. You collect inputs that already have answers. You fit a function that maps those inputs to those answers. You measure how often the function is wrong on examples it has never seen. That last sentence is the whole subject. Neural nets, “AI,” and vendor APIs are families of functions and measuring sticks. They do not replace the loop.

A normal program says: if the subject contains the word invoice, send it to billing. That works until the next thousand tickets use different words, different languages, or a screenshot instead of a subject line. The ML program is: collect tickets with labels, search for knobs that match those labels, then refuse to believe the result until a held-out pile agrees.

You already know the cheap version of this loop. A new hire writes ten keyword rules. You score them on last week’s tickets. You keep the rules that beat “always search.” Machine learning is that habit with more knobs and a more honest exam.

Fit, then measure, on new data

Three verbs, in order:

1. Fit — change the function so it matches the labeled examples you are allowed to look at (the training set).
2. Measure — compute a number that says how often it is wrong, or how expensive the mistakes are.
3. On new data — the number that counts is the one from examples the fitting did not see.

Skip any verb and you are doing something else. Fitting without measuring is a demo. Measuring on the same rows you fitted is a memorization contest. Measuring on new data without a clear goal is a well-scored answer to the wrong question.

Generalization is the name for “still works tomorrow.” A lookup table of yesterday’s tickets does not generalize. A function that captured a pattern (the word “down” plus a VIP flag predicts urgent) might. You cannot see generalization by staring at training accuracy. You need a split. The next lessons will make that split a ritual.

Three families

Joeven agents mostly use supervised models: classifiers that pick a tool, rankers that order chunks, embedders that turn text into a list of numbers. Even when the brain is a hosted language model, you still need labeled traces and a score. That is the same habit. The model family is not the scientific method. The method is: examples, a function, a number on unseen work.

Unsupervised work still shows up. You cluster failed traces to name failure modes. You compress a conversation into a short list of numbers for search. You flag oddballs. Those are not classifiers until you later promote a cluster into a label and train.

Reinforcement shows up whenever you cannot label every step. The user did not mark each tool call. They closed the ticket, or they did not. A reward after the episode is a delayed label on a whole path. You do not need a research stack to use the idea. You need a number you can compute and a policy you can compare to a dummy.

A model is a function with knobs

A model is a function from input to output. The shape of the function is your choice (a linear score, a small net, a nearest-neighbor vote). The parameters are the knobs inside that shape. Learning is the search for knobs that match the labels.

Suppose you want to guess if a ticket is urgent from one number: how many times the word “down” appears.

score = w * downs + b

Then you pick a cutoff. If the score is at least 0.5, predict urgent. w and b are parameters. You can set them by hand. You can search them with a loop. Both are machine learning. Gradient descent later replaces you as the searcher. The loop does not change: propose knobs, score them, keep the better ones.

You do not start by believing the function. You start by scoring it. Accuracy on five toy tickets is not a product metric, but it is enough to feel the idea: some knobs match the labels, some do not, and you can print the difference.

A hyperparameter is a knob you choose and do not fit inside that loop: the cutoff, the learning rate, which words count as features. Parameters are fitted. Hyperparameters are chosen on a validation pile. Mixing those two jobs is how people accidentally train on the exam.

Run to execute this in your browser. Nothing is sent to a server.

What printed: three lines. w 0.0 b 0.0 acc 0.4 — a flat score of zero never clears 0.5, so every ticket is “not urgent.” Two of five labels are 0, so accuracy is 2/5. w 0.4 b -0.5 acc 0.8 — the score grows with “down” counts, but two downs still sit under the 0.5 cutoff, so one urgent row is missed. w 1.0 b -1.5 acc 1.0 — zero and one “down” stay below the cutoff; two and above go urgent. Hand-tuning is still machine learning: a slow optimizer (you). A pair that looks “almost right” can still miss a row. You only know after you print. That is why you will later measure on new tickets, not only on the five you fitted.

Change w and b and run again. Watch accuracy jump. Then notice the trap: 1.0 on five rows is not a ship decision. It is a story about five rows.

What ML is not

It is not magic. Bad labels make bad policies. If “urgent” means three different things to three labelers, the function will average the confusion.

It is not “the model understands.” It is curve fitting with a test set. A router that picks sql for “revenue” does not know finance. It saw that pattern enough times, or a nearby embedding, or a keyword cousin.

It is not a substitute for a goal. A 99% accurate classifier that answers the wrong question is a well-measured failure. “Is this English?” is not “did we close the ticket without a forbidden refund?”

It is not the same as prompting. Prompting changes the input to a frozen function. Fine-tuning changes weights. Both can overfit an eval. Both still need the fit-measure-on-new-data loop.

It is not “bigger model always wins.” A keyword rule that is already 96% on a frozen slice is the thing to beat. Compute, latency, and drift are part of the comparison.

Ask first: what would a dumb rule score? If “always call search” is already 80%, your classifier has a high bar. Machine learning is the move when the rule book is too large to write and you can measure the rest.

Common mistakes

• Fitting on all the logs you have, then reporting that number as “accuracy.”
• Changing the prompt until the demo passes, then calling the demo a test set.
• Treating a hosted model as if it learned from your tickets. It did inference on your tickets. Learning is a different product.
• Optimizing a metric that is not the product (fluency, thumbs-up, “the JSON parsed”) while the agent still calls the wrong tool.
• Skipping the dummy. Without a baseline, every model is a hero.

How agents use this

Tool routing (“search or SQL?”), memory (“which chunk?”), and “did we finish the ticket?” are all prediction problems. When you log traces and score them, you are doing ML even if the brain is an API.

Write the metric before you pick the model. “Lower the loss” is not a product. “On held-out traces, the router matches the senior-engineer tool, and the agent does not call refund on FAQ tickets” is a product. The rest of this track is the machinery under that sentence: features, splits, loss, ranking, and the loop you use to judge an agent.

A production agent is a function from a conversation state to an action. You will not write every rule for that function. You will collect examples, fit something (a rule, a prompt, a small classifier, rarely a fine-tune), and measure it on a freeze of traces it did not train on. That is machine learning. The later pages name the parts. This page is the habit.

Tip:Write the metric before you pick the model. “Lower the loss” is not a product.