It is Wednesday standup at a Lagos fintech. The AI-team lead says the sentence that ends the meeting for the four engineers listening: we'll add an orchestrator agent that handles handoffs through MCP with a policy layer in front. Three of the four have never used those terms in a sentence they meant. The fourth has used them, but with three different meanings than the other three assumed. Nobody asks for a definition. The stand-up ends. The tickets get assigned. The agent gets built.
Most teams are building agents faster than they are building the vocabulary for them. This series is the working vocabulary — twenty terms across three pieces, grounded in when to use each, what it costs, and what breaks when it is missing. It is not exhaustive. A bank needs terms for payment orchestration and reconciliation that this list does not cover. A clinical-decision-support team needs terms for eval-against-a-clinical-corpus. A trading desk needs terms for latency budgets that this vocabulary would treat as one word. The twenty are the common vocabulary. The vertical vocabulary extends it.
Part 1 walks through seven foundations — the loop that defines the agent shape, and the four terms that decide what the agent knows when it thinks. Part 2 covers coordination — how agents reach the world and each other. Part 3 covers governance and running things in production.
Key takeaways
- An agent is a loop, not a call. Perceive, plan, act, observe — that shape is what separates an agent from a prompt, and the rest of the vocabulary is scaffolding around it.
- Tool use is where an agent stops describing and starts doing. Each tool is a capability and a risk surface at the same time; least-privilege scoping applies unchanged.
- What the agent knows at each step is decided by four terms working together — memory holds it, RAG fetches it, grounding anchors it, context engineering arranges it. Underinvest in the arrangement, and the model behaves badly regardless of how good the retrieval is.
- Context engineering is the load-bearing craft nobody teaches in the courses. It is what decides whether the same LLM produces a competent agent or a chaotic one.
- The twenty are the common vocabulary. Verticals — banking, healthcare, trading — extend it with their own load-bearing terms this list does not cover.
The Loop
An agent is a loop that perceives, plans, acts, and observes — then loops back with what it just learned. Everything else on this list is scaffolding around that shape. Three terms cover the loop itself.
Agent Loop
The perceive-plan-act-observe cycle that defines the agent shape.
- Reach for it whenever the work requires more than one LLM call to reach a goal. The loop is what turns a prompt into an agent.
- Trade-offs — every iteration is latency and tokens. A five-turn loop against a $5-per-million-token model at 4,000 tokens per turn is around $0.10 per user request before you add tools. The loop also has to know when to stop, or it doesn't.
- Cost and effort — the loop itself is a
whilewith a stopping condition and is cheap to build. Tuning it — when to stop, what to do on failure, how to cap runaway cost — is where the real work sits, and it is where most demo-to-production journeys break.
Tool Use
The agent's ability to call functions and take real actions in the world — search a database, hit an HTTP endpoint, run code, send an email.
- Reach for it the moment you need the agent to do rather than describe. A read-only agent that only summarises is a summariser, not an agent.
- Trade-offs — each tool is another surface for hallucination, prompt injection, and permission escalation. The least-privilege architecture applies unchanged; giving an agent broad tools is giving an attacker broad tools.
- Cost and effort — tool definitions are half a day per tool. Tool safety — scoping the credentials, defining the allow-list, testing what happens when the agent calls the wrong tool with the wrong arguments — is a quarter of the project.
Agentic Pipeline
The structured end-to-end flow from user input through reasoning and tool calls to output. The pipeline is a mental model — it names the stages the agent moves through.
- Reach for it when a single loop is no longer the right abstraction and you need to distinguish stages that have different characteristics (retrieval, planning, execution, verification, response).
- Trade-offs — over-formalising the pipeline early rigidifies the design before you know which stages matter. Under-formalising leaves you with an untraceable ball of prompts nobody can debug.
- Cost and effort — the pipeline is documentation before it is code. The code should follow the stages that survive contact with the first three real users, not the stages that felt right on the whiteboard.
What the Agent Knows
The agent's answer is only as good as what it is looking at when it thinks. Four terms cover the discipline of deciding what that is, and one of them — the last — is the one nobody teaches.
Memory
Short-term memory holds the current conversation. Long-term memory holds what the agent remembers about the user, the domain, the last session.
- Reach for it when the agent needs to be more than a stateless chatbot. Customer support with ongoing case history. Ongoing research where the previous session's findings matter. Personal assistants of any kind.
- Trade-offs — long-term memory is a data-protection surface (NDPA, GDPR, retention discipline, deletion requests). Short-term memory hits the context-window ceiling faster than teams expect; a 200,000-token window is not infinite when tool descriptions and prior turns compound.
- Cost and effort — short-term is free (it is the context you already have). Long-term is a schema decision, a retrieval strategy, an eviction policy, and a legal review. Expect a two-week discovery to get the memory model right for a regulated business.
RAG (Retrieval-Augmented Generation)
The agent retrieves relevant external knowledge before generating an answer.
- Reach for it when the model's training data is stale, wrong, or absent — internal documentation, product manuals, customer records, regulatory text.
- Trade-offs — RAG is only as good as the retrieval. The retrieval is only as good as the chunking, the embedding, and the classification discipline underneath. Bad RAG confidently returns wrong answers with citations that make them look right; see DSPM meets RAG.
- Cost and effort — a naive RAG is a weekend project. A production RAG with hybrid search, reranking, evals, and a corpus-hygiene discipline is a quarter of one engineer's time, then ongoing.
Grounding
Anchoring the agent's output in a trusted data source so the answer cites what it stands on.
- Reach for it whenever the output has consequences — legal, medical, financial, regulatory, contractual. Grounded output is defensible in an audit; ungrounded output is not.
- Trade-offs — grounding reduces hallucination but does not eliminate it. The agent can still misinterpret the source, cite the wrong passage, or invent a plausible-looking quote. Grounding is a floor, not a ceiling.
- Cost and effort — citation-level grounding is straightforward once the retrieval works. Source-selection grounding — deciding whether the source itself is trustworthy for this question — is the real work and is where the domain expertise has to sit.
Context Engineering
Designing what the agent actually sees at each step. System prompt, tool descriptions, retrieved documents, prior turns, structured examples, output format.
- Reach for it on every agent, always. This is not optional.
- Trade-offs — this is the load-bearing craft that decides whether the same LLM produces a competent agent or a chaotic one, and it is the least-taught skill in the field. Prompt tweaks give diminishing returns; context redesigns can transform an agent's behaviour.
- Cost and effort — high engineering hours, low direct spend. The best engineers we work with spend more time on context design than on prompts. When a client asks us why their agent is unreliable, this is the answer three times out of four.
If the vocabulary above is behind the deployment at your team's next standup, which of the seven terms is the one nobody is currently using with the same meaning as the person sitting next to them?
FAQs
Is this list exhaustive?
No. The twenty across the series are the common vocabulary — the terms that show up across most agent projects regardless of industry. Banking adds payment-orchestration and reconciliation terms this list does not cover. Healthcare adds clinical-decision-support terms. Trading adds latency-budget terms this vocabulary would treat as one word. Treat the twenty as the baseline; expect your vertical to extend it with three-to-seven load-bearing terms of its own.
How much of "context engineering" is prompt engineering under a new name?
Some, but not most. Prompt engineering is what you write in the system prompt. Context engineering is deciding what documents are retrieved, what tool descriptions surface, what turns of history the agent sees, what output format constrains its response, what examples anchor its behaviour. The prompt is one input into the context; the context is the load-bearing decision.
When does an "agentic pipeline" abstraction start paying off, and when does it just add ceremony?
It pays off once the loop has more than one distinct stage that needs its own eval, its own prompt, or its own error-handling policy. It adds ceremony when the "pipeline" is a single agent doing what a single agent could always do, dressed up with stage names. Rule of thumb — if the stages do not have different failure modes, they are one stage.
Why is grounding not part of RAG?
RAG is a retrieval technique. Grounding is a discipline about what the agent's output is anchored in. RAG is one way to feed grounding, but not the only one — a well-designed system prompt with a canonical reference document is also grounding, and an agent that quotes its own memory can be grounded if the memory is trustworthy. Treat grounding as the goal and RAG as one tactic.
Companion content
- Coordinating the Agent — The Working Vocabulary, Part 2 — Part 2 covers MCP, A2A, Orchestrator, Multi-Agent System, Handoffs, Agent Protocols
- Governing the Agent — The Working Vocabulary, Part 3 — Part 3 covers Guardrails, Policy Layer, Sandboxing, Human-in-the-Loop, Observability, Evaluations, Agent Identity
- DSPM Meets RAG: Data Classification in the Knowledge Base Era — the classification discipline under RAG
- Instructions Are Not a Boundary: Least-Privilege for AI-Assisted Code Review — the least-privilege pattern that applies to tool use
How to engage
If your team's vocabulary is behind the deployment and you want a vendor-neutral read on which primitives to lean on for your specific stack, talk to us at creativeminds.dev/contact. We ship agents in production and the diagnostic maps the vocabulary against your existing tooling.