Glossary
66 terms from “Agent Harness Fundamentals: Loops and Control.” Hover the first occurrence in the lesson for its definition.
| Term | Definition | Source |
|---|---|---|
| harness | The collective name for the control code wrapped around the model — running tools, driving the loop, deciding when to stop and when to wait for a person. The model only proposes actions; the harness rules on whether they execute and whether the loop continues. | How tool use works — Claude API |
| Agent | An LLM using tools based on environmental feedback in a loop. The model dynamically directs its own process and decides which tools to use inside the loop, rather than following predefined code paths. | Building Effective AI Agents — Anthropic Engineering |
| workflow | A system where LLMs and tools are orchestrated through predefined code paths — what to do first, which branch to take are all settled in advance by a person. | Building Effective AI Agents — Anthropic Engineering |
| loop | The repeated process of model proposes → execute tools → feed result back to model. A single tool-call round-trip is just the special case where the loop turned once. | Building Effective AI Agents — Anthropic Engineering |
| control-flow decisions | Judgments about 'which path to take next.' In workflows they're hard-coded; in agents the model makes them dynamically inside the loop — this is the boundary between the two. | The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) |
| loop control | The while loop driving model→tools→model, reading stop_reason to decide whether to turn another round or stop. It's the heart of the harness. | The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) |
| tool dispatch | After the model proposes 'call this tool with these parameters,' the code that routes the request to the real function, runs it, and packs the output back into a tool_result. | The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) |
| context management | The harness component managing loop-produced history — deciding where it goes, how much to keep, how to compress or summarize, preventing context from ballooning until attention budget is exhausted. | The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) |
| proposing an action | The model's sole job on each turn — looking at the current conversation and emitting a structured request for 'what I want to do next,' without ever executing it. | How tool use works — Claude API |
| approval valve | A pause inserted before executing a tool marked high-impact, showing a human 'here's what I'm about to do' and executing only on a nod, returning is_error on refusal. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| round-trip | One complete tool-call cycle: model returns tool_use, host executes the tool, packages tool_result, appends to conversation, and sends another request. The loop is just repeating round-trips. | How tool use works — Claude API |
| environmental feedback | The tool execution result fed back to the model as input. The model decides its next step based on this feedback — it's the fuel that drives the loop forward. | Building Effective AI Agents — Anthropic Engineering |
| autonomy | The agent's property of dynamically deciding its own next step and which tool to use. It's why agents are useful, and it also means higher costs and compounding-error risk. | Building Effective AI Agents — Anthropic Engineering |
| while loop | A while structure with stop_reason as its condition, turning a single round-trip into code: while stop_reason is still tool_use, turn another round. | The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) |
| four steps | The fixed sequence connecting round-trips into a loop: send request → read stop_reason and tool_use blocks → execute tools and package tool_result → append history and send again. | How tool use works — Claude API |
| stop_reason | The field in the model's response indicating why it stopped: tool_use means it wants a tool and the loop continues, end_turn means it's wrapping up and the loop ends. | How tool use works — Claude API |
| tool_use | A content block the model emits to request a tool call, carrying id / name / input. It means the model wants to use a tool, not that one has been used. | How tool use works — Claude API |
| tool_result | A content block packaging tool execution output back to the model, carrying tool_use_id to claim which call it answers, content for the output, and is_error when it failed. | Handle tool calls — Claude API |
| end_turn | A stop_reason value meaning the model no longer wants tools and thinks it's finished talking. The loop ends naturally and returns final text to the user. | How tool use works — Claude API |
| tool_use_id | The field in tool_result claiming 'this is the response to which tool_use call,' identified by matching the tool_use block's id. Multiple tools in one turn rely on this for one-to-one correspondence. | Handle tool calls — Claude API |
| is_error | An optional field on tool_result, set to true when tool execution failed, so the model knows this call didn't succeed and can retry with different arguments or take another path. | Handle tool calls — Claude API |
| callModel | The pseudocode call in skeleton loops representing 'send a request to the model.' Real implementations swap it for SDK's client.messages.create. | How tool use works — Claude API |
| executeTool | The call in skeleton loops representing 'the host actually goes and runs the tool the model named.' The action happens at this step, not when tool_use arrived. | How tool use works — Claude API |
| attention budget | The model's finite resource for parsing context. Every new token depletes it; the longer the context, the worse the model's ability to accurately recall information from it. | Effective context engineering for AI agents — Anthropic Engineering |
| stopping conditions | Explicit rules the host enforces — like maximum number of iterations — that stop the loop independently of the model's own end_turn, keeping control on your side. | Building Effective AI Agents — Anthropic Engineering |
| max turns | The most basic hard stop condition: a ceiling on how many times the loop is allowed to go around, stopping at the mark regardless of what the model wants. | Building Effective AI Agents — Anthropic Engineering |
| hard stop | A stop condition that halts unconditionally at the boundary and ends the loop for good — nothing continues automatically. Max turns and budget exhaustion both fall here. It's a terminal state. | Building Effective AI Agents — Anthropic Engineering |
| soft stop | A resumable pause where the loop deliberately halts at a checkpoint, hands control to a person, and can pick up from that exact spot once they answer. It's not an ending. | Building Effective AI Agents — Anthropic Engineering |
| counter | A variable maintained outside the loop, accumulating across rounds, recording how many laps the loop has turned. It's what makes the max-turns gate able to judge. | Building Effective AI Agents — Anthropic Engineering |
| checkpoints | Pause points set at nodes in the chain where 'if this is wrong, everything after is wasted,' letting the loop surface intermediate state for verification or await human feedback. | Building Effective AI Agents — Anthropic Engineering |
| needsHumanApproval | A predicate in soft-stop examples judging 'does the next action need a person's sign-off first?' When it matches, the loop suspends and hands over the scene awaiting human response. | Building Effective AI Agents — Anthropic Engineering |
| task is done | The softest of the four stop conditions — the model judges it finished and returns end_turn. Decision authority sits with the model, but you still must confirm it really finished rather than gave up partway. | Building Effective AI Agents — Anthropic Engineering |
| snapshot | The resumable state handed over at soft-stop pause — current messages plus the pending action that stalled, packaged together so a person can pick up from that exact spot after handling it. | Building Effective AI Agents — Anthropic Engineering |
| over-engineering | Piling on mechanisms when complexity doesn't demonstrably improve outcomes. Should only add complexity when it clearly improves results — but stop conditions like max turns are low-cost high-return control, not this category. | Building Effective AI Agents — Anthropic Engineering |
| compounding errors | One wrong step followed by every subsequent turn continuing atop the mistake and amplifying the bias. No exceptions thrown, each step looks reasonable, but errors compound like interest down the chain. | Building Effective AI Agents — Anthropic Engineering |
| context bloat | Every loop turn stuffs two messages into history, add-only never-subtract, so each request carries progressively longer context. Requests get slower and more expensive. | Effective context engineering for AI agents — Anthropic Engineering |
| context rot | As context lengthens, key information drowns in noise and the model 'can see it but can't grab it' — recall degrades on a gentle slope with length, not a sudden cliff. | Effective context engineering for AI agents — Anthropic Engineering |
| dead loop | A mechanical fault where host code is wrong (like forgetting to reassign response at loop-body end), so stop_reason stays frozen at the old value, while is permanently true, and the process hangs. | How tool use works — Claude API |
| idle spinning | Code is entirely correct, loop legitimately sends requests and executes tools each turn, yet no new progress is made — like calling the same tool repeatedly getting near-identical empty results. | Building Effective AI Agents — Anthropic Engineering |
| no-progress detection | A hard gate built for idle spinning: host watches 'is anything new happening,' and if N consecutive turns call the same tool returning nearly-identical output, judge it no-progress and break out. | Building Effective AI Agents — Anthropic Engineering |
| budget cap | An explicit cost ceiling set for the loop, counted by turns or by tokens (money). Hit the ceiling and stop; lightweight by turns or closer to real cost by token. | Building Effective AI Agents — Anthropic Engineering |
| budget burnout | Turn count times per-turn context multiply to drive cost out of control. An agent stuck spinning can burn serious API spend overnight while accomplishing nothing. | Building Effective AI Agents — Anthropic Engineering |
| context governance | Actively managing loop-produced history as a fallback — compressing old turns, summarizing early results, dropping irrelevant intermediate artifacts, putting a brake on per-turn cost. | Effective context engineering for AI agents — Anthropic Engineering |
| early stopping | Stopping an already-drifted loop the moment something looks off, rather than letting it burn through the full budget. Works with checkpoints to cut error off while still small. | Building Effective AI Agents — Anthropic Engineering |
| diminishing marginal returns | The property of context as a finite resource — each additional piece of history brings progressively less value. So every chunk of history should justify 'is this still worth it.' | Effective context engineering for AI agents — Anthropic Engineering |
| excessive agency | The vulnerability where damaging actions get performed in response to unexpected, ambiguous, or manipulated LLM outputs — regardless of what caused the malfunction. When the model is wired to real authority, bad output can trigger destruction. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| interrupt | The bluntest of the three human interventions — regardless of what the model wants to do this turn, the entire loop terminates and no further request goes out. After interrupt there's no 'then what.' | Building Effective AI Agents — Anthropic Engineering |
| steer | Pushing a fresh human message into the conversation, changing what the model leans into next, while the loop keeps running with the new instruction. Steer changes direction, not whether the loop lives. | Building Effective AI Agents — Anthropic Engineering |
| approve | Intervention on one specific high-impact action — the loop reaches it, stops, shows 'here's what I'm about to do,' and executes only if a person says yes; skipping or canceling on no. After approval the loop resumes its rhythm. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| human-in-the-loop | Control where a human gets the chance to say 'hold on' at a few critical points before irreversible actions land, rather than only seeing logs afterward. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| human gate | A manual checkpoint beyond the harness's own automatic gates, guarding the few 'if done wrong, can't take back' spots where automation's trust needs a person's live judgment. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| irreversible | Actions that can't be undone in one step, or can only be undone at enormous cost (drop database, transfer money, publish externally, change production config). Approval gates must come before these. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| blast radius | A measure of an operation's impact-range and irreversibility when it goes wrong. Larger blast radius means gate the confirmation point earlier. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| counterfactual test | A self-check to judge reversibility: if this action ran and was wrong, can I undo it in one step at low cost? If not, the gate must go early. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| askHuman | The call inside approval valve that requests a release decision from a person. In a terminal it means 'print the pending action, read one line of input.' Must complete before executeTool. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| @anthropic-ai/sdk | The official Node SDK. Use it to replace skeleton pseudocode callModel with real client.messages.create, driving the same stop_reason loop. | How tool use works — Claude API |
| client.messages.create | The SDK method that sends a model request, taking model / max_tokens / tools / messages. It's the real-world replacement for callModel in the loop. | How tool use works — Claude API |
| runToolUses | A function that takes this turn's tool_use blocks, actually runs each one, and packages each into a tool_result. Approval valve and try/catch both live inside it. | Handle tool calls — Claude API |
| runAgent | The entry function carrying the whole harness loop, wiring messages, four control valves, request sending, and tool execution together until stop_reason is no longer tool_use. | How tool use works — Claude API |
| signatureOf | A no-progress-detection signature function — concatenates this turn's tool_use names and parameters into one string, used to compare against the previous turn and detect spinning. | Building Effective AI Agents — Anthropic Engineering |
| response.usage | The field in model responses reporting token consumption this turn (input_tokens + output_tokens). Basis for budget caps counted in tokens. | Building Effective AI Agents — Anthropic Engineering |
| input_schema | The JSON schema in a tool definition describing input structure. The model constructs tool_use input to match, making parameters conform to tool requirements. | Handle tool calls — Claude API |
| try/catch | The error-tolerance wrapper around tool execution — when it throws, don't crash the harness, package the error as an is_error tool_result and pass it back, giving the model a chance to retry or pivot. | Handle tool calls — Claude API |
| control valves | The collective name for control mechanisms welded into the loop, each guarding one spot — max turns, budget cap, no-progress detection, and high-impact-action approval. Positions aren't arbitrary. | The 2026 Agent Engineering Roadmap — GitHub (codejunkie99/agent-roadmap-2026) |
| policy valve | A generalization of approval valve — routing tools by name into allow (straight through), ask (confirm before execution), deny (always refused) tiers, judged before executeTool. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |
| high-impact | Actions producing externally-visible or irreversible consequences (write_file, http_post, delete_file). Only gate approval on these; harmless reads and queries go straight through. | LLM06:2025 Excessive Agency — OWASP Gen AI Security Project |