20 AI buzzwords, explained so you can actually use them
Sounding smart is easy. Knowing which term maps to which engineering decision is the part that pays. Here's the high-level breakdown of all twenty.
If you found this through the reel: yes, you can drop any of these twenty into a meeting and sound like you've shipped AI systems for years. That trick is free. The version that changes what you get paid for is knowing what each word is hiding, because every one of them is a compressed engineering decision, and the people who can decompress it in real time are the ones who get handed the interesting work. So that's the treatment below. Not definitions. What the term is, and what you'd do differently because you understand it.
Twenty terms today. One new one explained every week.
Get the next buzzword decompressed in your inbox, plus the decision it hides. Free, one email a week.
Retrieval: getting the right facts in front of the model
Seven of the twenty live in this section, which should tell you something. In most production AI work the model is the easy part. The hard part is handing it the right three paragraphs at the right moment.
1. RAG pipelines. Retrieval-augmented generation. Instead of hoping the model memorized your documents, you go find the relevant passages when the question arrives and paste them into the prompt. Every RAG system I've seen has the same four stages: ingest the documents, index them, retrieve the best matches for a query, generate an answer grounded in them. When answers come back wrong, one of those four stages is broken, and in my experience it is very rarely the model, even though the model is what everyone blames first.
2. Chunking strategy. Documents get split into pieces before indexing, and that split decides what retrieval can ever find. Cut too big and every chunk drags noise into the prompt. Cut too small and a chunk loses the sentence that gave it meaning. The strategies that work follow the document's own shape (headings, functions, paragraphs), overlap neighbors a little, and tag each piece with where it came from. A surprising number of "the model hallucinated" tickets are chunking bugs in a costume.
3. Semantic search. Search by meaning rather than exact words, so "refund policy" finds "money-back guarantee." Under the hood, text becomes an embedding, a long list of numbers where similar meanings end up close together. Great for fuzzy questions. Bad at exact identifiers: error codes, part numbers, invoice IDs. That's why serious systems run hybrid search, semantic plus plain keyword matching, and merge the results.
4. Vector database. A store built to hold embeddings and answer "which of these million vectors is nearest to this one" in milliseconds. Pinecone and Weaviate are dedicated products; pgvector bolts the same capability onto Postgres. My honest take: most teams don't need a new database for this. pgvector on the Postgres you already run will carry you a long way, and one fewer system is one fewer thing that can go stale.
5. Cosine similarity. The arithmetic behind "nearest." Take two vectors, measure the angle between them, and the cosine of that angle is your score: 1 means they point the same way, 0 means unrelated. The thing worth remembering is that it measures direction and ignores size, so a two-line chunk and a two-page chunk on the same topic can tie. Which is one more reason chunking matters.
6. Mismatched embedding. The bug that ruins retrieval quietly. The index was built with one embedding model, and queries are now being embedded with a different one, or a newer version of the same one. The two sets of vectors live in different mathematical spaces, similarity scores turn into noise, and retrieval keeps returning confident garbage without throwing a single error. Treat the embedding model as part of the index's schema. Change one, rebuild the other. Every time.
7. Stale indexes. The documents changed. The index didn't. Now the bot answers from last quarter's pricing page with complete confidence. I've watched this happen to a support assistant that was, technically, working perfectly. Freshness is a pipeline question: when does re-indexing run, what triggers it, and how would anyone notice if it silently stopped? Before you ask a RAG system how accurate it is, ask how old an answer is allowed to be.
Tools and agents: letting the model act
8. Tool calling. The model doesn't only produce text. It can emit a structured request, something like "call get_invoice with id 4471", your code runs it, and the result goes back into the conversation. That one mechanism sits underneath every agent product you've heard of. The design work is in the tools themselves. A handful of well-described tools beats one big vague tool, and each of them needs a failure message the model can reason about, because "500 Internal Server Error" teaches it nothing.
9. MCP. Model Context Protocol, an open standard Anthropic published for how AI applications connect to tools and data. Instead of hand-writing an integration for every model-and-tool pairing, a tool exposes one MCP server and any client that speaks MCP can use it. People keep reaching for the USB-C analogy, and I've stopped fighting it because it's accurate. If you're building integrations, build them as MCP servers. They'll outlive whatever model you're using this quarter.
10. A2A. Agent2Agent, the protocol Google introduced for agents talking to one another: an agent publishes a card describing what it can do, another agent discovers it, hands over a task, and collects the result. The simplest way to keep the two protocols straight is that MCP connects an agent to tools and A2A connects agents to agents. You'll want A2A when work crosses team or vendor boundaries. Inside one application you almost certainly won't.
11. Multi-agent orchestration. Splitting a job across several specialized agents, say a planner, a builder, and a reviewer, with something coordinating the hand-offs. It's real, it's useful for parallel work, and it's also expensive and miserable to debug. Start with one agent and good tools. Add agents only when a single context window provably can't hold the job. Most "we need multi-agent" conversations I sit in on are really "our one agent has bad tools" conversations.
12. Agent harness. Everything wrapped around the model that makes it an agent: the loop that calls tools and feeds results back, permission checks, retries, context management, stop conditions, logging. The model is the engine. The harness is the rest of the car. Give two teams the same model and different harnesses and you'll get wildly different products, which is why this is where most of the actual engineering, and most of the hiring, has moved.
Context and cost: what the model sees, and what it costs you
13. Prompt caching. Models re-read the entire prompt on every call, and you pay for every token of it. Caching lets the provider reuse the already-processed prefix (your system prompt, the big reference document, the tool definitions) across requests, so repeated tokens cost a fraction of the price and come back faster. It forces one layout rule on your prompts: stable content first, changing content last. Otherwise the cache never hits.
14. Token optimization. Tokens are the unit of both billing and latency, so this is performance engineering wearing a new badge. Send less. Trim boilerplate. Retrieve three chunks instead of thirty. Cache the stable parts. Route the simple requests to a smaller model that's good enough. Then measure tokens per request the way you'd measure query time per endpoint. If nobody on the team can quote that number, nobody is optimizing it.
15. Context compaction. Long sessions fill the context window. Compaction summarizes the older turns into a shorter recap so the conversation can continue without losing the thread. It's lossy on purpose. The skill is choosing what survives the squeeze: decisions made, constraints stated, questions still open. The chatter can go. If you want to judge an agent harness quickly, watch how the agent behaves in the first few turns after a compaction.
16. Memory engineering. Deciding what persists between sessions and how: files the agent reads on startup, a searchable store of things it has learned, running summaries about the user or the project. Memory is curated context with a write policy, meaning explicit rules about what gets saved, updated, and thrown away. Treat it as a bigger context window and you'll end up worse off than with no memory at all, because the agent trusts what it remembers completely.
17. Multimodal input. Giving the model images, audio, PDFs, or screenshots along with text. This sounds more exotic than it is, and it's more useful than it sounds. A screenshot of the bug usually beats three paragraphs describing it. A photo of the whiteboard beats retyping it. Learn what each model accepts natively versus what you have to preprocess, and stop converting things to text that never started as text.
Trust: knowing whether any of it works
18. Evals. Tests for model behavior: a set of inputs with expected outcomes, scored automatically or against a rubric. They are how you find out whether a prompt change or a model upgrade helped, as opposed to feeling like it helped on the three examples you tried by hand. A team without evals ships on vibes and regresses without noticing. A team with them can swap models in an afternoon.
19. Observability. Logging every step of a model-powered request: the prompt that went out, the chunks that came back, the tools that ran, tokens, latency, the final answer. Without it, "the AI said something weird" is a ghost story nobody can reproduce. With it, the weirdness usually has a boring cause you can point at in the trace. Usually in retrieval, if you want to bet.
20. Model guardrails. Checks on what goes into the model and what comes out: catching prompt injection, refusing requests that are off policy, validating that a response matches the expected schema before it touches a database. There are two layers here and only one of them counts. What you tell the model to do is a preference. What your code enforces no matter what the model says is a guarantee. Build the guarantee first.
Turning the buzz into leverage
The test for whether a term has turned into knowledge is simple. Can you name the failure it prevents, and the question it makes you ask? Here's what that looks like on a normal Monday.
- Someone in a planning meeting says "we'll add RAG." Ask which of the four stages they expect to be the hard one. The answer tells you whether they've built one before.
- A pull request swaps the embedding model. Look for the index rebuild in the same change. If it isn't there, you just caught a mismatched-embedding bug before it shipped.
- An interviewer asks about agents. Talk about the harness, not the model. Everyone can name the model. Almost nobody can explain what happens after a tool call fails.
Twenty words. Twenty decisions hiding inside them. I don't think the engineers getting ahead right now know more terms than anyone else. They've just learned to hear a buzzword and reach straight for the question underneath it.
Want a coach in your corner?
Book a 1:1 call — we'll map your next step and pressure-test your plan. Group courses coming soon.
Get one like it in your inbox each week
Practical guides and roadmaps for the AI shift — free, no hype, written by the same people.
