Artificial Intelligence: A Practical Starting Point

The word "AI" now covers a spam filter, a chess engine, a fraud model, a chatbot, and a robot arm. That breadth is why product conversations go in circles: two people say AI and mean systems with almost nothing in common. Getting the vocabulary straight takes fifteen minutes and it prevents a large share of the confusion that follows.

Nested, not parallel

Artificial intelligence is the outer field: building systems that perform tasks we associate with intelligence — recognising patterns, predicting, planning, conversing. It includes approaches that involve no learning at all. A search algorithm, a constraint solver, and a rules engine are all AI, and several of them are still the correct answer to real problems.

Machine learning is the subset where behaviour is derived from data rather than written by hand. You supply examples; the system fits a function.

Deep learning is the subset of machine learning built on multi-layer neural networks, which is what made unstructured data — images, audio, text — tractable.

Foundation models and LLMs are large deep-learning models trained on broad data and adapted to many tasks. This is the layer most current products sit on.

Agents are not another layer down. An agent is an architecture: a model wired into a loop where it can call tools, observe results, and act. The same model is a chatbot in one wiring and an agent in another. Confusing a capability with an architecture is behind a lot of overpromising, because "we built an agent" says something about your plumbing rather than about what the system can do.

The practical consequence of the nesting: a problem that does not need learning should not use it. A deterministic rule is cheaper, faster, testable, and explainable, and the discipline of asking "could a rule do this?" first eliminates a surprising number of projects.

Everything deployed is narrow

Every system running in production today is narrow: competent inside the distribution it was built for, and degrading unpredictably outside it. The important word is unpredictably. A human who does not know something usually signals it. A model outside its distribution produces an answer with the same confidence as one inside it, and that mismatch — between confidence and reliability — is the single property that most often surprises people.

This is why the same three practices show up in every serious deployment regardless of domain: evaluate on data resembling reality rather than the training set, keep a human in the loop wherever an error is expensive, and monitor after launch because the world moves even when your model does not.

It also gives you a useful way to read claims. "Understands," "reasons," and "knows" are descriptions of behaviour, not mechanism. When a vendor uses them, the question worth asking is: what does it do when it does not know? A good answer names specific failure modes. A vague answer usually means nobody measured.

Route the problem before comparing tools

Most projects stall because a framework was chosen before the task was defined. Write two sentences first: what decision or action must this system produce, and what does a wrong answer cost? Those two determine nearly everything else — the accuracy bar, whether a human reviews, and how much you can spend per call.

Then route:

Structured, tabular data with a clear target — churn, pricing, risk, forecasting. This is classical machine learning, and scikit-learn is where it lives. It remains the largest category of real business problems and the one most often over-engineered.

Images and video — a deep learning framework for the recognition, with OpenCV handling capture, preprocessing, and the drawing of results.

Text understanding at scale — the choice is between a small task-specific model and a general language model, which comes down to cost, latency, and how narrow the task is.

Language generation and open-ended tasks — a foundation model, hosted or local. Ollama covers the local case.

Multi-step work with tools — an agent architecture, and the frameworks that structure it.

The rest of this track walks through those tools one at a time: what each is genuinely for, when it is the wrong choice, and the failure modes that show up once real work runs through it.

Common mistakes

Choosing a framework before defining the task. The most reliable way to stall a project, and it is entirely preventable with two written sentences.

Using learning where a rule would do. Rules are cheaper, testable, and explainable. Learning is for the cases where the rule cannot be written.

Reading confidence as reliability. They are unrelated, and the gap between them is where production incidents come from.

Treating "agent" as a capability level. It describes how the system is wired, not how good it is.