Technical Guides

A large language model is a very capable writer with a very specific weakness: it only knows what it learned during training, and that training stopped at a fixed point in the past. Ask it about your company's return policy, last quarter's pricing, or a document you wrote yesterday, and it has nothing to draw on except guesswork. Retrieval augmented generation, usually shortened to RAG, is the technique that fixes this. It gives the model a way to look things up before it answers.

When people want a language model to know something new, they usually reach for one of three tools: prompting, fine tuning, or retrieval augmented generation. They sound interchangeable. They are not. Each one changes a different part of the system, costs a different amount, and suits a different kind of problem. Choosing the wrong one is the most common way AI projects stall.

Every modern AI search, recommendation, and retrieval system rests on one quiet idea: that meaning can be turned into numbers. An embedding is exactly that, a list of numbers that captures what a piece of text or a product is about. Understanding embeddings is the key to understanding how machines compare things by meaning instead of by matching words.

A traditional database answers exact questions. Find the customer with this ID, the orders placed on this date, the products in this category. It is fast and precise, but it has no idea what anything means. A vector database answers a different kind of question: find the things most similar in meaning to this one. It is the storage layer that makes semantic search and retrieval augmented generation possible at scale.

For most of the web's history, search meant matching words. You typed "hotel pool hours" and the engine looked for pages containing "hotel", "pool", and "hours", roughly in that order of importance. It worked well enough that an entire industry grew up around choosing the right words. Semantic search changes the rule. Instead of matching the words you typed, it matches what you meant. Understanding the difference explains a great deal about how AI assistants find, or fail to find, your business.

Every conversation with a language model happens inside a box of fixed size. Everything the model can consider at once, your question, the instructions, any documents you supplied, and the conversation so far, has to fit inside that box. The box is called the context window, and it quietly shapes what AI can and cannot do for you.

When you type a sentence to a language model, it does not see letters or even words. It sees tokens. Tokens are the small units a model actually reads, counts, and bills by, and once you understand them, several puzzling things about AI start to make sense: why it struggles with some spellings, why prices are quoted per million tokens, and why a context window is measured the way it is.

Ask a language model a question it cannot actually answer and it will often answer anyway, fluently and confidently, with details that sound right and are not. This is called hallucination. It is the single most important limitation to understand before trusting AI with facts about your business, and it is also a solvable problem once you know where it comes from.

A prompt is simply what you say to a language model. Prompt engineering is the craft of saying it well. The phrase sounds technical, but the underlying skill is familiar to anyone who has briefed a new colleague: the clearer the brief, the better the work. A handful of habits account for most of the improvement.

A language model on its own can only do one thing: produce text. It cannot check today's weather, look up a booking, send an email, or query a database. Everything it says comes from what it learned in training plus whatever you put in the prompt. Function calling, also called tool use, is what lets a model reach outside itself. It is the bridge between an AI that talks and an AI that does.

Most explanations of retrieval augmented generation focus on the glamorous parts: the embeddings, the vector database, the language model writing the answer. But two quieter steps decide whether the whole thing actually works. Chunking determines what gets stored. Reranking determines what gets used. Get them wrong and even the best model answers from the wrong material.

Large language models can feel like magic: you type a question and a thoughtful paragraph appears. Under the surface the mechanism is simpler than it looks, and knowing it explains both what these models do well and where they fall down. At the center is one repeated act: predicting the next piece of text.

Most of the information a business publishes is written for people: paragraphs, brochures, menus, pages of prose. People read it fine. Machines struggle, because a paragraph does not say which words are the facts. A knowledge graph fixes that by storing facts as connections between things. It is one of the oldest ideas in computing and one of the most useful in the age of AI.

If a knowledge graph is a collection of facts, an ontology is the rulebook that says what kinds of facts are allowed. It defines what types of things exist, what properties they can have, and how they are permitted to relate. The word comes from philosophy, where it means the study of what exists. In data it means something more practical: a shared blueprint so that everyone, and every machine, means the same thing by the same words.

The two words get used interchangeably, and they are related, but they describe different amounts of structure. A taxonomy sorts things into categories. An ontology describes how things relate. Knowing which one you have, and which one you need, saves a lot of confusion when organizing information for people and for machines.

Your business probably has more than one name. The legal name on the invoice, the brand on the sign, the shortened version guests use, the misspelling that shows up in reviews, the old name from before the rebrand. To you they are obviously the same place. To a machine they are five different strings of letters, and unless something tells it otherwise, five different places. Entity resolution is the job of working out which mentions refer to the same real thing.

Entity resolution decides that several mentions are the same thing. Entity linking goes one step further: it connects a mention in text to a known record of that thing in a knowledge base. When an article says "the Azure" and a system attaches that phrase to a specific entry with a stable identity, an address, a set of facts and a history, that is entity linking. It is how a word on a page becomes a thing a machine knows about.

Standard retrieval augmented generation finds passages that look similar to a question and hands them to a language model. It works well for direct questions whose answer sits in one paragraph. It struggles when the answer requires connecting facts that live in different places. GraphRAG fixes that by retrieving from a knowledge graph instead of, or alongside, a pile of text chunks. The model gets facts and their connections, not just passages that happen to share words with the question.

Long before large language models, a group of researchers led by the inventor of the web set out to make web content readable by machines, not just by people. They called it the Semantic Web, and they built three standards that are still the backbone of serious knowledge graphs today. RDF is how facts are written. OWL is how the rules about those facts are defined. SPARQL is how you ask questions. Here is what each one does, without the jargon.

A web page says things in two layers. There is what a person reads: the headline, the photos, the paragraphs. And there can be a second layer, invisible to the visitor, that states the same facts in a form a machine can parse without guessing. Schema.org is the shared vocabulary for that second layer. JSON-LD is the most common way of writing it into a page. Together they are what search engines and AI systems mean when they talk about structured data.

Everything your business knows about itself exists in one of two forms. Either it is written for people, in sentences that need interpreting, or it is written for machines, in fields that need no interpreting at all. The second form is structured data. It is not a new idea. It is the difference between a paragraph and a form, and it is the single biggest factor in whether an AI system gets your facts right.

Strip any fact down to its simplest form and you get three parts: something, a relationship, and something else. The pool opens at seven. The hotel is in Pattaya. The restaurant serves Thai food. Each one is a subject, a predicate and an object. In data this three part unit is called a triple, and it is the atom from which knowledge graphs, the Semantic Web, and most structured descriptions of the world are built.

There is a style of business writing that works well on people and badly on machines. It flows. It sets a mood. It folds six facts into one warm paragraph and trusts the reader to pick them out. People do pick them out. AI systems, which read by cutting text into pieces and matching those pieces against questions, frequently do not. Granular facts, each stated on its own and clearly labelled, are what survive that process. Here is why.

A chatbot answers. An agent acts. That is the whole difference, and it changes everything about what the software can do for you and what it needs from the world around it. Both are built on the same language models, so the distinction is not about intelligence. It is about whether the model is allowed to do things, check the results, and keep going until a goal is met.

For the first few years of mainstream AI the product was an answer. You asked, it wrote. Agentic AI is the next phase: systems that take a goal and carry it out, making decisions along the way, using software tools, and only coming back to you when they are done or need a choice made. The word "agentic" simply means having agency, the ability to act. Here is what that shift involves and why it is arriving now.

Every AI assistant has the same limitation: it only knows what is in its training and what you type into the chat. To be useful with your data, your systems and your tools, it needs a way to reach them. Until recently every connection was custom, built once for one model and one tool, and rebuilt for the next. The Model Context Protocol, MCP, is an open standard that replaces all those custom connections with one shared way of plugging tools and data into any model. It is often described as the USB port for AI, and the comparison is fair.

An MCP server is the piece of software that lets an AI assistant reach your system. Building one is less about code than about decisions: what to expose, how to name it, what to protect. This guide walks through those decisions in plain terms, so that whether you write the server yourself or ask someone to, you know what a good one looks like.

One agent with a long list of tools and a complicated goal tends to get confused. It loses track of what it has done, uses the wrong tool, or tries to hold too much in its limited context. The fix is the same one organisations found long ago: split the work. A multi agent system is several agents, each with a narrower job, coordinating to complete a task that none of them could do well alone.

Strip an AI agent down to its parts and you find a language model surrounded by three things that turn it from a text generator into something that can get work done. Tools let it act on the world. Memory lets it keep track. Planning lets it decide what to do next. Here is what each part does, how they fit together, and what happens when one is missing.

For twenty years there was one game: search engine optimization, SEO, the craft of ranking on a results page so people click through to your site. Then answer boxes started appearing above the links, and then AI assistants started answering without showing links at all. Two new acronyms arrived to describe the new game. They overlap, they are often used loosely, and they describe genuinely different things. Here is what each one means and how they fit together.

When someone asks an AI assistant for a hotel near the old town with a rooftop pool, the assistant names two or three. It does not show a page of ten blue links. It chooses. Understanding how that choice is made is the first step to being chosen. The process is not mysterious, and it is not a popularity contest. It is a sequence of filters, each of which a business can pass or fail.

Search used to end with a list. Now it often ends with an answer. The box at the top of the results, the voice assistant's single reply, the AI summary above the links: all of these are answer engines, systems that give the person what they asked for without a click. Answer engine optimization, AEO, is the practice of making your content the answer those engines choose. It is a narrower, more precise discipline than traditional SEO, and in a world where the answer is often the only thing the person sees, it matters more every year.

A growing share of the questions that used to go to a search box now go to an AI assistant. People ask ChatGPT for hotel recommendations, Perplexity for the best restaurant near a landmark, Gemini for whether a place suits a family. These systems answer in prose, name a handful of businesses, and sometimes cite their sources. Being one of the names is the new visibility. Here is how these assistants find what they recommend, and what makes a business easy for them to choose.

Many businesses have noticed the same thing. Their search rankings held steady, their pages still appear, and yet fewer people arrive. The explanation is zero click search: the person asked, the search engine or AI assistant answered on the spot, and nobody clicked anything. The visit that used to happen now does not. Understanding this shift is the difference between chasing lost traffic and adapting to where attention actually went.

An FAQ page should be the easiest content on your site for an AI to use. Real questions, direct answers, one pair after another. Yet many FAQ pages contribute nothing to how assistants describe a business, and the owners never find out why. The reasons are technical, specific and fixable. Here are the most common ones, in the order they usually bite.

Everything an AI assistant says about your business comes from somewhere. Usually it comes from scattered sources: a page here, a listing there, a review, a directory entry, each written in its own words and each slightly different. The assistant assembles a picture from the fragments and hopes they agree. A knowledge graph replaces the fragments with a single, connected, machine readable description of what you are. It is the most direct way to be understood correctly by any system that reads you.

Every website has had a small text file at its root for decades: robots.txt, a note to search engine crawlers saying which parts of the site they may and may not visit. In 2024 a proposal appeared for a sibling file aimed at a different reader. llms.txt is a plain text file, also at the site root, written for large language models. Where robots.txt says where a crawler may go, llms.txt says what the site is about and where the most useful content lives, in a form a model can read in one pass.

For twenty five years a website was built for one visitor: a person with a screen, a mouse or a thumb, and the patience to look around. A second visitor has arrived. AI agents now visit websites on behalf of people, to find facts, compare options and complete tasks. They do not look around. They read what they can parse, call what they can reach, and leave when they cannot. Agent readiness is the question of whether your site works for this visitor. Most do not, for reasons that are easy to list and increasingly important to fix.