Continue Learning from the Source

Success condition, boundary, and stop condition are this course’s teaching terms. The ideas are supported by the sources; the phrases are ours, and the nearest source vocabulary is often narrower.

• Success condition. Anthropic observes that agents add the most value for tasks that have “clear success criteria,” which is the same instinct. Our term is about writing that criterion into the job so a human can check it.
• Boundary. OpenAI calls these guardrails and treats them as a layered defense that includes code and classifiers, not only instructions. Anthropic uses “guardrails” more narrowly, for a screening model running alongside the main one. Because the word means different things in the two guides, and because this module is specifically about limits written in ordinary language, the course says boundary and saves the stronger controls for later.
• Stop condition. Anthropic uses “stopping conditions,” but gives a mechanical example — a maximum number of iterations. OpenAI speaks of an “exit condition” that ends the loop, and separately of planning for human intervention so an agent can “gracefully transfer control when it can’t complete a task.” Our stop condition covers the judgment case rather than the iteration cap: Anthropic’s point that an agent must know “when to stop and ask for clarification when it’s uncertain” is the closest statement of what Module 2 means.

One further caution about Module 2’s advice against over-scripting. OpenAI’s guide recommends breaking tasks into small, explicit steps, because it is written for teams building production agents from existing operating procedures. That is a different problem from the one this module addresses. The principle both guides do share is restraint about complexity: find the simplest solution that works, and add more only when it earns its place.

Trace is course terminology and you should expect not to see it. Products say activity, history, log, or run details; the environment tested for Module 10 simply said “Worked for 30s.” The word is useful here precisely because it is generic.

Verification lines up with Stanford’s stated requirement that “all agent outputs and actions require verification proportional to impact.” Stanford gives the principle; the two-part split in Module 10 — check the content, and separately check the side effect — is this course’s framing.

Escalation overlaps with patterns all three sources describe: Stanford’s human escalation path, OpenAI’s human intervention with its transfer of control, and Anthropic’s checking in when judgment is needed. This course defines it more broadly than any one of them, to cover returning any decision the agent should not make alone.

There is no universal agent vocabulary here, and the course is not proposing one. For Module 10 in particular, the observed product behavior outranks anything in vendor documentation: where the two differ for the tested run, the page reports what was actually seen, on a stated date.

Prompt injection is the one term in this course that is genuinely standard vocabulary. Failure mode and recovery are ordinary engineering words used loosely here, not defined terms from any of these sources.

OpenAI’s user-facing explainer supplies the definition, the social-engineering framing, and the advice to limit an agent’s access to what a task needs and to review the details before confirming a consequential action. Two of its points shaped this module directly: that broad, open-ended instructions make it easier for hidden content to mislead a model — which is Module 2’s bounded job, arriving from the security side — and that its own guidance may not prevent every attack, which is why Module 9 calls a checkpoint one defense rather than proof.

Anthropic names prompt-injection attacks as attempts “to trick models into taking costly actions that they otherwise wouldn’t,” and separately notes that agents have more room to misread user intent and act with unintended consequences. Those are two different risks in one sentence, and Module 9 keeps them apart as Cases A and D.

Stanford lists prompt injection alongside tool hijacking, data poisoning, credential leakage, and supply chain risk. Module 9 teaches only the first and says so.

What this course deliberately omits. No attack strings appear anywhere, and nothing here will teach you to write one. OpenAI has published a more technical article on designing agents to resist prompt injection; its architectural point is close to Module 9’s section on capability, but it is not cited as a source here, because we could not read it — openai.com serves an automated block to every fetcher we have, and while the page resolves with the expected title in an ordinary browser, this course does not annotate sources it has not actually read.

Checkpoint, approval, and approval scope are this course’s vocabulary. The three sources all describe human decision points before consequential actions, and all three use different language for it. Collapsing them into one supposedly standard term would misrepresent the field.

• Stanford writes about human-in-the-loop controls and recommends requiring confirmation before external actions, listing sending messages, changing permissions, publishing content, running deletions, deploying code, and making purchases. It pairs this with dry-run modes and starting with small batches.
• OpenAI writes about human intervention, and describes a mechanism that lets an agent “gracefully transfer control when it can’t complete a task.” It names two triggers: exceeding failure thresholds, and “high-risk actions” that are “sensitive, irreversible, or have high stakes.” Those two triggers are why Module 8 treats being stuck and being about to act as different reasons for the same pause.
• Anthropic describes configurable permissions in its own products — per-action settings such as always allow, needs approval, or block — with the example of allowing calendar reading while still requiring approval before an invitation is sent. It also observes that when a task requires dozens of actions, repeated prompts become a source of friction and users sometimes tune them out, which is the tension Module 8’s section on approval scope is about.

Two of those are descriptions of particular products’ design choices rather than universal agent standards. Do not assume any given tool offers the same options, or the same labels.

All three current sources draw this line, and none of them draws it in Module 7’s words.

OpenAI separates tools that “retrieve context and information necessary for executing the workflow” from tools that “interact with systems to take actions such as adding new information to databases, updating records, or sending messages.” Its human-intervention guidance then singles out “high-risk actions” — “actions that are sensitive, irreversible, or have high stakes” — which is where this course’s interest in reversibility comes from. That guide also has a third tool category for agents used as tools by other agents; Module 7 leaves it out, because it is about orchestration rather than consequence.

Anthropic makes the same split concrete from the user’s side, describing per-action permissions and giving the example of deciding it is always fine for a model to read your calendar while still requiring approval before it sends someone an invitation. Same connection, two different answers, depending on whether the step changes anything for another person.

Stanford asks you to identify separately what an agent can read, what actions it can take, and where logs and outputs go — and advises choosing read-only access unless write access is genuinely needed. Its list of actions warranting confirmation is sending messages, changing permissions, publishing content, running deletions, deploying code, and making purchases.

Side effect and reversibility are teaching language here, not a taxonomy. “Side effect” is ordinary software usage rather than anything specific to agents. Stanford does maintain a formal risk-classification page for people who need to classify an agent institutionally, and it likewise distinguishes actions that are “not easily reversible or irreversible” — but Module 7 deliberately teaches the conceptual distinction rather than asking you to perform a classification, so it is not cited as a dependency here.

Both sources support the behavior Module 6 describes, and neither supplies its vocabulary.

Anthropic puts adjusts directly in its definition of the loop, and gives a worked example of a step going wrong: an expense submission is rejected, and rather than retrying blindly, the agent recognizes it does not know the relevant rule and pauses to ask before continuing, then “fold[s] what it learns into the plan and carr[ies] on.” Elsewhere the same post notes that an agent “will often encounter things its plan didn’t cover,” that it may resolve some of those gaps itself, and that others “will be questions of preference or intent that only the user can settle” — which is Module 6’s fallback-or-stop decision, stated from the other side.

OpenAI supports the same shape from the implementation side: an agent “recognizes when a workflow is complete and can proactively correct its actions if needed,” and “in case of failure, it can halt execution and transfer control back to the user.” Its tool selection depends on the current state rather than a fixed route, and its runs end at exit conditions.

Anthropic’s earlier engineering post adds the mechanism: agents should gain “ground truth” from the environment at each step to assess progress, and can “pause for human feedback at checkpoints or when encountering blockers.” It also lists “recovering from errors” among the capabilities that make agents viable at all.

Plan, adaptation, and fallback are this course’s teaching words. No source defines them in these senses. “Plan” is the one to watch: this course uses it for an observable proposed route, and the claim that a plan can be something you read and edit rather than hidden reasoning is grounded in real products — Anthropic describes a Claude Code mode in which the agent shows its intended plan up front and the user can review, edit, and approve it before anything runs. Module 6 keeps that product-neutral, but the idea is not hypothetical.

Module 5 describes one iteration as Choose → Act → Observe → Update. That is a teaching simplification, not standardized terminology, and no source phrases it that way.

Anthropic’s description is the closest: an agent “operates in a self-directed loop: it plans, acts, observes the result, adjusts, and repeats until the task is done or it needs to check in for human input.” We say Choose where that says plans, deliberately. “Plan” invites the idea that you could read the model’s internal deliberation, and this course sticks to what is observable from outside: a step was selected, an action happened, a result came back.

Of the three terms, run is the one with a firm source behind it. OpenAI’s guide says every orchestration approach needs the concept of a run, “typically implemented as a loop that lets agents operate until an exit condition is reached,” and gives common exit conditions as tool calls, a structured output, errors, or reaching a maximum number of turns.

Current state is nearly source language: OpenAI writes that an agent “dynamically selects the appropriate tools depending on the workflow’s current state.” Module 5 uses the phrase more broadly, to cover everything that bears on the next decision rather than only what drives tool choice. Iteration is this course’s own word; neither source uses it as a term.

This course defines context as the information available to the model when it decides what to do next. Anthropic’s engineering guidance is more precise: context is “the set of tokens included when sampling from a large-language model,” and context engineering is “the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference.”

A token is the unit a model actually reads — roughly a word or a piece of one. The technical definition is the accurate one, and if you go on to build these systems it is the one you will need. Module 3 avoids it because counting tokens is a different skill from deciding what belongs in a task, and because published limits change faster than any tutorial can track.

Two ideas from that post are worth having in the original. The first is that context must be treated as “a finite resource with diminishing marginal returns” — not merely finite, but subject to the observation that a model’s ability to accurately recall information decreases as the amount grows. The second is the goal: “finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome.” That is Module 3’s “relevance beats accumulation,” stated exactly.

The same post also names the failure modes at both ends of Module 2’s comparison, calling the space between them “the right altitude”: at one extreme, hardcoding brittle logic to force exact behavior; at the other, guidance so vague it gives no real direction.

The two companies do not share this vocabulary. “Context engineering” is Anthropic’s term. OpenAI’s guidance for teams reaches the overlapping practical advice — share the context, expectations, and structure behind a task — without using it.

If you read both engineering guides, you will hit an inconsistency worth knowing about in advance.

Anthropic treats workflow and agent as two alternative architectures: a workflow runs a predefined path, and an agent directs its own. That is the contrast this module teaches.

OpenAI uses “workflow” to mean the sequence of steps needed to meet the user’s goal, and describes an agent as a system that executes a workflow by having the model manage that execution.

The two are describing the same distinction from different angles, and both agree on the substance: what makes something an agent is that the model, rather than a predetermined script, controls how the work proceeds. Only the noun moves. This is a good illustration of why this course states its working definitions rather than claiming an official one.