Welcome: what agentic work actually means

What to understand

• An agent is a model wrapped in a loop. It reads context (your prompt, files, prior turns, tool output), proposes an action, takes that action (often only after your approval), observes the result, and repeats, until the goal is met or it stops to ask you. The model is the brain; the loop and its tools are what turn thinking into doing. This loop is the single idea the whole course is built on.
• The loop, not the model, is what makes it 'agentic'. The same underlying model can power a chatbot (one turn, no tools, no actions) or an agent (many turns, real tools, real side effects). What you are adopting in this course is not a smarter chatbot, it is a colleague that can reach into your environment and change it.
• OpenAI Codex and Claude Code are both agentic coding tools, and both are one engine reachable from many surfaces. Codex shows up as an App, IDE extension, CLI, Web/Cloud, GitHub integration, and a Chrome extension; Claude Code lives in the terminal, IDE, desktop app, and browser. Same agent, many front doors, you'll map this properly in Lesson 2.
• The single most important habit for a new user is read-only first. Ask the agent to explore, summarise, and propose a plan before you ever let it write, run, or push anything. A plan is cheap to inspect and free to throw away; a wrong action may be irreversible. Reviewing the plan first is where almost all of your safety leverage lives.
• Both products build the safety stance into explicit, named control surfaces, this is not folklore. Codex exposes approval policies and sandbox modes (its default for a version-controlled folder is the 'workspace-write' sandbox with 'on-request' approvals, so it can edit inside your workspace but must ask before leaving it or touching the network). Claude Code exposes permission modes you cycle with Shift+Tab, default (reads freely, asks before edits/commands), acceptEdits, plan (research and propose, no edits), auto, dontAsk, and bypassPermissions, and a set of 'protected paths' it will not write to without asking. You steer how much autonomy the agent has; it is a dial, not a switch.
• Agents are powerful precisely because they chain many small actions together, which is also their danger. A single vague instruction can fan out into a long sequence of edits, commands, and commits. The cost of an unclear prompt is therefore far higher than with a chatbot: you are not risking one bad paragraph, you are risking a cascade.
• Good agentic work is defined by stop conditions (also called red lines): situations you decide in advance must make the agent pause and check with you. Common picks are touching production, deleting files, spending money, pushing to a shared branch, and reaching the public internet. Naming these before you start is what separates a controlled session from a hopeful one.
• A reusable safety preamble turns your red lines into a habit. Instead of remembering to be careful each time, you paste a short standing instruction at the start of every session, work read-only first, explain the plan before acting, ask before anything irreversible. The agent treats a clearly stated boundary as a hard limit; making it a copy-paste artefact means you never forget it under time pressure.
• Treat the agent like a fast, capable, literal-minded junior colleague. Brilliant at execution and tirelessly thorough, but it has no instinct for what 'obviously' shouldn't be touched, no memory of last week's incident, and it will do exactly what you said rather than what you meant. Clear goals, explicit guardrails, and a review step before anything irreversible are how you get the upside without the blast radius.

Deeper dive

Plans & pricing compared

How the two coding agents expose the same safety idea, 'don't take irreversible actions without asking', through their own named controls. These are the dials you'll set in later lessons; the defaults below are for a normal version-controlled project folder. Control names and defaults change as both tools ship rapidly, verify at the official docs linked below before relying on them.

Sources (as of June 2026): Claude Code. Choose a permission mode · Codex. Agent approvals & security · Codex. Sandboxing

Step by step

1

Frame the loop in your head

Before opening any tool, write one sentence describing a real task you'd hand an agent this week (e.g. "summarise last month's support tickets into themes" or "rename a config field across this small repo and update its tests"). Underneath it, jot the four loop stages, read, propose, act, observe, and one concrete line of what each stage would look like for YOUR task. You're rehearsing how the agent will think, and finding the stage where a human review gate belongs. You are done when each of the four stages has one concrete line for your task and you can point at the exact stage where your review gate belongs.

HintIf you can't state the task in one sentence, the agent won't be able to either, tighten it before you tighten anything else. The fuzzier the goal, the wider the agent's action fan-out.

2

Open the Codex overview and find the safety controls

123

Go to developers.openai.com/codex and read the top of the page, then glance at the 'Agent approvals & security' and 'Sandbox' pages. Confirm three things: (a) Codex is one agentic tool reachable across App, IDE, CLI, Web/Cloud, GitHub, and Chrome; (b) it has named approval policies (on-request is the default, it asks before escalating); and (c) it has sandbox modes (workspace-write is the default, it can edit inside your workspace but must ask to leave it or reach the network). You're confirming that 'ask before irreversible' is a built-in dial, not something you bolt on.

HintDon't sign up or install anything yet, this lesson is deliberately read-only, which is also exactly the posture you're learning.

On this screen

1. 1Many front doors, one agent. The interface list (App, IDE, CLI, Web, GitHub, Chrome) is the same engine reachable from wherever you already work, not six separate products.
2. 2Safety is named, not implied. Approval policies and sandbox modes are explicit controls, the default 'workspace-write + on-request' means it edits in your workspace but asks before leaving it or going online.
3. 3You steer with goals. The phrasing about writing code from descriptions signals you direct it with plain-language intent and guardrails, not low-level commands.

3

Name your three red lines

In the same note, write three actions you never want an agent to take without explicitly asking you first. Strong picks are the irreversible ones: pushing to a shared branch, deleting or overwriting files, and sending anything to an external service or the public internet. For each, add one line on what the damage would be if it happened silently, that consequence is why it's a red line. You are done when each red line reads as a sentence you could paste to an agent verbatim, with its consequence written next to it.

HintPhrase each red line as something you'd actually type to the agent, e.g. "always ask before deleting or pushing". Set the gate by consequence, not by how confident the agent sounds.

4

Adopt the reusable safety preamble

Take the production safety preamble from this lesson, paste it into your note, and edit two things to make it yours: fold in the three red lines you just named, and trim any rule that doesn't apply to your work. Keep it tight enough that you (and the agent) can actually hold it in mind. This becomes the standing instruction you paste at the start of every session in every later lesson. Check it by reading it aloud: if you cannot summarise your own preamble in three lines, trim it, you are done when it fits on half a page.

HintA boundary the agent can re-read and act on beats a wall of rules it (or you) will skim. If a session runs very long, re-paste the critical red lines, old context can get trimmed.

Production prompt examples

STANDING INSTRUCTIONS, apply these to everything you do in this session, and keep applying them until I explicitly lift a specific rule.

ROLE: You are a careful senior engineer pairing with me. I am the human in the loop and I make the final call on anything that changes the outside world.

WORKING MODE:
1. Read-only first. Before writing, running, or changing anything, explore what you need and tell me, in 3-6 lines: what you understand the goal to be, the files/areas you looked at, and the plan you propose. Then STOP and wait for my go-ahead.
2. One step at a time for anything that changes state. After I approve the plan, make the smallest reasonable change, show me the diff or the exact command, and wait for approval before the next state-changing step.
3. Narrate before you act, not after. I should never be surprised by something you already did.

HARD RED LINES, never do any of these without first asking me in plain language and getting an explicit 'yes':
- Delete or overwrite files, or remove anything that isn't trivially recoverable.
- Run shell commands that install, build, deploy, migrate, or modify the system.
- Touch git history beyond local commits: no push, no force-push, no rebasing shared branches, no changing remotes.
- Send anything to an external service, an API, an email, or the public internet.
- Spend money or consume a paid quota in a way I haven't approved.
- Write to protected/config locations (e.g. .git, CI config, shell profiles, secrets).

WHEN IN DOUBT:
- If the task is ambiguous, ask ONE tight clarifying question instead of guessing.
- If you think a red line genuinely needs crossing to finish the task, stop and explain why, the risk, and the safest alternative, then let me decide.
- If you realise you've made a mistake, say so immediately and propose how to undo it.

OUTPUT STYLE: Be concise. Show plans as short bullet lists and changes as diffs or exact commands. Don't restate large files back to me.

Confirm you understand these standing instructions in one line, then ask me for the task.

Common mistakes to avoid

• Treating the agent like a search box and giving it a vague one-liner, then being surprised by the scope of changes it makes, vague goals fan out into long action chains.
• Letting the agent write or run things on first contact instead of asking it to explore and propose a plan you can inspect first.
• Trusting the agent's tone: it sounds equally confident when right and when wrong, so confidence is never a reason to skip a review gate on an irreversible action.
• Skipping stop conditions, so there's no agreed point where the agent must pause before doing something it can't undo.
• Assuming "undo" exists everywhere, pushes, deletions, external sends, and spend often can't be cleanly reversed.
• Running one of the fully-autonomous modes (Claude Code bypassPermissions / Codex danger-full-access) on your real machine to avoid prompts, instead of reserving it for an isolated container or VM.
• Relying on remembering to be careful each time, rather than pasting a written safety preamble that states the boundaries explicitly.

Source conflicts to review

• Control names and defaults for both tools change quickly (Codex separates approval policy from sandbox mode; Claude Code recently added auto and dontAsk modes). Names here are accurate as of June 2026, re-verify at the official docs and distrust tutorials more than a few weeks old.
• Secondary sources sometimes blur Codex's 'approval policy' (when it asks) with its 'sandbox mode' (what it can do); they are two independent dials. Prefer the official agent-approvals and sandboxing pages.