Glossary

Generated from the topic definitions. Each entry links to the topic it belongs to.

"Trust but verify" for agents Verifying outputs: When an agent acts rather than answers, verification moves from reading text to checking effects: what files changed, what was sent, what was deleted. Let the agent proceed on low-stakes steps, then inspect the result against what you asked for, and require a pause before any step that is hard to reverse. Trust is granted per action, not per tool.
Agent loop What an agent is: The cycle an agent runs: observe the current state, think about what to do, act through a tool, observe the result, repeat. The loop ends when the model says it is done, a step limit is hit or a human intervenes. Everything an agent does, good or bad, is some number of turns of this loop.
Agent SDK The agent loop and harness: A library that provides the loop, tool plumbing, context management, permission checks and often built-in tools, so a developer supplies instructions and tools and gets an agent. An SDK saves rebuilding solved parts and encodes hard-won defaults. The cost is that its choices about context, retries and stopping are now yours to understand rather than to write.
Agent-specific security risks Guardrails and production: Risks that appear when a model can act: prompt injection through content the agent reads, exfiltration through tools that send data outward, over-permissioned tools that turn a wrong decision into real damage, and confused-deputy situations where the agent spends its own authority for whoever wrote the text it acts on. They are mitigated by limiting capability and reviewing actions, not by better prompts.
Agentic RAG loop Agentic retrieval and memory: Retrieval driven by the agent: it forms a query, reads what comes back, judges whether it answers the question, and reformulates, searches elsewhere or drills into a document before answering. Compared with one fixed search per question, it handles vague queries and multi-hop questions much better, at the cost of more calls and a loop that needs a bound.
AGENTS.md / CLAUDE.md Project instructions: The instruction file coding agents load automatically from a repository root. Several tools read a shared name and others read their own; a symlink lets one file serve both. It holds what the agent must know every session: commands, conventions, boundaries. It is not documentation for people and is read on every turn, so every line costs context.
Allowlists Hooks, permissions, settings: Explicit lists of tools, commands or paths the agent may use without a prompt, and denylists it may never use. They turn a stream of approval prompts into a one-off decision and make that decision reviewable in configuration. Keep them narrow and specific; a broad wildcard grants much more than the command that prompted it.
Attribution Agents in a team: Recording that an agent contributed to a change, typically as a trailer in the commit message and a note in the pull request, alongside the human who directed and verified the work. Attribution lets reviewers calibrate attention, keeps history honest, and separates what a person certifies from what a tool produced. The human remains the author of record.
Auto-memory Memory and session context: Notes an agent writes for itself during a session and reads back in later ones: preferences it learned, facts about the project, decisions made. It reduces re-explaining but is unreviewed by default, so it can carry a wrong assumption forward for weeks. Read what the agent remembers now and then, and correct or delete entries that have gone stale.
Automation complacency Recognizing failure: The habit of waving through a tool's output because it has been right many times before. Attention decays fastest when the tool is good, so the rare failure passes unchecked. It is a known effect from aviation and medicine, not a personal weakness, and is countered by process: designed checks, sampling and rotating who reviews.
Avoiding context rot Context engineering for code: Keeping the session's context lean so the agent keeps following instructions and remembering the goal: one task per session, summaries instead of raw logs, fresh sessions for new work, and no pasting of whole files it can read itself. When answers drift or earlier rules get ignored, the context is full; compact or restart rather than push on.
Bias Recognizing failure: Systematic slant in a model's output inherited from its training data and its tuning: which names it assumes are senior, which dialect it calls professional, which candidates it ranks higher for the same record. Bias is hard to see in a single answer and shows up in patterns across many. Anything a model does that affects people should be sampled and compared across groups.
Blast radius Agent risk: Everything an agent's action can reach and change: the files it can write, the accounts it can act as, the systems its credentials open, the people its messages reach. Blast radius is decided by what the agent is connected to, not by what you asked it to do. Sizing it before a task is the first step in deciding how much autonomy to allow.
Bounded self-checking loops Verifying agent work: Giving the agent a check it can run itself, such as a test suite, a linter or a build, and letting it iterate until the check passes, with a limit on attempts and a rule for what it may change. The bound matters: an unbounded loop will eventually satisfy the check by weakening it. The human verifies the check is still honest at the end.
Chat vs agent vs automation Choosing models and tools: Three ways to apply a model. Chat: you steer every turn, best for thinking and one-off drafts. Agent: you brief it and it works through steps with tools, checking in as agreed, best for bounded tasks with clear done-criteria. Automation: it runs unattended on a trigger, best for repetitive, low-stakes, well-tested tasks. Autonomy rises across the three, so the checks must rise too.
Checking habits Verifying outputs: Small routines that catch model errors before they spread: read the output against the request you made, look for claims you did not supply, run the code, open the link, do one calculation by hand. The depth scales with stakes. A habit is better than a rule because it runs even when you are in a hurry, which is when errors slip through.
Checking results Delegating to an agent: Reviewing what the agent delivered against the brief's done-criteria rather than against a general impression. Read the changes, not the agent's summary of them; run what can be run; look for work outside the limits you set. A plausible result is easy to accept and often subtly wrong, so the brief is the yardstick, and any gap goes back into the next brief.
Choosing a degree of autonomy Delegating to an agent: Deciding, per task, how much the agent may do before you look: draft only, act but ask before anything irreversible, or run to completion. The choice follows from how costly a mistake is and how easily it is undone, not from how capable the agent seems. Start with less autonomy on a new kind of task and widen it as the results earn trust.
CI integration Agents in a team: Making the continuous integration pipeline the shared gate for agent changes: the same lint, test, build and security checks run on every pull request regardless of who or what wrote it. CI turns individual verification into a team guarantee and gives agents an objective target. Agents can also be given CI results to fix, within the same bounds as any self-checking loop.
Client Connecting tools with MCP: The side inside the agent application that connects to servers, lists the tools they offer, passes those descriptions to the model, executes the model's tool calls against the right server and returns results. The client is where connection configuration, approval prompts and permission checks live, so it is where a user controls what a server may do.
Code- vs model-driven orchestration Orchestration and multi-agent: Two ways to coordinate agents. In code-driven orchestration a program decides which agent runs when, passing outputs along fixed paths; it is predictable, testable and cheap. In model-driven orchestration a model decides, delegating to other agents as tools; it adapts to unforeseen cases and is harder to bound. Use code for known workflows and a model for the genuinely open parts.
Codebase understanding Running a coding agent: Using the agent to orient in unfamiliar code before changing it: ask where a feature lives, how a request flows, what a module depends on. The agent reads files and searches faster than you can, and its explanation is a fast first map. Verify the map against the code on anything you will act on, since agents summarize confidently.
Commits and PRs Plan, implement, verify: Recording agent-assisted work in the team's normal units: focused commits with messages that say why, and pull requests that explain the change, link the specification and state what was verified and how. Good commit boundaries make review and revert possible; a PR that describes the agent's role lets reviewers calibrate their attention.
Compaction Memory and session context: Replacing a long session's history with a summary so work can continue inside the context window. Compaction keeps the goal and recent state and drops the raw detail, so anything not in the summary is lost. Ask for a summary that names open items and decisions before compacting, and save it to a file when the work will span sessions.
Confidentiality Responsible use: Information you are trusted to keep inside a boundary: customer contracts, unreleased plans, source code, colleagues' conversations. Pasting it into an AI tool is a disclosure to a third party, even if nobody reads it. The test is whether you would email the same text to that provider; if not, summarize, redact or use a sanctioned tool.
Context files Memory and session context: Files a person curates for the agent to read: project instructions, design notes, a plan, a glossary of domain terms. Unlike auto-memory they are deliberate, versioned and reviewed like code. They are the right place for anything the whole team wants every session to know, and the place to move a fact once auto-memory has proven it useful.
Context rot Grounding and memory: The decline in a model's performance as its context window fills with old turns, tool output and stale instructions. Important details get lost among irrelevant ones, early instructions are followed less reliably and answers drift. Long sessions and large pasted documents cause it. The cure is to keep context short and deliberate: summarize, start fresh, or retrieve only what is needed.
Context window How language models work: The maximum number of tokens a model can take into account at once, counting the instructions, the conversation so far, any documents pasted in and the answer it is producing. Anything outside the window does not exist for the model. Larger windows cost more per call and do not guarantee the model uses everything inside them equally well.
Cost Guardrails and production: What an agent spends per task in tokens, tool calls and time, and how that scales with users. Agents multiply model cost by their number of turns, and a runaway loop or verbose tool can multiply it again. Track cost per run, set budgets that stop a run, cache what repeats, and route simple steps to smaller models.
Cost and latency Capabilities and limits: Every token read or written costs money and time. Long prompts, large documents, big models and multi-step agents multiply both. Latency grows with output length because tokens are produced one at a time. Cost and latency are why a smaller model or a shorter prompt is often the right engineering choice even when a larger one would answer slightly better.
Cost and speed Choosing models and tools: The price and delay of a choice, per task and at the volume you expect. A model that costs ten times more and answers slower must be enough better to justify it; an agent that takes twenty tool calls costs twenty times a single answer. For repeated work, small differences per call become the whole budget, so measure before scaling.
Critique Working with an assistant: Asking an assistant to review your own work: find weak arguments, unclear passages, missing steps or errors. Because models tend to praise, ask for problems only, ask it to grade against stated criteria, or tell it the text is someone else's. Critique is one of the safest uses, since you remain the author and judge every suggestion.
Data privacy Responsible use: Personal data or source code pasted into a prompt leaves your control. Where it goes is set by the tool's terms: how long the provider retains it, whether it may train on it, where it is stored and where it is processed, and which subprocessors it passes through. A tool built on a gateway built on a model vendor has three such policies. Remove or replace names, contact details, health or financial information and anything covered by privacy law unless the tool is approved for it.
Decomposition into components Deciding and specifying: Splitting a problem into parts with clear responsibilities and interfaces, each small enough to build and verify on its own. Good components can be implemented in any order that respects their dependencies, tested in isolation and replaced without touching the rest. The split is a design decision the engineer owns; agents follow it well and invent it poorly.
Defense layers Guardrails and production: No single control stops every bad outcome, so production agents stack several: policy in the system prompt, input and output filtering, permission limits on tools, human approval at irreversible steps, monitoring and alerting, and the ability to stop the agent. Each layer catches what the previous ones miss, and the design assumes the model itself will sometimes be fooled.
Degree of autonomy What an agent is: How much an agent may do before a human sees it. At one end it only suggests; further along it acts but asks before anything irreversible; at the far end it runs unattended. Autonomy is a setting chosen for a task, not a property of the product, and the right level depends on how costly a mistake is and how easily it can be undone.
Dependencies Deciding and specifying: The relationships that force an order: which component needs another to exist first, which decision has to be made before a piece can be specified, which external system must be available. Naming dependencies early sets the sequence of work, shows what can proceed in parallel and exposes the risky assumption that everything else rests on.
Dependency hygiene Quality with agents: Adding libraries deliberately and keeping them pinned, current and few. An agent asked to solve a problem will often add a package where a few lines would do, or pick one it has seen frequently rather than one that is maintained. Review every new dependency for need, license, maintenance and size, and lock versions so builds stay reproducible.
Designing the verification Deciding and specifying: Deciding how each piece of work will be checked before it is built: which tests must pass, what to observe in the running system, which review questions to ask. Designing the check first makes the criteria precise, gives the agent a target it can run itself, and keeps verification from being replaced by a glance at a diff that looks right.
Deterministic gates Verifying agent work: Checks whose outcome does not depend on a model's judgment: tests, type checks, linters, builds and schema validation. They give the same answer for the same input, so they can block a merge. A review by another model adds a second opinion and finds things a gate cannot, but it can be wrong or be persuaded in the same way as the first model, so it never replaces the gate.
Disclosure Responsible use: Saying that AI was used, to the extent the audience expects. A reader of a report, a reviewer of code or a party to a contract generally wants to know whether a machine drafted the text and who checked it. Disclosure is about trust, not shame: state what the AI did, what you did, and who is accountable for the result.
Documentation Quality with agents: Keeping the written explanation of a system current as agents change it. Agents can draft documentation from code well, and equally well leave it stale. Treat docs as part of the change: the brief names what must be updated, the review checks it, and project instructions tell the agent where documentation lives and what style it follows.
Drafting Working with an assistant: Getting a first version of an email, report, plan or message from a brief, then shaping it. Give the audience, the purpose, the points that must appear and the tone; ask for alternatives when you are unsure. The draft is raw material, not the product. The facts in it are yours to supply and check, and the final voice should be yours.
Endorsed answers Verifying outputs: An answer that a qualified human has reviewed and marked as correct, distinct from raw model output. Some teaching and support systems show the mark so readers know which answers carry human accountability. The idea transfers to teams: separate what the model said from what a person has checked, and make the difference visible in the artifact.
Error analysis Evaluation and testing: Reading failed runs one by one, classifying what went wrong and where, and counting the categories. It replaces guessing about what to fix with evidence: the most common failure is usually one thing, such as a tool schema or a retrieval miss, and fixing it moves the metric more than any general tuning. It is the highest-value activity in improving an agent.
Error handling Tool use: What happens when a tool fails, times out or returns something unexpected. The result should go back to the model as a clear, structured error it can reason about, not an exception that ends the run or an empty string it treats as success. Design tools to fail loudly and informatively, and decide in the harness how many retries a step gets.
Escalation Governance and oversight: The agreed route for raising an AI-related problem: a leaked document, an agent that took a wrong action, output that harmed someone. It names who to tell, how fast and what to preserve. People report faster when the route is known and blameless, and the organization learns from near-misses instead of only from disasters.
Eval-gated deploys Guardrails and production: Treating any change to prompt, tools, model or harness as a release that must pass the evaluation suite before it reaches users, the same way code must pass tests. The gate turns evaluation from an occasional study into a continuous control and catches the regression that a small wording change or a model update introduces.
Example (few-shot) Prompting: One or more worked input-output pairs placed in the prompt so the model can copy the pattern. Few-shot examples are the most reliable way to fix a format, tone or edge-case behavior that is hard to describe in words. Two or three well-chosen examples usually beat a long paragraph of rules, and a bad example teaches the mistake just as well.
Exfiltration Agent risk: Data leaving a boundary it should not cross, often as the second half of an injection: the agent is tricked into putting secrets, private files or conversation contents into a URL, a message or a public location. Any tool that can send data outward is an exfiltration path. Review those tools first and restrict where an agent may send anything.
Finding information Working with an assistant: Using an assistant to locate, summarize and compare information, in documents you supply or, with a search tool, on the web. It is fast at orientation and at turning a long text into the three things you need to know. It is unreliable on specifics from memory alone, so ask for sources, supply the material yourself where you can, and check anything you will repeat.
First change Running a coding agent: A small, well-bounded edit done with the agent to learn how it works: a fix with a failing test, a rename, a documentation update. Brief it, watch which files it reads, read the diff it proposes and run the tests yourself. The point is to calibrate how it behaves in your project before trusting it with something larger.
Function calling Tool use: The mechanism by which a model asks for a tool to run. The developer sends tool definitions with the prompt; the model replies with a structured request naming a tool and its arguments instead of prose; the application executes it and sends the result back as a new message. The model never runs code itself; it emits a request the harness fulfils.
Giving context Delegating to an agent: Supplying the agent with the information and materials the task depends on: the relevant files, the approved source of numbers, the constraint you know and it cannot, the example of what good looks like. An agent that has to guess sources takes the most available one, not the right one. Point at things by name and location rather than by description.
Golden sets Evaluation and testing: A curated set of inputs with expected outputs or qualities, covering typical cases, edge cases and past failures, run every time the agent, prompt or model changes. The golden set is the agent's regression suite. It should be representative of real use, grow with every production incident and stay small enough to run often.
Grounding Grounding and memory: Tying a model's answer to sources it was given rather than to what it remembers. A grounded answer cites the passage it relied on and says so when the sources do not cover the question. Grounding reduces hallucination about the supplied material but does not make the model check facts on its own, and it cannot fix a source that is wrong.
Hallucination Capabilities and limits: Output that is fluent and confident but false: an invented citation, a function that does not exist, a plausible date that is wrong. It happens because the model predicts likely text, not verified facts, and it has no built-in signal for "I do not know". Hallucination is most likely on specifics, rare topics and anything the model cannot look up.
Hallucination in practice Recognizing failure: What invented output looks like in daily work: a statute with a real number and wrong contents, a library method that almost exists, a quote attributed to the right person from a speech never given, a summary that adds a point the source did not make. The tell is specificity without a checkable source. Treat precise details from a model as claims to verify, not facts.
Harness What an agent is: The software around the model that makes it an agent: the loop, the tool definitions, the permission checks, the system prompt, context management and the stop rules. Two agents using the same model can behave very differently because their harnesses differ. When an agent misbehaves, the fix is usually in the harness, not the model.
Hierarchical planning Design patterns: Breaking a large goal into subgoals, each with its own plan, often handled by its own agent call or subagent with a fresh context. The top level tracks subgoals and their status; lower levels handle detail. It keeps any one context small and focused and maps well onto decomposed specifications, at the cost of coordination and of information lost between levels.
Hooks Hooks, permissions, settings: User-defined scripts the agent runs at lifecycle events: before or after a tool call, when a session starts, when the agent finishes. A hook can block an action, transform it, or run a check such as formatting or a secret scan. Hooks enforce rules deterministically where instructions only ask, and their output goes back to the agent so it can react.
Human in the loop Agent risk: A required human decision at a chosen point in an agent's work, such as before sending, paying, deleting or deploying. The human sees what the agent proposes and approves, edits or stops it. Placing the checkpoint at the irreversible step, rather than everywhere, keeps the agent useful while keeping accountability with a person.
Install and setup Running a coding agent: Getting a coding agent running in a terminal or editor: installing the tool, authenticating to a model provider, opening it in a repository and checking it can run the project's own commands. Setup is also where you decide what the agent may reach, so do it in a repository you can afford to have touched and with a clean working tree.
Instruction Prompting: The part of a prompt that says what to do. A clear instruction names the task, the input it applies to, the constraints to respect and what a good result looks like. Vague instructions are filled in by the model with plausible defaults, so most prompt failures trace back to something the instruction left unsaid rather than to the model misunderstanding.
Instruction dilution Capabilities and limits: The weakening of an instruction as more text piles up after it in the context window. A rule stated once at the start competes with everything said since; in a long conversation or a long instruction file the model follows some rules and quietly drops others. Dilution is why short instruction files work better than long ones and why a rule that must always hold belongs in a mechanical check, not in prose.
Isolating a fault Verifying agent work: Narrowing a failure to its cause by systematic steps: reproduce it, shrink the input, bisect the change, add observation at the boundary, confirm the hypothesis before fixing. Agents can help at each step but will also guess fixes; insisting on a reproduced, explained cause before any patch is what keeps the fix from becoming a new bug.
Iteration Prompting: Improving a result by changing the prompt after reading the output, rather than resending the same prompt hoping for a better draw. Each round adds a missing constraint, an example of the failure, or a sharper definition of done. Iteration is the normal way to reach a reliable prompt; a first attempt that works is the exception.
Iteration Decomposing work: Working in rounds: delegate a piece, check it, adjust the brief with what you learned, delegate the next. The first result usually reveals a missing constraint or a wrong assumption about the goal. Treat each round as feedback on the brief rather than as the agent failing, and keep rounds short so mistakes stay cheap.
Knowledge cutoff Capabilities and limits: The date after which a model's training data stops. Events, releases and documentation newer than the cutoff are unknown to the model unless they are pasted into the context or fetched by a tool. A model will often answer about recent things anyway, from older patterns, so the cutoff is a common and quiet source of wrong answers.
Licensing and attribution Responsible use: Material you give a model and material it produces both carry obligations. Feeding in copyrighted text or code you may not redistribute does not remove the restriction on it, and output that reproduces a source needs the same attribution the source demands. Keep track of where inputs came from and check that output which looks copied is credited or replaced.
LLM as judge Evaluation and testing: Using a model to grade outputs against a rubric, so evaluation scales beyond what humans can read. It works well for criteria a careful reader could apply and poorly for facts the judge cannot check. Judges have biases, toward length, toward their own style, toward the first option, so calibrate them against human grades on a sample and re-check when the model changes.
Logging and audit Governance and oversight: Recording what an agent was asked, what it did, which tools it called and what changed, so that a person can later reconstruct and judge its actions. Logs turn an opaque incident into a traceable one and make patterns visible across many sessions. Store them where the agent itself cannot edit them, and review a sample even when nothing has gone wrong.
Loop from scratch The agent loop and harness: Writing the agent loop yourself in a few dozen lines: send the conversation and tool definitions to the model, inspect the reply, run any requested tool, append the result, and call again until the model answers without a tool request. Building it once removes the mystery from every agent product and shows where the real difficulty lies: in tools, context and stopping.
MCP primitives Connecting tools with MCP: The kinds of things a server can offer besides tools. Resources are data the client can read into context, such as files or records, each with a URI. Prompts are reusable templates the user picks by name. Sampling lets a server ask the client's model to complete text, so the server needs no model access of its own. Roots tell a server which directories it may work in. Most servers only use tools, and the others matter only when your client supports them.
MCP security Connecting tools with MCP: Connecting a server extends the agent's blast radius to everything the server can reach. Risks include servers from untrusted sources, tool descriptions that carry injected instructions, tools that return attacker-controlled content, and tools that can send data outward. Vet the source, run with least privilege, approve risky tools per call and review what leaves. Connect a server with your own identity, never with a shared service account, so it can do only what you may do and its actions trace back to you.
MCP vs CLI Connecting tools with MCP: An agent can often reach the same system through a protocol server or by running a command-line tool it already knows. A server gives typed tools, discoverability and a stable interface across agents. A CLI is already installed, costs no tool descriptions in context and is easy to audit. Prefer the CLI when it exists and is good; add a server when the interface needs shaping.
Memory storage choices Agentic retrieval and memory: Where an agent's long-term memory lives and how it is found again: plain files the agent reads whole, key-value notes, a searchable index over text, a database queried by tool, or summaries folded into the system prompt. Each trades simplicity against scale and precision. Start with files the human can read and edit; add indexing when volume demands it.
Metrics that cannot be gamed Evaluation and testing: A metric that can improve without the real quality improving will be optimized until it does exactly that. Length, keyword presence and self-reported success are easy to game; tests the agent cannot see, human spot checks and outcomes measured downstream are harder. Choose metrics that require the quality itself to move, and watch for divergence between the number and what users see.
Model change risk Governance and oversight: Providers update models, and a workflow that behaved well can behave differently after an update: a format changes, a refusal appears, a shortcut is taken. Because the model is outside your control, treat each change like a dependency upgrade: pin versions where possible, keep a test set that represents your tasks, and re-run it when the model changes.
Model family and size How language models work: Vendors publish models in families with several sizes. Larger models usually reason better and follow complex instructions more reliably, but cost more and respond more slowly. Smaller models are cheaper and faster and are often good enough for narrow, well-specified tasks. Choosing a model means matching the size to the difficulty of the job.
Model fit Choosing models and tools: Matching a model to a task by what the task needs: a small fast model for classification or reformatting, a larger one for multi-step reasoning or ambiguous instructions, a model with tools where fresh facts matter. Fit is tested, not assumed: run a few representative inputs on each candidate and compare, rather than defaulting to the most capable and expensive option.
Model vs agent What an agent is: A model takes text in and produces text out, once. An agent is software that calls a model repeatedly, gives it tools, feeds the tool results back and stops when a goal is met. The model supplies judgment; the agent supplies hands, memory and a loop. Most of what makes an agent useful or dangerous lives in the software around the model.
Monorepo hierarchy Project instructions: In a repository with many packages, instruction files can sit at the root and inside subdirectories; the agent reads the ones on the path to the files it is working on. Root holds what is true everywhere, subdirectory files hold what differs. The hierarchy keeps each file short and lets teams own their own rules without conflicting.
N x M integration problem Tool use: With N agent applications and M tools or data sources, every pairing needs its own integration unless both sides speak a shared protocol. This is what made a standard for tool connections necessary: a tool exposed once through the protocol works with every compliant agent, turning N times M integrations into N plus M.
Non-determinism Capabilities and limits: The same prompt can produce different answers on different runs because output is sampled from probabilities. Even at the lowest temperature, small differences in serving can change results. This means one good answer does not prove a prompt is reliable, and any process built on a model needs checks that tolerate variation.
Observability Evaluation and testing: Recording what an agent does in real use so it can be inspected later: each model call, tool call, result, latency and cost, tied together as a trace per run. Observability turns a user complaint into a traceable run, feeds error analysis and the golden set, and shows drift when a model or dependency changes. Without it, production is a black box.
Observing a running system Verifying agent work: Running the changed software and watching what it actually does: the logs it writes, the requests it makes, the state it leaves behind, the screen it renders. Tests prove what they cover; observation catches what nobody thought to test. For agent work, running it yourself is also the check that the agent's report of "tests pass" is true.
Orchestration tax Orchestration and multi-agent: The cost every additional agent adds: more tokens for handoffs and repeated context, latency from extra calls, information lost at each boundary, new failure modes when agents disagree or wait on each other, and harder debugging. A multi-agent design has to beat a single well-equipped agent by more than this tax, and often it does not.
Overreliance Recognizing failure: Trusting a model's output beyond what you have checked or could check. It starts with tasks you know well and then spreads to ones you do not, where you can no longer tell a good answer from a plausible one. The remedy is to keep verifying in proportion to stakes and to keep enough of your own competence to recognize when the tool is wrong.
Parallel calls Tool use: Letting the model request several independent tool calls in one turn, which the harness executes concurrently and returns together. It cuts latency and round trips for read-heavy work such as fetching several files. Calls that depend on each other's results must stay sequential, and side-effecting tools need care because concurrent execution can reorder them.
Parallel sessions Agents in a team: Running more than one agent session at once, on separate tasks, to use waiting time. It multiplies output and also the chances of two sessions editing the same files, losing track of which change belongs where, or exhausting your own attention for review. Parallel work needs isolation per session and a discipline of finishing and reviewing one task before merging the next.
Permission modes Hooks, permissions, settings: Preset levels of how much an agent may do without asking, from approving every edit and command, through auto-accepting edits but asking for commands, to running everything unattended. The mode sets the default; allowlists refine it. Choose per task by what a mistake would cost, and step up only inside a sandbox or a disposable worktree.
Permissions Running a coding agent: What the agent may do without asking: read files, edit files, run commands, reach the network. Coding agents prompt for approval on risky actions by default and let you widen or narrow that. Approving everything for convenience turns a mistake in a command into a mistake in your repository or system, so widen access per project and per task.
Permissions and least privilege Agent risk: Giving an agent only the access the current task needs: read where it needs to read, write only in the working folder, no network or credentials unless required. Least privilege limits what a mistake or an attack can do. Convenient broad access is the usual failure; a separate account, a sandbox or a scoped token is the usual fix.
Plan mode Plan, implement, verify: Having the agent explore and propose before it edits anything. In plan mode it reads the code, asks questions and writes down the steps it intends to take; you correct the plan while corrections are cheap. Most agent mistakes are cheaper to catch in a plan than in a diff, so use it for any change touching more than a couple of files.
Plan-then-execute vs reactive Design patterns: Two ends of a spectrum. Plan-then-execute decides the whole sequence first and then runs it, which is predictable, cheap to review and brittle when a step surprises. Reactive decides one step at a time from the latest observation, which adapts well and is harder to predict or bound. Most agents mix the two: plan coarsely, react within a step.
Planning Design patterns: Having the agent write out the steps to a goal before taking them, as a list it then works through and updates. A written plan improves multi-step tasks, makes progress visible and gives a human a moment to correct course cheaply. Plans go stale as steps reveal new facts, so the pattern includes revisiting the plan, not only following it.
Plugins Agent skills: The unit for distributing customizations together: a plugin bundles skills, hooks, subagents and server connections into one installable package with a version. A marketplace is a catalog of plugins that a team or vendor publishes so others can install from it by name. Installing a plugin lets its hooks run in your sessions and gives its servers the access you grant, so treat it like any other dependency and read what it contains.
Policy Governance and oversight: A written statement of which AI tools may be used, with what data, for what tasks, and with what checks before results are relied on. A good policy is short, names owners and gives examples of allowed and disallowed use. Without one, every person invents their own rules and the organization's exposure is the sum of the most careless choices.
Progressive disclosure Agent skills: Structuring a skill so the agent reads only what the current step needs: a short description always visible, the main instructions loaded when the skill is chosen, and detailed references or scripts opened only when a step calls for them. It keeps the context window small across many available skills and puts depth where it is used instead of where it is loaded.
Project instructions Context engineering for code: A file in the repository the agent reads at the start of every session, holding what it needs to know each time: how to build and test, the conventions to follow, the places not to touch. It is where a recurring agent mistake gets fixed once. Keep it short and factual; long instruction files are followed less reliably than short ones.
Prompt injection Agent risk: An attack where text the agent reads, such as a web page, email, document or code comment, contains instructions that the model follows as if they came from its user. The model cannot reliably tell data from commands. Any agent that reads untrusted content and can act is exposed, and the defense is limiting what it can do, not hoping it will refuse.
Protocols (MCP, A2A) Guardrails and production: Standards for how agents connect to things. The Model Context Protocol standardizes how an agent reaches tools and data through servers. Agent-to-agent protocols standardize how one agent discovers, delegates to and exchanges results with another across organizations. Shared protocols reduce integration work and also widen the attack surface, so each connection is a trust decision.
Provider operations Guardrails and production: The mechanics of calling a model provider reliably. Pin an exact model ID, one that names a single fixed version, so the model changes only when you choose. Use prompt caching so the stable prefix of a system prompt and tool list is processed once and read back at a lower price on later calls. Retry retriable errors, such as rate limits and overload, with a backoff. Report terminal ones, such as an invalid request or a content refusal, to the caller. Set timeouts on every call.
Quality pillars Evaluation and testing: The distinct dimensions along which an agent can be good or bad: correctness of the result, faithfulness to sources, safety of actions, efficiency in steps and tokens, and adherence to instructions and format. Naming them separately matters because they trade off; an agent can score well on one while failing another, and one number hides that.
ReAct Design patterns: A pattern where the model alternates a short written reasoning step with an action, observes the result and reasons again. Making the reasoning explicit before each tool call improves tool choice and leaves a readable trace of why the agent did what it did. Most tool-using agent loops are a form of this pattern, whether or not the reasoning is shown to the user.
Reasoning across tool levels Choosing models and tools: Tools rise in abstraction, from autocomplete to chat to agents to systems of agents, and each level hides more of what happens below. The judgment about fit, cost, risk and what to keep human has to be re-applied at each new level rather than carried over. What was safe to trust at one level may not be at the next, and vice versa.
Red-teaming your own agent Verifying agent work: Deliberately trying to make your own agent misbehave before relying on it: feeding it a file with hidden instructions, pasting it a web page you did not read, asking for something its permissions should stop, giving it an ambiguous brief and seeing how far it runs. The aim is to learn what it does under pressure, in a sandbox where nothing real can be damaged. What you find becomes a permission change, an instruction or a gate.
Referencing files Context engineering for code: Naming the exact files, functions or documents the agent should read instead of describing them, so it loads the right context on the first try. A path and a line number beat "the config code". Reference the example to imitate, the test to extend and the spec to follow; the agent will otherwise pick whichever similar file it finds first.
Reflection Design patterns: Having the model critique its own output, or a second model call critique it, and then revise. Reflection catches errors a single pass misses, especially in code, arguments and formats with checkable rules. It costs extra calls and can loop on trivial edits, so bound the rounds and give the critic concrete criteria rather than asking whether the answer is good.
Regulation Governance and oversight: Law that applies to how an organization builds and uses AI, with the EU AI Act as the main example. It defines what counts as an AI system, sorts uses into risk tiers from prohibited to minimal, and puts different duties on the provider who builds a system and the deployer who uses it. Deployers owe transparency to the people affected and must make sure their staff have enough AI literacy for the tools they use.
Retrieval (RAG) Grounding and memory: Retrieval-augmented generation: before the model answers, a search finds the passages most relevant to the question and pastes them into the prompt, so the answer can rest on documents the model never saw in training. It is how assistants answer about your files or a company wiki. Its quality is bounded by the search; irrelevant passages produce confident wrong answers.
Reversibility Plan, implement, verify: Keeping every change easy to undo: committed in small steps, on a branch, with no destructive operations mixed in, and with data migrations that can be rolled back. Reversibility is what makes it safe to let an agent try something. If a step cannot be reversed, it is the step that needs a human to look before it runs.
Review norms Agents in a team: The team's agreements on how agent-assisted changes are reviewed: the author reads and understands every line before requesting review, the PR says what the agent did and what was verified, reviewers read the diff rather than the description, and size limits keep changes reviewable. Norms keep the human accountability that agents can quietly erode.
Reviewing code you did not write Verifying agent work: Reading an agent's diff as a reviewer, not an author: you have no memory of why each line exists, so every line has to justify itself. Look for changes outside the brief, silent behavior changes, deleted tests, copied patterns applied wrongly and comments that describe intent rather than what the code does. Read the code, not the agent's summary of it.
Risk assessment Governance and oversight: A short, written method for judging an AI use case before it starts. Name the domains it touches, such as personal data, money, safety or reputation, then rate impact and likelihood on agreed scales and combine them into a level. A level above the agreed threshold needs extra controls or a decision, in writing, from someone with the authority to accept the risk. The record is what makes the decision reviewable later.
Role and system prompt Prompting: Text set before the conversation starts that frames every later turn. A system prompt typically assigns a role, sets tone, states standing rules and lists what the model must never do. In chat products the vendor writes one you cannot see; in agents and custom applications the developer writes it, and it is where recurring behavior is fixed.
Rollout strategies Guardrails and production: Releasing a change to a fraction of traffic first, comparing its metrics with the current version, and widening or reverting based on what is observed. Shadow runs, canaries and gradual percentages all apply to agents. Because model behavior is non-deterministic and evaluation is imperfect, gradual rollout is the check that evaluation cannot give.
Rubrics Evaluation and testing: Written criteria that turn "good" into scorable statements: what a passing answer must contain, what disqualifies it, how partial credit is given. A rubric lets different graders, human or model, agree, and it makes the definition of quality reviewable and improvable. Writing one usually exposes disagreement about what the agent is for.
Sampling and temperature How language models work: At each step the model has a probability for every possible next token and picks one by sampling. Temperature scales those probabilities: low values make the model pick the most likely token almost every time, high values spread the choice across less likely options. Low temperature gives consistent, conservative output; high temperature gives variety at the cost of more mistakes.
Sandbox Running a coding agent: An isolated environment the agent runs in so that a wrong command damages only what is inside it: a container, a virtual machine or a separate user account. The sandbox limits which files, network destinations and credentials the agent can reach. It is a control you set up before the session, and a coding agent with no sandbox has exactly the access you have.
Scoping a task Context engineering for code: Telling the agent where a task lives and where it stops: which module, which layer, which files are in play and which are off limits. Scoping saves context by avoiding exploration of irrelevant code and prevents the well-meaning refactor that spreads a small change across the repository. A scoped brief also makes the resulting diff easier to review.
Secrets hygiene Running a coding agent: Handling the API keys and tokens an agent needs so a leak stays small. Use a personal key, never a shared one, and keep it in a password manager or an environment variable. A key never goes into a file the agent can commit. If a key may have been exposed, revoke it first and investigate afterwards, because rotation is cheap and a leaked key is used by someone else quickly.
Sections Project instructions: The recurring parts of a good instruction file: what the project is, how to build, test and lint, the layout of the code, the conventions to follow, the things never to do, and how to finish a piece of work. Each section answers a question the agent would otherwise guess at. Remove anything the agent can discover cheaply itself, and keep examples concrete.
Security review of agent output Quality with agents: Checking agent-written code for the classic mistakes it makes easily: unvalidated input, string-built queries and commands, secrets in code, permissive defaults, disabled checks, error handling that hides failures. Agents reproduce common patterns including common vulnerabilities. Static analysis catches some; a reviewer asking "what if the input is hostile" catches more.
Sequencing for early feedback Plan, implement, verify: Ordering increments so the riskiest assumption or the most visible behavior is tested first. Build the thin end-to-end path before the details, the integration before the polish, the part you are least sure about before the part you are certain of. Early feedback turns a possible rewrite into a small correction.
Sequential / hierarchical / collaborative Orchestration and multi-agent: Three arrangements. Sequential: agents form a pipeline, each transforming the previous output. Hierarchical: a manager agent delegates subtasks to workers and integrates their results. Collaborative: peer agents share a workspace or conversation and negotiate. Complexity and unpredictability rise in that order; sequential is enough far more often than it seems.
Server Connecting tools with MCP: The process that exposes tools, resources and prompts over the protocol. A server wraps something, a database, an API, a file system, a browser, and describes each tool with a name, a purpose and a parameter schema the model can read. Write or install a server once and any compliant agent can use it, which is the protocol's point.
Session and context Running a coding agent: A session is one conversation with the agent and its context window is the session's memory. Every file read and command output lands in it, so long sessions fill up and the agent starts forgetting earlier instructions. Keep one task per session, start fresh for unrelated work, and ask for a summary before compacting or handing off.
Session handoff Memory and session context: Ending one session so the next can pick up without loss: a written state of what was done, what remains, what was decided and why, and where the relevant files are, stored in the repository or a plan file. A good handoff lets a fresh session, or a colleague's, start productive in one turn instead of rediscovering the work.
Settings layering Hooks, permissions, settings: Configuration comes from several places that override each other in a fixed order: the user's own defaults, the project's shared settings committed to the repository, local project overrides that are not committed, and flags for one session. Knowing the order explains why a setting seems ignored and lets a team ship safe defaults while people keep personal preferences.
Short- and long-term memory Grounding and memory: Short-term memory is the current context window: everything said and seen in this session, gone when it ends. Long-term memory is anything written down outside the window and read back later, such as notes files, summaries or a database the agent searches. Models have no other memory; "it remembered" always means something was stored and re-read.
Skill spec Agent skills: The open format for an agent skill: a directory with a metadata file that names the skill, describes when to use it and holds the instructions, plus optional scripts and reference files alongside. The description is what the agent reads to decide whether to load the skill, so it carries the trigger; the body carries the procedure. Because the format is shared, skills move between agents.
Skill vs tool vs instruction Agent skills: Three ways to change what an agent does. An instruction is standing text loaded every session, for rules that always apply. A tool is a function the agent can call, for capabilities it lacks. A skill is a procedure loaded only when relevant, for repeatable multi-step work the agent could do but does inconsistently. Pick by frequency, by whether the need is knowledge or capability, and by context cost.
Source checking Verifying outputs: Following a claim, citation or quote back to where it is supposed to come from and confirming it says what the model reported. Models produce references that look right more easily than references that are right. Anything with a page number, URL, statute, version or study behind it should be opened before it goes to anyone else.
Spec-driven change Plan, implement, verify: Writing the specification of a change, including its success criteria, as a document the agent works from and the reviewer checks against. The spec stays the source of truth while the agent iterates; when the code and the spec disagree, one of them is updated deliberately. It suits changes where the design matters more than any single test.
Stop conditions The agent loop and harness: The rules that end a run: the model answers without requesting a tool, a maximum number of turns or tokens is reached, a budget is spent, a check passes, or a human stops it. An agent with only the first rule can run indefinitely. Good harnesses combine a natural completion signal with hard limits and report which one fired.
Structured output Prompting: Asking the model to answer in a fixed shape, such as a table, a numbered list with named fields, or a machine-readable format like JSON, so the next step can use the result without a human reformatting it. Naming the fields and giving one example of the shape makes the output far more consistent and makes missing information visible.
Subagents Hooks, permissions, settings: Separate agent instances the main agent delegates to, each with its own context window, tool set and often its own instructions. They keep bulky work such as searching or reviewing out of the main context, allow parallel work and let a task run with narrower permissions than the parent. The parent sees only the subagent's report.
Success criteria Deciding and specifying: Concrete, checkable statements of what a finished result must do and must not do, written before the work starts. Good criteria describe observable behavior, name the edge cases that matter and set limits such as performance or compatibility. They become the agent's target and the reviewer's checklist, and they stop a plausible result from being accepted as a correct one.
Supply-chain risk Quality with agents: The risk that something you install is not what it seems: a package name the agent hallucinated that an attacker has registered, an action or plugin pinned to a moving tag, a transitive dependency with a known flaw. Agents increase exposure by suggesting names from memory. Verify that packages exist and are the intended ones, pin to exact versions, and audit regularly.
Sycophancy Capabilities and limits: The tendency of a model to agree with the user, praise their idea or change a correct answer when challenged, because agreeable text was rewarded during training. Sycophancy makes a model a poor judge of your own work unless you ask for criticism explicitly, hide your preference, or have it argue the other side.
Task brief Delegating to an agent: The short written statement you hand an agent: the goal, the context it needs, the limits it must stay inside and the criteria that make the work done. Whatever a brief leaves out, the agent fills in with a plausible default, so what it must not touch matters as much as what it must do. Writing done-criteria first turns review into a check.
Task decomposition Decomposing work: Splitting a large piece of work into steps small enough that each has a clear input, a clear output and a way to check it. Good pieces can be handed to an agent one at a time, verified independently and redone without losing the others. Decomposition also surfaces the decisions that are yours to make before the agent starts filling gaps.
Team hooks Agents in a team: Scripts that run automatically at fixed points, before a commit, after an agent edits a file, before a command runs, to enforce a rule mechanically: format the code, block a secret, refuse a forbidden path. Hooks enforce what instructions can only request, and they apply to every session and every team member the same way, which is what makes them a team tool.
Test-driven change Plan, implement, verify: Writing or having the agent write a failing test that captures the desired behavior, then implementing until it passes, then cleaning up. The test gives the agent an unambiguous target it can run on its own and gives you proof that the change does what was asked. It suits bounded behavioral changes and bug fixes.
Testing Quality with agents: Keeping tests that prove behavior rather than mirror implementation. Agents write tests readily, and readily write tests that pass by asserting what the code happens to do. Review agent tests for what they would catch if the code were wrong, keep them fast enough to run in an agent's loop, and never let an agent delete or weaken a test to make a change pass.
Thought partner Working with an assistant: Using the assistant to think, not to answer: explain your problem, ask it to question your assumptions, list what you might be missing, argue the opposite view or lay out options. The value is in your own clearer thinking. Ask for challenge explicitly, because a model left to itself tends to agree with the framing you give it.
Token How language models work: The unit a language model reads and writes. A token is a chunk of text, often a word fragment, punctuation mark or common word, chosen by a fixed tokenizer. Models are priced, limited and timed in tokens, not words or characters. A rough rule for English is three to four characters per token, so a page of text is a few hundred tokens.
Tool What an agent is: A function the agent can ask to run, described to the model by name, purpose and parameters. Reading a file, searching the web, running a command or calling an API are tools. The model does not execute anything itself; it emits a request, the agent runs it and returns the result. Tools are how an agent reaches beyond its context window.
Tool cost Connecting tools with MCP: Every connected tool adds its description to the context on every turn, and every call adds its result. A server with dozens of tools can consume a large share of the window before the task starts, and verbose results crowd out the conversation. Connect only the servers a project needs, prefer servers with few well-described tools, and watch result sizes.
Tool schema design Tool use: Writing the name, description and parameter schema that tell the model what a tool does and how to call it. The description is a prompt: it must say when to use the tool, what it returns and what it must not be used for. Few, well-named, strictly typed parameters with examples outperform flexible ones. Most tool misuse is a schema problem, not a model problem.
Training vs inference How language models work: Training is the one-off, expensive phase where a model's weights are adjusted on a large body of text until it predicts well. Inference is every later use of the frozen model to produce output. Nothing you type during inference changes the weights; the model only "remembers" what is in the current context window.
Trajectory evaluation Evaluation and testing: Grading the sequence of steps an agent took, not only its final output: did it call the right tools, in a sensible order, without dangerous or wasteful actions, and did it recover from errors. Two runs with the same answer can have very different trajectories, and the unsafe or lucky one will fail in production. Trajectories are also where error analysis starts.
Transport Connecting tools with MCP: How client and server exchange messages. A local server usually runs as a child process talking over standard input and output; a remote one is reached over HTTP, often with streaming. The transport decides where the server's code runs and what credentials it holds, which makes it a security decision as much as a plumbing one.
Trust boundary Running a coding agent: The line between what the agent may decide on its own and what is enforced from outside it. Instructions in a prompt are requests the model can ignore or be tricked out of, so a control that matters is enforced by the harness, the operating system or the network. Knowing what the agent sends to its provider, from file contents to command output, is part of drawing that line.
Turning repeated work into reusable knowledge Memory and session context: Noticing when the agent is explained the same thing or walked through the same steps twice, and moving it somewhere durable: a fact into project instructions, a procedure into a skill, a check into a hook, an example into a context file. Each move removes a future explanation and a future mistake. It is the compounding part of working with agents.
Unbounded-loop pitfalls The agent loop and harness: The ways a loop keeps going wrongly: retrying a failing tool forever, alternating between two fixes, satisfying a check by weakening it, re-reading the same files as context fills, or spending the whole budget on exploration. Each burns money and can cause harm through side effects. Limits, detection of repeated states and visible progress reporting are the defenses.
Verifying against the specification Verifying agent work: Checking the result against the success criteria written before the work, item by item, instead of judging whether the change looks reasonable. This catches the plausible-but-wrong result, the criterion quietly dropped and the edge case skipped. If a criterion cannot be checked, either the spec or the verification design needs fixing before the change is accepted.
What is worth building Deciding and specifying: Judging an idea before building it: who needs it, what it costs to build and to keep, what it displaces, and what happens if it is not built. Cheap implementation makes this judgment more important, not less, because the cost of building the wrong thing is now mostly the cost of maintaining it. Say no, or say smaller, before the agent starts.
What to keep human Choosing models and tools: The steps that stay with a person on purpose: decisions with legal or ethical weight, judgments about people, anything irreversible or costly, and the final accountability for a result. Keeping a step human is a design choice, and naming those steps early prevents them from being automated by default as tools improve. Keeping a human path also means the process keeps working when the tool is unavailable.
When basic RAG suffices Agentic retrieval and memory: Many systems need only the simple form: embed documents, retrieve the top matches for the question, put them in the prompt, answer. It is enough when questions are direct, the corpus is well chunked and latency matters. Reach for agentic retrieval only when evaluation shows failures on multi-step or ambiguous questions that a better index cannot fix.
When instructions are not enough Project instructions: Instructions are requests; a model follows them most of the time and forgets them as context fills. A rule that must hold every time, such as never committing secrets or always running the formatter, belongs in a hook or a permission setting that enforces it mechanically. A capability the agent lacks belongs in a tool or a skill, not in a longer paragraph.
When to stop and do it yourself Decomposing work: Recognizing the point where explaining, correcting and re-checking an agent costs more than doing the step directly. Signs include a third round on the same piece, a task that depends on knowledge only you hold, or a check that takes longer than the work. Taking the step back is a judgment call, not a failure of the tool or of you.
Working increments Plan, implement, verify: Landing a change as a series of small steps, each of which leaves the system working and tested. Increments keep the diff reviewable, keep the agent's context focused and make it obvious which step introduced a problem. An agent will happily produce a large change in one go; asking for increments is part of the brief.
Working with files and images Working with an assistant: Giving the assistant a document, spreadsheet, screenshot or photo to work from instead of describing it. This grounds the answer in your material and unlocks tasks such as extracting a table from a picture or comparing two versions of a contract. Mind what is in the file before uploading; attachments are data disclosure just like pasted text.
Worktrees Agents in a team: Separate checked-out copies of one repository, each on its own branch, sharing one history. A worktree per agent session gives each its own files and build state, so parallel sessions cannot overwrite each other and a bad session can be discarded without touching the others. They are the standard way to isolate concurrent agent work locally.
Writing a good skill Agent skills: A good skill has a description that fires on the right requests and no others, steps that are concrete enough to follow without guessing, a way for the agent to check its own result, and scripts for anything deterministic. It is tested by watching an agent use it on a real task and revising where it hesitated or went wrong, the same iteration loop as prompting.