The terms that keep showing up in the cards, and what changes once you know them.
28 terms
Fetching relevant documents first and pasting them into the prompt so the model answers from fresh or private data it never trained on.
Most quality problems live in retrieval, not generation, so when an answer is wrong, print what got retrieved before swapping the model.
See also Chunking · Vector database · Reranker · Context engineering
An LLM program that takes a goal, picks and calls tools on its own, reads the results, and decides the next step over many turns.
When a title says agent, it is not about answer quality but about a loop that keeps going after failures, so the metric becomes task completion, not accuracy.
See also Agent loop · Harness · Tool use · Long-horizonShowed up in Repos · Releases
The code wrapped around a model that supplies its prompts, tools, procedure, retries, and stop conditions so a task actually finishes.
A score that jumps with the same weights usually means this layer changed, so decide first whether the claim is about the model or about the shell around it.
See also Agent loop · Terminal-Bench · Verifier · Orchestration
The repeating cycle of think, call a tool, observe the result, and feed that observation back into the next prompt.
Cost is not one answer but how many times this cycle spins; runaway token bills almost always come from a loop that never decides to stop.
See also Agent · Harness · Tool use · Prompt Caching
Having the model call outside capabilities such as search, code execution, or file writes instead of answering from its own weights.
Failures split in two: the model choosing the wrong tool, and the tool returning junk, and debugging starts by deciding which one happened.
See also Function calling · Model Context Protocol · Sandbox · Agent
A convention where the model is given tool names and argument schemas up front and returns a chosen call with filled-in arguments.
The name and description are part of the prompt, so when a tool never gets called the culprit is usually that one description line, not the code.
See also Tool use · Structured output · Model Context Protocol · Agent Skills
Forcing the model to emit JSON that matches a fixed schema instead of free prose.
It removes parse failures from a pipeline, but a schema that is too tight makes the model flatten what it actually wanted to say.
See also Function calling · Tool use · Guardrails · Verifier
An open protocol that exposes tools and data sources in one shape so any client can connect to them the same way.
One server works across many clients, but every server you attach spends context on tool descriptions before the task even starts.
See also Tool use · Function calling · Context engineering · Prompt InjectionShowed up in Repos
Folders of instructions loaded only when relevant, injecting the how-to for a specific job at the moment it is needed.
A cheap way to add ability without growing the always-on prompt, though a vague trigger line means the file simply never loads.
See also Harness · Context engineering · AGENTS.md · Coding agent
A convention file at a repo root that tells coding tools how to build, test, and follow that project's rules.
When an agent flails on an unfamiliar repo it usually cannot find how to build or test it, and rules only persist if they live in the repo, not in a chat.
See also Coding agent · Agent Skills · Context engineering · Harness
A tool that reads and edits a repo, runs its tests, and carries one instruction all the way to a committable change.
What separates it from autocomplete is not the output but the loop, and the dividing line is whether it can run the tests itself.
An isolated environment where model-generated code or commands run, so a bad step cannot damage anything outside it.
The moment an agent gets a shell this becomes mandatory, and if the tool list includes deletes or pushes, an approval gate matters more than isolation.
See also Coding agent · Guardrails · Human in the Loop · Tool use
Letting a model read the screen and drive mouse and keyboard so it can operate apps that expose no API.
It is the last resort for tools with no API: slow, brittle, and worth logging every step because a rerun rarely reproduces the same screen.
See also Tool use · Sandbox · Guardrails · Agent
Splitting long documents into retrievable units, where the size and overlap of the pieces decide what can be found at all.
A table or code block cut in half effectively disappears from search, and a surprising share of retrieval failures trace back to this step.
See also Retrieval-Augmented Generation · Vector database · Reranker
A store that keeps text as numeric arrays of meaning and returns the entries closest to a query, fast.
It finds things that share no keywords, but it is weak exactly where you need a literal match, like an error code or an ID.
See also Retrieval-Augmented Generation · Chunking · Reranker
A small model that takes the few dozen candidates from first-pass search and re-scores them against the query.
If only the top five reach the prompt, ordering is the answer, and bolting this on is usually cheaper than replacing the retriever.
See also Retrieval-Augmented Generation · Vector database · Chunking
Storing facts, preferences, and past decisions outside the session and pulling them back into the prompt when they are needed.
More stored memory is not better: one stale fact that never gets retired makes the model confidently wrong, and it will quote that fact as its reason.
See also Context engineering · Retrieval-Augmented Generation · Long-horizon · Agent
Deciding what goes into each call and what stays out, treating the limited input window as a budget to spend.
It is not about writing a better prompt but about allocation: tool definitions, memory, and retrieved chunks all compete for the same room.
See also Agent memory · Retrieval-Augmented Generation · Model Context Protocol · Harness
The property of tasks that need tens or hundreds of chained steps, where one wrong turn early poisons everything after it.
Ninety-five percent per step is near-certain failure over fifty steps, so papers with this word are usually about recovery and stopping, not accuracy.
See also Agent loop · Agent memory · Verifier · Orchestration
Letting outside code own the order, branching, and retries across many model calls and tool runs.
The more decisions the model makes the more flexible it is; the more the code makes, the more it reproduces, and that line is the whole design.
See also Multi-agent · Harness · Agent loop · Subagent
Splitting one job across several role-specialized instances that pass results between each other.
You gain parallelism but they also cite each other's mistakes as evidence; work that fails with one instance rarely succeeds just by adding two more.
See also Orchestration · Subagent · Agent · Long-horizon
A child run spawned by the main session to keep its own context clean, returning only a summary of what it found.
The point is to offload long searching and take back a summary, with the catch that whatever the summary drops, the parent never sees.
See also Multi-agent · Orchestration · Context engineering · Agent
A middle layer that picks which model each request goes to, based on difficulty, price, and latency.
It is where cost gets cut by sending easy calls to cheap models, and also a single point whose outage takes every downstream app with it.
See also Orchestration · Harness · Prompt Caching
A machine check such as tests, compilation, or rules that scores an agent's output and lets it pass only when the check holds.
Papers with a verification gate usually raise scores by adding a grader, not a better model, and the trick only works where success is machine-checkable.
See also Harness · Long-horizon · Structured output · SWE-benchShowed up in Papers
A step-by-step record of one agent run: every prompt sent, every tool called, and what each call returned.
An agent rarely fails the same way twice, so you find the step that broke by rewinding the recorded run, not by trying to reproduce it.
See also Agent loop · Harness · Eval · Background agent
Replacing the earlier part of a long session with a summary so the run can keep going once the context window fills up.
Whatever the summary drops never comes back, and that is usually why a long run suddenly forgets what it was doing halfway through.
See also Context window · Context engineering · Agent memory · Long-horizon
An agent run that executes unattended in its own environment, reporting back as a pull request or a notification when it finishes.
There is no point to step in mid-run, so unless you narrow tool permissions and approval gates up front, review only happens after the fact.
See also Coding agent · Sandbox · Human in the Loop · Trace
Splitting a goal into small units with clear order and success conditions so each one can be run and checked on its own.
A bad split makes every later step fail faithfully; an agent that spins in circles is more often broken here than at the tool layer.
See also Long-horizon · Orchestration · Subagent · Verifier