Before you learn AI security, learn to speak AI
From here, it starts a GenAI security learning series. This is the first chapter in this series as Edition 001: GenAI Fundamentals — Vocabulary Overview
ToC of Edition — 001 in GenAI Security Series
- Why start with words, not threats
- Evolution of GenAI timeline
- The model era: transformer → foundation model → GPT
- Frontier AI: what “frontier” actually means
- RAG & vector retrieval: grounding the model in your data
- From one call to a loop: what “agentic” means
- Agent memory: giving the loop a past
- Agent protocols: MCP & A2A — how agents talk to tools and each other
- Multi-agent systems: when one loop isn’t enough
- The agentic harness: the system around the loop
- Agenting Engineering: The new discipline
1. Why Start With Words, Not Threats
You cannot threat-model, secure, or even sensibly use something you can’t name. Most people entering AI (or AI security) skip straight to “how do I secure an LLM app” or “how do I build an agent” and stall immediately, because half the sentences around them use terms nobody defined: the model is a frontier model, grounded with RAG, running an agentic loop with memory, talking to tools over MCP, coordinating with other agents over A2A, inside a well-built harness. That sentence is precise and useful once you know every word in it — and mostly noise if you don’t.
This overview walks the terms in the order the industry actually built them, from “what is the model” to “what is the practice of engineering systems around the model” — covering the full spine an AI engineer or AI security engineer needs: the model itself, how it’s grounded in real data, how it becomes an agent, how agents remember and talk to tools and each other, and what it takes to engineer and run all of that as a system. Each term gets one clear definition, one worked example, and a pointer to where this library goes deeper.
2. Evolution of GenAI timeline
Evolution of the vocabulary — each term sits on top of the one before it
3. The model era: transformer → foundation model → GPT
Transformer — the neural network architecture (Vaswani et al., “Attention Is All You Need,” 2017) built around attention: a mechanism that lets the model weigh how relevant every other word in a passage is to the word it’s currently processing, in parallel rather than one word at a time. That parallelism is why transformers could be trained at the scale that made modern AI possible. Attention is the mechanism; GPT, Claude, and Gemini are all applications of it.
Pretraining — feeding a transformer a very large amount of text (or code, or images) and having it learn to predict the next token, over and over, until it has absorbed statistical patterns of language, facts, and reasoning “shapes.” A one-time, extremely expensive step done by a model provider — not something that happens every time you use the model.
Foundation model — the result of pretraining: a large, general-purpose model broad enough to be adapted, via fine-tuning or prompting, to many tasks. Everything else — chatbots, coding assistants, agents — is built on top of one.
GPT (Generative Pre-trained Transformer) — OpenAI’s name for its model line, and the term that leaked into everyday language as shorthand for “a large language model.” Every GPT is a pretrained transformer; not every transformer is a GPT (BERT, for instance, is a transformer that isn’t generative in the same way). When people say “an LLM” today, they usually mean a GPT-style, decoder-only transformer.
One distinction worth having early: a base model — the raw output of pretraining, good at continuing text, bad at following instructions — is not the same as an instruct/chat model: the same base model, further trained with techniques like RLHF (reinforcement learning from human feedback) to follow instructions and hold a conversation. ChatGPT, Claude, and Gemini are all instruct/chat models sitting on top of a base foundation model.
Feel the difference without opening a lab. Type “The capital of France is” at a raw base model and it just continues the sentence — “Paris, a city known for…” — because it was only ever trained to predict the next word. Type the same fragment at an instruct model like ChatGPT or Claude and it answers the implied question: “Paris.” Ask either one to “write a Python function to reverse a string”: a base model might drift into unrelated prose about string reversal, while a chat model returns a working def reverse_string(s): return s[::-1], because it was specifically trained to recognize and comply with instructions. This is why every consumer product you’ve used is a chat model, never a bare base model — base models are a research/fine-tuning starting point, not something end users interact with directly.
4. Frontier AI: what “frontier” actually means
Frontier model / frontier AI — the small set of models sitting at the current edge of general capability: the largest, most capable, most expensive-to-train models from the leading labs (GPT-4/5-class, Claude Opus/Sonnet-class, Gemini Ultra/Pro-class), as opposed to smaller, narrower, or open-weight models trained for a specific job. “Frontier” is a relative term describing a position on a capability curve that keeps moving — what was frontier in 2023 (GPT-4) is a mid-tier model people now run cheaply.
The word matters for two practical reasons. First, a capability vs. blast-radius trade-off: frontier models give you the broadest reasoning and tool-use ability but are the hardest to fully govern and the most expensive per call, while smaller/narrower models shrink the attack surface but push more of the safety burden onto you. Second, it’s a design decision, not a leaderboard: choosing “the frontier model” for every task is often overkill — the smart default is usually the smallest model that clears the capability bar for the job.
Take a support ticket that needs to be classified as billing, technical, or other. A frontier model handles it easily — but you’re paying frontier prices and sending potentially sensitive ticket text to a third-party API for a task that never needed frontier reasoning. A small, fine-tuned classifier does the same job for a fraction of the cost and latency, and if it runs on your own infrastructure, the ticket text never leaves your network. The frontier model would have worked — it just wasn’t the right tool for this job.
5. RAG & vector retrieval: grounding the model in your data
Everything so far describes a model’s frozen knowledge — whatever it absorbed during pretraining, locked in place until the next training run. Two hard limits follow: it knows nothing past its training cutoff, and nothing about your private data. RAG (Retrieval-Augmented Generation) is the standard fix — instead of retraining the model, you fetch the relevant slice of your own data at query time and hand it to the model as part of the prompt, so it answers from that text rather than from memory.
The retrieval side runs on two more terms you’ll see constantly. An embedding is a piece of text converted into a list of numbers — a vector — that represents its meaning, positioned so similar meanings sit near each other in that numerical space. A vector database is a data store built to hold millions of these embeddings and answer “what’s semantically nearest to this query?” almost instantly, instead of doing a keyword match — the retrieval engine underneath RAG, semantic search, and recommendation systems alike.
A close cousin worth knowing by name: CAG (Cache-Augmented Generation) — instead of retrieving at query time, you preload your entire (smaller, stable) knowledge base into the model’s context once and cache it, skipping retrieval entirely. RAG scales to huge, changing knowledge; CAG is simpler and faster when your knowledge base is small and doesn’t change often. Most production systems end up using both — CAG for the small, hot, stable core; RAG for the large, changing long tail.
Picture an e-commerce returns-policy assistant. Without RAG, you’d paste your entire, ever-changing returns policy into every prompt — expensive, and stale the moment policy changes. With RAG, your policy documents are chunked, converted to embeddings, and stored in a vector database ahead of time. When a customer asks “can I return a phone I bought 20 days ago?”, the system embeds the question, searches for the nearest matching policy chunks, and inserts just that chunk into the prompt before the model answers. The model never “knew” your policy — it was handed the right paragraph, on demand, every time.
6. From one call to a loop: what “agentic” means
A single call to a frontier model — prompt in, text out — is inference, not agency. The model is stateless: it doesn’t remember the call before, and it can’t act on the world. Say it asks for a tool to be called — it still can’t call it. Something has to sit outside the model, read that request, actually run the tool, and hand the result back.
That’s the move from “LLM” to agent: a system that wraps a model in a repeating loop — Perceive → Reason → Act → Observe — so the model’s output on one turn becomes the input for deciding the next action, across many turns, without a human manually re-prompting it each time. This loop is often called ReAct (Reason + Act) in the literature, and “the agentic loop” colloquially. It’s the single biggest shift in the industry timeline: passive text generation → active real-world action. An LLM that says something wrong is embarrassing; an agent that does something wrong — sends an email, deletes a file, executes a trade — is a different category of consequence entirely.
Ask a plain LLM to “book me a flight to Delhi next Friday under ₹8,000” and it returns a paragraph of text describing flights it thinks might exist — possibly hallucinated — and stops. It cannot check a real fare or book anything. An agent running the loop instead reasons that it needs today’s date and real fare data, calls a search_flights() tool, observes the actual results, reasons again to pick the cheapest option under budget, calls book_flight(), and reports back a real confirmation number. Six turns, one goal, zero re-prompting from you in between. That loop — not the model getting “smarter” — is what turned a text generator into something that could actually get the job done. It’s also exactly why the booking step needs a security boundary around it: a plain LLM call can only embarrass you; an agent’s action can spend real money.
7. Agent memory: giving the loop a past
The loop above has a hole in it: as soon as the conversation ends, everything is gone. The model is stateless — every session starts from a blank slate, the same way you’d feel re-briefing a manager for an hour only to have them ask “wait, what are you working on again?” a week later. Memory is the engineering layer that fixes this: it lets an agent retain and recall information across turns, sessions, and time, instead of relying purely on what fits in the current context window.
The clearest way to organize agent memory is a human-memory analogy, popularized by the CoALA paper (Sumers, Yao, Narasimhan & Griffiths, Princeton, 2023). Sensory memory is the raw input buffer — fleeting, gone almost immediately. Short-term / working memory is the context window — everything the model can see right now. Long-term memory splits three ways: episodic (what happened — this customer called last Tuesday about a refund), semantic (facts and knowledge — our return window is 30 days for apparel), and procedural (how to act — the steps for processing a refund correctly). And collective / organizational memory is shared across agents or sessions, not just within one.
A shopping assistant with no long-term memory makes you re-explain, every time you open the chat, that you’re looking for running shoes, size 9, under ₹4,000 — it has no idea it’s “you” at all. One with long-term memory recalls that you asked about running shoes last week, knows your shoe size from your profile, and follows the store’s standard “recommend three options, always mention return policy” flow — without you repeating any of it.
8. Agent protocols: MCP & A2A — how agents talk to tools and each other
Once you have agents that call tools and remember things, a new problem shows up fast: every agent framework had its own bespoke way of describing a “tool,” and every tool needed a custom integration per agent. With M agents and N tools, that’s M × N one-off connectors — the same trap hardware was in before USB, and enterprise software was in before HTTP. The fix is the same shape every time: agree on a protocol once, so M × N collapses to M + N.
MCP (Model Context Protocol) is often described as “USB-C for AI”: a standard way for an agent to discover and call tools, read files, or query data sources, regardless of which agent framework or tool provider is on the other end. Instead of writing a custom integration to your internal order-lookup API, you stand up one MCP server for it, and any MCP-compatible agent can use it. A2A (Agent-to-Agent) is a protocol for agents to discover each other’s capabilities and collaborate directly, rather than one agent calling another as if it were just another tool — the layer that makes multi-agent collaboration interoperable across vendors instead of hand-wired.
Before MCP, your coding agent, your support agent, and your ops agent each need a custom-written connector to your order-lookup API — three integrations, three sets of bugs, three things to update whenever the API changes. After MCP, you build one MCP server that exposes look_up_order(order_id). All three agents — and anything your company builds next — connect to it the same standard way, at zero additional integration cost.
9. Multi-agent systems: when one loop isn’t enough
A single agentic loop works well for a bounded task. Complex work often gets split across multiple specialized agents, each running its own loop, coordinating via protocols like A2A or a controlling “supervisor” agent — mirroring how a human team divides labor, since nobody expects one person to plan the project, write every line of code, and review their own work with a fresh eye.
Take a coding task handled by a team of agents instead of one: a planner agent breaks “add a returns feature to the checkout flow” into subtasks, a coder agent implements each subtask, a reviewer agent — a separate loop, deliberately not the same one that wrote the code — checks the diff for bugs before it merges, and the planner agent collects the results and reports back to you. Four agents, four loops, one shared goal, coordinated rather than run by a single do-everything agent. The upside is specialization and independent checks — a reviewer that didn’t write the code catches things a single self-reviewing agent tends to miss. The trade-off is a new layer of coordination overhead and new failure modes, like an instruction injected into one agent propagating to its peers, that simply don’t exist in a single-agent system.
10. The agentic harness: the system around the loop
If the model is the brain, something still has to be the body: assemble the prompt, call the model, parse its output, execute the tool it asked for, capture the result, manage memory across turns, enforce what it’s allowed to touch, and decide when the task is actually done. That entire piece of engineered infrastructure — everything that is not the model itself — is the agentic harness.
The industry crystallized this term in 2025–2026 for something practitioners were already building under other names: agent runtime, scaffolding, executor. The core insight worth carrying forward: Agent = Model + Harness, and two agents built on the identical model can behave completely differently depending on the harness wrapped around it. Most of what looks like “the model forgot” or “the model looped forever” is actually a harness problem — context management, stop conditions, verification — not a model problem.
Claude Code and Cursor can both run on the exact same underlying Claude model. Yet one lives in your terminal and edits files across a whole repo with a memory of your project conventions; the other lives in your IDE with a different tool set, different context assembly, and different guardrails. Swap the harness and the “same AI” becomes a different product with a different blast radius — the model didn’t change at all. That gap is the harness.
11. Agentic engineering: the new discipline
The practice of engineering what surrounds the model has evolved through three recognizable phases, and the label for the practitioner’s skill has shifted with it.
Prompt engineering is crafting the single instruction you send the model for a better one-shot output — the unit of work is a string.
Context engineering is deliberately curating everything that ends up in the model’s context window across a session — system prompt, retrieved documents from RAG, tool outputs, prior turns, agent memory — so the model reasons well over many steps, not just one; the unit of work is the context window.
Agentic engineering is designing and building the harness itself: the loop, the tools, the memory, the protocols connecting agents to tools and each other, the permission boundaries, the verification step, the orchestration across sub-agents; the unit of work is the system the model runs inside.
Each phase didn’t replace the last — it wraps it. Take the goal “help our support team answer billing questions correctly.”
Prompt engineering writes one good system prompt: “You are a billing assistant. Answer only from company policy. If unsure, say so.” Better answers, one shot at a time — but it knows nothing about this customer’s account.
Context engineering assembles the customer’s account history, the relevant policy page, and recent conversation turns into every call, so the model reasons over this specific case.
Agentic engineering gives it a look_up_account() tool, a check_refund_eligibility() tool, permission to issue refunds only under ₹500 without approval, and a verification step that confirms the refund was actually issued before telling the customer it’s done. Same underlying model at every stage — what changed is how much of the system around it you engineered.
This is also why “AI security” for agentic systems increasingly looks like systems security — identity, authorization, sandboxing, blast radius — rather than “prompt safety.”
Every term, in order
As a quick recap, here’s the spine in one pass:
- Transformer — the attention-based neural architecture behind modern AI.
- Pretraining — the one-time process of training a transformer on massive text/code corpora.
- Foundation model — the general-purpose model that results from pretraining.
- GPT / LLM — a generative, pretrained transformer; the common shorthand for “large language model.”
- Base vs. instruct/chat model — raw pretrained model vs. the same model fine-tuned (often via RLHF) to follow instructions.
- Frontier AI / frontier model — the current edge of general model capability; a moving relative tier, not a fixed one.
- Embedding — text converted into a meaning-vector, used for retrieval and search.
- Vector database — a store built to find the nearest-meaning embeddings to a query, fast.
- RAG — retrieve relevant data at query time and hand it to the model as context.
- CAG — preload and cache a stable knowledge base into context once, instead of retrieving.
- Inference — a single stateless prompt-in/text-out call to a model.
- Agent — a system that wraps a model in a repeating decide-and-act loop.
- Agentic loop / ReAct — the Perceive → Reason → Act → Observe cycle that turns inference into autonomy.
- Agent memory (episodic/semantic/procedural) — the engineering layer that lets an agent recall things across turns and sessions.
- MCP — the standard protocol for an agent to discover and call tools/data sources.
- A2A — the standard protocol for agents to discover and collaborate with each other.
- Multi-agent system — multiple specialized agents, each running a loop, coordinating on one goal.
- Agentic harness — the engineered infrastructure (everything that isn’t the model) that runs the loop.
- Prompt / context / agentic engineering — the three widening phases of the practitioner’s craft: string → context window → whole system.
What’s next: LLM — Zero to Hero in next edition
This overview deliberately stopped at naming things. The companion piece, “LLM: Zero to Hero,” goes one level deeper into the model layer specifically: what an LLM actually is beyond “a transformer” — parameters, weights, layers; how it works mechanically — tokenization, embeddings, the attention forward pass, decoding; the internals that matter in practice — context windows, KV cache, quantization, temperature/sampling, and why each shows up later as an attack surface or design constraint; and what you can actually build with one — completion, chat, function/tool calling, structured output, embeddings for search, and fine-tuning vs. prompting vs. RAG as three different ways to specialize the same base model.
That lesson builds directly on the vocabulary above — you’ll be reading “context window,” “base model,” and “inference” as things you already know, not things being defined for the first time.
Sources & further reading
- Vaswani et al., “Attention Is All You Need,” NeurIPS 2017 — the transformer paper.
- Sumers, Yao, Narasimhan & Griffiths, “Cognitive Architectures for Language Agents” (CoALA), Princeton, 2023 — the memory taxonomy.
- Awesome GenAI Security
- GenAI Security Study Plan
