# Glossary

Canonical: https://loopmaster-ai.pages.dev/learn/glossary

Use this glossary when you write a loop plan or ask an agent to review one. Loopmaster vocabulary is normative for this site; vendor terms are descriptive mappings to the cited docs, not claims that Anthropic or OpenAI use Loopmaster's taxonomy.

## Core terms

| Term | Meaning | Often confused with |
|---|---|---|
| Prompt | One instruction or input to a model. It can describe a job, but it does not repeat work by itself. | Loop. |
| Scheduled prompt | The same prompt re-run on a timer. The timer repeats the prompt, but each run may be amnesiac, ungraded, and unaware of done. | Loop or automation. |
| Automation | Work that runs without a human's hands at the moment of execution. Scripts, zaps, workflows, scheduled prompts, and loops can all be automations. | Loop. |
| Trigger | The time, event, webhook, command, or human request that starts one pass. | Loop or schedule. |
| Schedule | A time-based trigger. It can wake a loop, but it is not the loop. | Loop. |
| Workflow | A predefined path through steps. A workflow may contain loops, but it does not have to let an agent choose the next action. | Agent loop. |
| Agent workflow | A workflow where some steps are performed by a model. The model fills in steps inside a predefined path; it does not own the outer continue-or-stop structure. | Agent loop. |
| Loop | Repeated passes with carried state, explicit checks, a stop or escalation rule, and a harness or runner that owns repetition. | Prompt or trigger. |
| Agent loop | The Loopmaster loop pattern with agency inside the pass: an agent observes state, chooses actions, uses tools, checks results, and stops or escalates. | Workflow. |
| Autonomous system | One or more loops granted standing permission to act within bounds without per-action approval. Autonomy is a permission property, not a control structure. | Loop or unattended automation. |
| Harness/runtime | The system that owns repetition: model calls, tool execution, state, logs, limits, approvals, and termination. | Model or prompt. |
| State | The umbrella term for what a loop can use across time: transient context, durable working state, and cross-run memory. | Context window. |
| Check | The proof that work succeeded: tests, source URLs, file existence, screenshots, reviewer approval, or another explicit signal; checks succeed or go green, never "the pass passed." | Agent confidence. |
| Stop rule | The condition that ends or pauses the loop on purpose; Loopmaster names exactly four terminal stops: done, blocked, exhausted, and interrupted. | Error handling. |
| Approval gate | A required human pause before public, destructive, expensive, credential, production, or otherwise risky actions. | Notification. |
| Log/artifact | The durable record a human or later agent can inspect: transcript, report, pull request, screenshot, saved state, or summary. | Final answer. |
| Runner | A concrete implementation of the harness, such as a native agent mode, scheduled task, cron job, queue worker, workflow, or script. | Trigger. |

## Units of execution

Loopmaster's smallest-to-largest execution chain is: action inside turn, turn usually inside pass, and pass inside run. A pass usually contains one turn, but a harness may group several turns under one pass-level check.

| Term | Meaning | Example |
|---|---|---|
| Action | One tool call or externally visible operation, such as a command, file edit, search, or API request. | Running `npm test` once is an action. |
| Turn | One top-level unit of agent work that starts from a user or harness directive and ends when the agent yields a result or question. | A Codex turn can start with "fix the failing auth test," run several tool calls, and end with an assistant message summarizing the change. |
| Pass | One traversal of a loop: load state, work, check, record, then choose the next verdict. | A docs freshness loop reads the source list, updates one stale entry, records evidence, and writes a pass-log entry. |
| Run | One lifecycle of a loop under one contract and one budget, from start to a terminal stop. | A three-pass link-audit run starts from a contract and ends done, blocked, exhausted, or interrupted. |
| Verdict | The recorded outcome at a pass boundary: continue, done, blocked, exhausted, or interrupted. | A pass log can record `continue` after fixing two links when three unchecked links remain. |
| Iteration | Non-normative and ambiguous: it means one repetition of whichever cycle the author is discussing, not a Loopmaster unit. | OpenAI's Codex agent-loop article uses iteration for model-inference-to-tool-call cycles inside a turn, while the Codex Goals guide uses iteration policy for deciding what to try next after each attempt. |

## State: three kinds, three lifespans

| Term | Meaning | Example |
|---|---|---|
| Context | The transient working material inside a session: messages, tool output, loaded files, and model working context. | A test failure pasted into the current conversation is context. |
| Working state | Durable per-run files that let the next pass rebuild where the run stands. | A task contract, checklist, pass log, and git history are working state for a multi-pass run. |
| Memory | Cross-run knowledge deliberately kept to shape future work. | `AGENTS.md`, a decision record, or this glossary can be memory when future agents read it before acting. |

Context answers "what am I doing right now," working state answers "where am I in this run," and memory answers "what should change every future run."

## Contracts, budgets, and stops

Every run ends in exactly one terminal stop. `continue` is a pass verdict, not a terminal stop.

| Term | Meaning | Example |
|---|---|---|
| Contract | The written operating agreement for a loop: target, check, budget, state, constraints, and blocked rule. | A `task-contract.yaml` can say "make `npm test -- auth` exit 0 without deleting tests." |
| Check | The proof that work succeeded, preferably automated and specific enough that the loop cannot talk itself into being done. | A release-note loop can check that `npm run build` exits 0 and the changed page contains the new version number. |
| Budget | The run's fuse, usually expressed in passes, time, tokens, spend, or a combination. | A bug-fix loop can stop after three passes or thirty minutes, whichever comes first. |
| Pass log | The durable per-pass record of what state was read, what happened, what check ran, what evidence exists, and what verdict was recorded. | A pass-log entry can link the CI run, list files changed, and record `done`. |
| Done | The terminal stop where the check succeeds with evidence. | A quick-start run is done when the promised command exits 0 and the evidence is recorded. |
| Blocked | The terminal stop where the loop needs input and stops with a specific question and what it learned. | A release loop is blocked when signing credentials are missing and it asks for the exact credential or approval needed. |
| Exhausted | The terminal stop where the budget is spent before the check succeeds. | A flaky-test loop is exhausted after three attempts if the failure remains and the contract allowed only three passes. |
| Interrupted | The terminal stop where a human or outer system stops the run before another terminal stop fires. | A user pressing Ctrl+C during a non-interactive goal run interrupts it. |

Blocked is a success mode, not an error: stop-and-ask beats guess-and-drift.

## Layers (Loopmaster taxonomy)

Task loop, goal loop, and steering loop are Loopmaster's own taxonomy, not Anthropic or OpenAI vocabulary. A layer name applies only to work that already qualifies as a loop under the five-part test; defining a layer is not the same as claiming Loopmaster operates that layer.

| Term | Meaning | Example |
|---|---|---|
| Task loop | A loop that varies actions until one task's check succeeds or a terminal stop fires. | A coding agent edits files, runs tests, reads failures, and edits again until the auth test is green or the run stops blocked or exhausted. |
| Goal loop | A loop that varies tasks until the goal's stopping condition is met, blocked, exhausted, or interrupted. | A milestone loop chooses one task loop, waits for its verified result, then chooses the next task until the feature is complete. |
| Steering loop | A loop that varies goals by watching world state and deciding what goal loops should pursue next. | A weekly product-maintenance loop could review usage, breakage, and landscape changes to re-aim the next goal contracts; Loopmaster does not claim to run one without a checked steering-loop pass log. |

## Vendor term map

Checked 2026-07-10. This map is descriptive, not an endorsement claim: when a vendor doc says the cited thing, Loopmaster maps it to the nearest Loopmaster term. "Closest analogue" means the vendor does not define the Loopmaster unit directly.

| Loopmaster | Claude Code (Anthropic) | Codex (OpenAI) | Sources |
|---|---|---|---|
| Action | Tool use or tool call; Anthropic's agent framing has agents dynamically directing their own tool usage. | A tool call requested by the model and executed by the Codex harness before its output is appended for the next model query. | [S5], [S2] |
| Turn | A `/goal` turn is followed by a small fast model check; if the condition is unmet, Claude starts another turn. | One conversation turn runs from user input to assistant message, and may include many model-inference to tool-call iterations. | [S1], [S2] |
| Pass | Closest analogue: one `/goal` after-turn completion-check cycle, one timed `/loop` firing, or one Stop-hook evaluation. | Closest analogue: one attempt under an active Goal, with the iteration policy deciding what to try next after each attempt. | [S1], [S3] |
| Run | A `/goal` lifecycle from activation until the condition is met, a turn/time bound is reached, `/goal clear` is used, or the process is interrupted. | A Goal's thread-scoped lifecycle as a completion contract that may end in success, pause or clear, interruption, budget limit, or a blocker requiring input. | [S1], [S3] |
| Check | The goal's completion condition, checked after each turn by an evaluator that judges what Claude surfaced and does not call tools. | The Goal's verification surface; completion must be evidence-based against files, tests, logs, benchmark output, generated artifacts, or other concrete evidence. | [S1], [S3] |
| Budget | A `/goal` condition can include a turn or time clause to bound how long it runs. | A Goal carries budget accounting; reaching the budget limit is not completion. | [S1], [S3] |
| Blocked stop | Anthropic's autonomy research observes Claude Code pausing to ask for clarification as an agent-initiated form of oversight; the `/goal` doc does not define a separate blocked state. | Codex Goals can stop on a blocker requiring user input, and strong Goals should define a blocked stop condition. | [S7], [S3] |
| Working state | Long-running Claude agent harnesses use progress files and git history to bridge sessions that start with no memory. | Closest analogue: Codex manages a growing thread context and context window, and Goals persist as thread-scoped state rather than global memory. | [S6], [S2], [S3] |
| Memory / instructions | The cited Claude sources define no Claude Code memory-file equivalent; Anthropic's long-running-agent guidance keeps cross-session knowledge in progress files and git history. | Codex reads and layers `AGENTS.md` instruction files before work. | [S6], [S4] |

Task loop, goal loop, and steering loop are intentionally absent from this vendor map: they are Loopmaster taxonomy, not Anthropic or OpenAI vocabulary.

## Sources

1. [Anthropic Claude Code docs — Keep Claude working toward a goal](https://docs.anthropic.com/en/docs/claude-code/goal)
2. [OpenAI — Unrolling the Codex agent loop](https://openai.com/index/unrolling-the-codex-agent-loop/)
3. [OpenAI Developers — Using Goals in Codex](https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex)
4. [OpenAI Developers — Custom instructions with AGENTS.md](https://developers.openai.com/codex/guides/agents-md)
5. [Anthropic — Building effective agents](https://www.anthropic.com/research/building-effective-agents)
6. [Anthropic — Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
7. [Anthropic — Measuring AI agent autonomy in practice](https://www.anthropic.com/research/measuring-agent-autonomy)