The vocabulary, without the theatre.

An agentic system is software that pursues a goal across several steps, choosing its own actions and tools along the way, instead of following a fixed script.

The dividing line from ordinary automation is who decides the order of operations. A sequence you drew in advance is automation; a system that decides what to do next, checks whether it worked and tries again is agentic. That autonomy is also the risk, which is why the ones that survive contact with production have a narrow remit and a human approval step on anything expensive.

An AI agent is a single autonomous worker inside such a system: it receives a task, calls tools to get it done, and reports back.

In practice the useful ones are far less glamorous than the word suggests — inbox triage, quote drafting, invoice matching, chasing missing documents. A good agent does one job with a defined set of tools and escalates anything ambiguous. An agent with access to everything and a vague brief is a liability.

Orchestration is the layer that decides which model, tool or agent handles each step of a task, and in what order.

It is where most of the real engineering in an AI product lives, and where most of the cost sits. Getting it right usually means routing the easy 80% to a small cheap model and reserving the expensive one for the cases that need it.

A tool call is a model asking your software to do something — query a database, send an email, fetch a file — and then using the result.

This is the mechanism that turns a chatbot into a system that can act. It is also the security boundary: a model can only do what its tools allow, so the tool list is the real permission model. Design it like you would an API for an untrusted client, because that is what it is.

Human-in-the-loop means a person reviews, approves or corrects the system output before it takes effect.

The design question is not whether to have it but where to put it. Approval on every step makes the system slower than doing the work by hand; approval on nothing makes the first bad output someone else’s problem. Put it wherever an error costs money, reputation or a relationship.

Workflow automation executes a fixed sequence of steps that a person defined in advance, with no judgment of its own.

This is what most companies actually need, and it is dramatically cheaper and more predictable than anything agentic. If the process can be written as a flowchart without the phrase "it depends", you do not need AI in it — you need the flowchart, built properly.

RPA — robotic process automation — drives existing software through its user interface, clicking and typing the way a person would.

Useful when a system has no API and never will. Fragile by nature: it breaks whenever the interface it imitates changes. Treat it as a bridge to a real integration, not a destination.

An LLM — large language model — is a model trained on very large amounts of text to predict what comes next, which turns out to be enough to summarise, classify, translate, write and reason about language.

It is a text engine, not a database and not a calculator. Everything it knows about your business has to be put in front of it at the time you ask. Most disappointing AI projects are ones that expected the second thing from the first.

A foundation model is a large general-purpose model trained once at great expense and then adapted to many specific uses.

For almost every company the correct relationship with a foundation model is renting one through an API. Training your own is a capital project measured in millions; the interesting work is what you build on top.

Fine-tuning continues training an existing model on your own examples so it adopts a particular format, tone or narrow skill.

It teaches behaviour, not facts — a common and expensive misunderstanding. If you want the model to know your product catalogue, use retrieval. If you want it to always answer in your house style or emit a specific structure, fine-tuning can help. Try prompting and retrieval first; they solve most of what people reach for fine-tuning to fix.

RAG — retrieval-augmented generation — fetches relevant documents from your own data and puts them in front of the model before it answers.

This is how a model comes to know things it was never trained on, and it is the default architecture for anything that answers questions over company knowledge. The quality of a RAG system is almost entirely the quality of its retrieval; the model is rarely the bottleneck.

An embedding is a list of numbers representing a piece of text, positioned so that things with similar meaning sit close together.

It is what makes search work by meaning rather than by keyword — a question about "late invoices" can find a document titled "overdue receivables". The trade-off is that similarity is not relevance, so a pure embedding search happily returns things that are related to the question but do not answer it.

A vector database stores embeddings and finds the closest matches to a query quickly.

Below a few hundred thousand documents you very likely do not need a dedicated one — Postgres with pgvector is enough and is one less system to run. The decision should come from your document count and query load, not from a vendor’s architecture diagram.

The context window is the maximum amount of text a model can consider at once, counting both what you send and what it writes back.

Bigger windows have not made retrieval obsolete. Accuracy degrades noticeably for information buried in the middle of a very long input, and you pay for every token you send, on every call. Sending the right ten pages beats sending all four hundred.

A token is the unit models read and write — roughly three quarters of a word in English, and somewhat less efficient in Italian.

Tokens are the billing unit, so they are how you should reason about cost. A feature that looks cheap per call can be ruinous at volume; the arithmetic is worth doing before you build, not after the first invoice.

Inference is the act of running a trained model to get an answer, as opposed to training it in the first place.

For a company using AI rather than building it, inference is essentially the entire cost line. It recurs with every use, which means an AI feature is an operating expense, not a one-off build.

A hallucination is a confident, fluent, wrong answer — output that is well-formed but not grounded in anything real.

It is not a bug that gets patched; it is a property of how these models work. You manage it rather than eliminate it: ground answers in retrieved sources, make the system cite where it got something, and design so that a wrong answer is caught rather than acted on.

Model drift is the gradual decline of a system’s accuracy as the world it operates in changes.

Your suppliers change their invoice layouts, your product names change, the provider ships a new model version. A system that was right at launch and has not been measured since is not a working system — it is an unmeasured one. This is the argument for evals existing before go-live.

Prompt injection is an attack where instructions hidden in content the model reads cause it to ignore its own instructions.

It matters the moment your system reads anything from outside — emails, web pages, uploaded documents, supplier PDFs. There is no complete fix today. The practical defence is to limit what the model’s tools can do, so that a successful injection cannot reach anything valuable.

Structured output constrains a model to return data in a fixed shape, such as JSON matching a schema you defined.

This is what makes a model usable as a component rather than a chat window. It removes an entire category of fragile parsing code, and it is the difference between a demo and something another system can depend on.

An eval is a test set of real cases with known correct answers, used to measure whether an AI system actually works and whether a change made it better or worse.

This is the single practice that separates AI systems that survive from ones that quietly rot. It does not need to be sophisticated — thirty real cases in a spreadsheet, scored honestly, beats an impression. Without evals you cannot change a prompt or a model version without gambling.

A guardrail is a hard limit on what a system is permitted to do or say, enforced outside the model rather than requested of it.

The distinction matters: instructing a model not to do something is a preference, while refusing to give it the tool is a guarantee. Spending limits, approval thresholds and read-only access are guardrails. A polite sentence in the prompt is not.

AI-native describes software designed from the start around what models can do, rather than existing software with AI features added on.

The honest version of this term describes a real difference in how a product is shaped — what the interface asks for, where the uncertainty lives, what happens when the model is unsure. The marketing version means a chat box in the corner. Ask which one you are being sold.

An MVP — minimum viable product — is the smallest version of an idea that real users can genuinely use, built to learn whether it is worth continuing.

The word "viable" is the load-bearing one and the one that gets dropped. An MVP that nobody can actually complete a task with teaches you nothing except that you built the wrong thing quickly.

A pilot is a limited trial of an AI system with a small group or a narrow slice of the work, run to decide whether to commit.

The failure mode is the pilot that succeeds and goes nowhere, because it was built on hand-cleaned data, without integrations, and with the team paying unusual attention. Scope a pilot so that the answer it gives you is about production, not about the pilot.

Production is the state where a system is used for real work by people who did not build it, with real data and real consequences when it is wrong.

Most of the engineering cost lives between a working demo and this. Error handling, edge cases, permissions, monitoring, the days the provider has an outage, and someone who owns it on a Tuesday afternoon — none of which the demo needed.

Observability is being able to see what an AI system did and why, after the fact — which inputs it received, which tools it called, what it produced.

Without it, "the AI got it wrong" is unactionable. With it, you can find the twelve cases a week where it fails and fix the pattern. For anything agentic this is not optional; a multi-step system you cannot replay is one you cannot debug.

Forward deployed engineering is a delivery model where an engineer from the supplier works inside the client’s own team, repository and data until the system is running in production.

It is the opposite of a consulting handoff. The engineer learns how the business actually runs rather than reading a brief about it, which is why it works for the gap between a pilot that impressed everyone and a system anyone relies on. Choose it when you already know what needs building and need hands rather than advice.

Handover is the point at which the client’s own team can run, change and fix the system without the people who built it.

It is a deliverable, not an event, and it is the part most easily skipped. Concretely it means documentation someone outside the project can follow, a walkthrough with the people who will own it, and access transferred. If handover keeps slipping, that is usually a business model rather than a schedule.

Computer vision is software that extracts information from images and video — counting, inspecting, locating or reading what is in a picture.

The mature, boring applications are the profitable ones: reading meters, checking labels, counting stock, spotting defects on a line. Accuracy depends far more on consistent lighting and camera position than on the model.

OCR — optical character recognition — converts an image of text into text a computer can process.

Solved for clean printed documents, still genuinely hard for handwriting, poor scans and complex tables. Modern vision models handle messy real-world documents far better than classical OCR, at meaningfully higher cost per page — which is a decision to make deliberately, per document type.

Document extraction pulls specific fields out of unstructured documents — invoices, delivery notes, contracts, tenders — into structured data a system can use.

This is one of the highest-return uses of AI in an Italian SME, because the input is a stack of PDFs and the output is a row in the gestionale. The hard part is never the common case; it is the supplier whose layout changes, the scan that is upside down, and knowing when the system should decline to guess.

Inference cost is what you pay per use of a model, normally billed per token in and per token out.

It scales with usage, so it belongs in the operating budget from day one. The costs that surprise people are the invisible ones: long system prompts sent on every call, retrieved context nobody trimmed, and agents that retry. Model the arithmetic at expected volume before you build.

The EU AI Act is European legislation that regulates AI systems according to risk, with obligations phasing in through 2026 and 2027.

Most SME uses — automating internal document handling, drafting, summarising — sit in the low-risk tier and carry transparency obligations rather than heavy ones. What genuinely changes the picture is anything touching employment decisions, creditworthiness or biometrics. This is not legal advice; if you are near those categories, get some.

Data residency is the question of which countries your data is stored and processed in, and under whose law it therefore falls.

For European companies this decides which providers are usable before any technical comparison starts. Most major providers now offer EU processing, and several offer zero-retention terms — but the defaults are frequently not the ones you want, so it is worth checking rather than assuming.

Vendor lock-in is the cost of leaving a supplier — how much of what you paid for cannot come with you.

In AI work the risk is rarely the model, which is genuinely swappable, and almost always everything around it: the prompts, the evals, the integrations and the data pipeline. Ask who owns the repository and whether the evals are yours. If the answer is vague, that is the answer.