| Workflow |
A system coordinating LLMs and tools through predefined code paths |
| Agent |
A system in which an LLM dynamically determines its own process and tool use |
| Augmented LLM |
An LLM extended with retrieval, tools and memory; the basic component of every agent structure |
| Agent loop |
Repetition in which the model chooses an action, executes a tool and receives the result as input again |
| Prompt chaining |
Fixed stages passing one call's output into the next call's input |
| Gate |
A point between chaining stages where code checks output |
| Routing |
A pattern classifying input and sending it to specialized downstream processing |
| Sectioning |
A parallelization variant running independent subtasks concurrently |
| Voting |
A parallelization variant running the same task repeatedly and collecting results |
| Orchestrator-workers |
A pattern where a central LLM dynamically divides work, delegates to workers and synthesizes results |
| Evaluator-optimizer |
An iterative pattern where one call generates and another evaluates and provides feedback |
| Critical path |
The longest dependency chain determining total duration in parallel work |
| Delegation contract |
A subagent's objective, output format, tool and source guidance, and boundaries |
| handoff |
A connection transferring execution control to another agent |
| agent-as-tool |
A connection calling another agent as a tool while retaining control |
| Code orchestration |
Defining agent flow in code to make execution more deterministic and predictable |
| Correlated errors |
Several agents using the same model or evidence making the same mistakes |
| ADR |
Architecture decision record: documents alternatives, measurements, selection reasons and reconsideration conditions |
| ACI |
Agent-computer interface: tools for agents and their descriptions and formats |
| Poka-yoke |
Designing inputs and formats to make mistakes difficult |
| Namespace |
Distinguishing tool names with service or resource prefixes |
| Preview and commit |
A tool structure that first calculates and displays changes, then executes only through a confirmed identifier |
| Idempotency |
Repeating the same request has the same effect as executing it once |
| Idempotency key |
An identifier recognizing repeated requests and ensuring their effect occurs once |
| MCP |
An open protocol connecting LLM applications with external data and tools |
| Host, client and server |
MCP's three roles: application, connector within it and service providing capabilities |
| Stateless protocol |
Each request contains all processing information and does not rely on earlier requests |
| State handle |
An explicit server-issued identifier pointing to state spanning calls; not a permission |
| MRTR |
The server requests additional input through an input_required result, and the client resends the original request |
| elicitation |
A server requests additional user information through the client; supports form and URL modes |
| Tasks extension |
An official extension providing durable task handles and status queries for long MCP tasks |
| Tool annotations |
Hints describing tool behavior; untrusted servers' annotations are not trusted |
| Token passthrough |
The prohibited pattern of forwarding received tokens to downstream APIs without validation |
| scope |
Actions permitted by a token; start minimal and escalate incrementally as needed |
| Progressive discovery |
Loading only needed tool definitions through search rather than preloading all of them |
| Programmatic tool calling |
The model writes tool-calling code, runs it in a sandbox and receives only final results |
| Context engineering |
Strategies for curating and maintaining the optimal token set seen by the model during inference |
| Context rot |
Declining ability to recall information accurately as context grows |
| Attention budget |
The model's finite capacity for attention, consumed incrementally by each token |
| Just-in-time retrieval |
Retaining lightweight identifiers and loading data when needed |
| Compaction |
Summarizing a conversation near the window limit and starting a new window |
| Tool result clearing |
The lightest compaction: removing old tool results that have served their purpose |
| Structured notes |
Records written outside context by an agent and reread later |
| Context pollution |
Incorrect, outdated or untrusted information accumulating and distorting judgment |
| System of record |
The authoritative system for business facts such as orders, transfers and approvals |
| Prompt caching |
Reusing processing of repeated prompt prefixes to reduce cost and latency |
| Checkpoint |
A durably stored stage result enabling resumption |
| Handoff package |
Documentation enabling the next executor to continue without a long conversation |
| Task and trial |
A test with input and success criteria, and one attempt at that test |
| Grader |
Logic scoring one aspect of agent performance |
| Transcript |
The complete trial record; also called a trace or trajectory |
| Outcome |
Final environment state after a trial |
| Trajectory evaluation |
Grading paths such as tool call order and arguments |
| pass@k / pass^k |
Probability of at least one success in k attempts / probability that all k succeed |
| Capability and regression evaluation |
Evaluation expanding the measured range of abilities / evaluation protecting previously working behavior |
| Saturation |
All solvable tasks in a suite pass, making further improvement invisible |
| Reference solution |
A solution confirmed to pass every grader, showing that the task is valid |
| Trace and span |
A complete workflow record and its constituent units of work with start and end times |
| Swiss cheese model |
Overlapping evaluation and observability layers because no single layer is perfect |
| Deadline |
Time allowed for the entire task, separate from stage timeouts |
| Exponential backoff and jitter |
Increasing retry intervals exponentially and adding randomness to prevent synchronized retries |
| Circuit breaker |
A protective mechanism blocking calls temporarily when downstream failures are high |
| Approval fatigue |
Review becoming a formality because there are too many approval requests |
| Approval binding |
Binding approval to execution arguments to prevent different content from executing |
| Guardrail |
A mechanism validating agent inputs, outputs or tool calls and able to stop execution |
| Sandbox |
An environment restricting program access to files, processes and networks at OS level |
| Prompt injection |
A vulnerability where input changes model behavior away from its intended purpose; direct or indirect |
| Excessive Agency |
Risk of harmful agent actions due to excessive functionality, permissions and autonomy |
| Rainbow deployment |
Running old and new versions together and gradually shifting traffic to protect active tasks |
| Complete mediation |
Downstream systems, rather than the LLM, checking authorization for every action |
| Denial of wallet |
An attack inducing excessive calls to drive up usage-based costs |
| Tripwire |
A signal triggered when a guardrail detects a violation; stops execution |
| Kill switch |
A mechanism immediately cutting off an agent or write tools |
| Compensating action |
An opposite action offsetting an effect that has already occurred |