LLMs, Tokens, RAG, Agents and Skills: AI Terms Along One Clear Thread

The AI world has a fresh batch of buzzwords every week. LLM, token, prompt, RAG, MCP, agent, skill, harness: just reading the list is enough to give you a headache. Where do they fit, and what problem does each one solve? Let's follow a single thread.

Suppose you live in New York City and want a weekend in Boston, which you've never visited. This is a hypothetical trip for one adult, with a total budget of USD 2,000 for transport, lodging, meals and activities. You open a chat, ask a casual question, and get an answer almost immediately. At the heart of that exchange is a large language model, or LLM.

Your message is split into tokens: units defined by a tokenizer, not necessarily individual characters or whole words. Each token has a number called a token ID. The model calculates which token should come next, then builds its answer one token at a time.

In that exchange, your question is the prompt.

A casual question often gets a fairly shallow answer. Try being more specific: “Plan my New York-to-Boston weekend day by day for one adult. Keep transport, lodging, meals and activities within USD 2,000.” That gives the answer a clearer target. The practice of making those instructions work better is called prompt engineering.

A trip takes more than one message to plan. You set the total budget at USD 2,000, then add that you'd rather avoid tourist traps, and the AI adjusts. How does it remember what you said?

The application can include earlier messages when it sends the next request to the model. That's context. There is a limit to how much the model can take in at once; when a conversation grows, the application may trim it or compress it into a summary that keeps the important details. That summary can serve as memory, one way of carrying useful information forward rather than the only kind of memory a system can use.

By now, it's starting to look a little more like the “intelligence” you had in mind.

The conversation continues: “Look at the travel guides I saved and plan around those.” The model draws a blank. It doesn't know what you've saved. This is where RAG, retrieval-augmented generation, can help.

A retrieval system can search your private material. One approach is to split documents into chunks and store them in a knowledge base, retrieve the relevant pieces for your question, then send those pieces to the model as additional context. The model uses that material to answer. This pattern can support customer-service and question-answering tools, although retrieving relevant text doesn't guarantee a correct answer.

RAG helps the model answer with better information. That alone doesn't give it a way to do the job.

You say, “Look up trains from New York to Boston for those dates,” and the AI says, “You can open a ticketing app.” It can tell you what to do, but it hasn't looked up any trains. Function calling gives it a way to request help from external tools.

The program first tells the model which tools are available, then sends the conversation. When the model decides it needs a tool, it returns a structured request. The program uses that request to look up train services and sends the result back. Now the model can tell you which departures fit your trip.

There's an engineering problem, though. Connecting a new tool can mean writing another adapter, and that work doesn't necessarily carry over to a different application.

MCP provides a shared protocol for connecting applications to tools and other resources. An AI application that supports it can connect to compatible tool servers, though those tools still need an implementation and the appropriate access configuration.

It's easy to confuse function calling with MCP. They do different jobs: function calling lets the model express a tool request in a structured way; MCP standardizes the connection to the tools. One is about how to ask, the other about how to connect.

Tools are useful, but you're still directing each step. Could you just say, “Arrange this trip for me,” and hand over the rest?

That's the idea of an agent. Given a goal, an agent can plan steps, call tools and keep track of the results. Those are the pieces we've just covered, brought together around a language model in a system that can act on a task.

The distinction is between a model answering in a chat and a system equipped to do things. An agent doesn't necessarily learn continuously or get smarter with every job, and not every AI product is an agent. Agent-based products can take several forms: a chat window, a command-line tool, or an assistant that can operate your desktop. The amount they can do on their own varies.

That last kind attracts attention because it can take on more of the execution: work on your computer, run scheduled jobs, and communicate through a messaging app. With those capabilities available, it starts to feel more like an assistant doing a job for you.

Ideally, the agent would organize the trip itself. In practice, you still find yourself reminding it: plan by day, look for local guides, check train services.

A skill can help with that. Put your preferences and working rules in a reusable skill, and the agent can refer to it when a similar task comes up.

Isn't that just a prompt? Yes, partly. A one-off prompt is like a sticky note you have to write again; a skill is more like a reusable book, with a title and contents you can open when needed. Its structure supports progressive disclosure: discover what's available, then load the instructions and resources the task calls for. That can keep irrelevant material out of context, though it doesn't guarantee a lower total token bill.

By this point, an agent may have enough access to operate your computer. More ability also means more room to make a mess: you ask it to buy a ticket, and it buys the wrong one, payment and all.

That brings us to the harness. Think of the tack that keeps a runaway horse under control.

A harness is the engineering around the model: the runtime, context, tools, controls and feedback. It can supply relevant information, set boundaries around actions, and check results so the agent can respond to feedback and fix problems. Those are capabilities to build into the system, rather than a promise of perfect memory or automatic acceptance. The point is a working environment where the AI can be useful within limits. Nobody wants to wake up and find that an agent has formatted the computer.

Back where we started, all you wanted was a weekend away. As the questions and requirements grew, each layer supplied another part of what the system needed.

These terms aren't just jargon pulled out of thin air. Each names an answer to a practical problem along the way.