A mission from start to delivery

The previous lessons gave you the loop, the three words and the eight dimensions. This one puts them in motion on a single feature, the way the capstone of the course will.

The mission

Suppose AgenticShop has a Shopping Cart module. It does not yet, you build it in module 3, but the walkthrough reads better on a feature that sits on top of something. The mission is this.

Add a percentage discount to the ShoppingCart module.
A cart can carry one discount, between 1 and 50 percent.
The subtotal is unchanged. A new `total` applies the discount to it.
Tests cover the bounds and the arithmetic. Nothing outside Packages/ShoppingCart changes.

A capable environment takes a mission like this through seven stages. The stages are a way of reading what happens. No tool shows them as a menu.

Stage by stage

Understand

The agent reads Package.swift and learns that ShoppingCart depends on Catalog and nothing else. It reads Cart.swift, finds Money built on Decimal, and reads the existing tests to see that they use Swift Testing and name tests after requirement identifiers. Repository intelligence and context engineering decide how much of this it finds on its own.

Plan

It lists what will change. A Discount type with a validated percentage, a discount property on Cart, a total computed from the subtotal, and one test per requirement. It notes that Checkout reads the cart and could be affected, and that the mission forbids touching it.

Authorize

Before anything is written, the environment checks the plan against its policies. Writing under Packages/ShoppingCart is allowed. Writing under Packages/Checkout is not. Running swift test is allowed without asking. Pushing a branch would require a person. In Claude Code these are permission rules. The words differ in Codex, and the question is the same.

Execute

The agent writes the type, the property, the computed total and the tests, with the tools it is allowed to use.

Validate

It builds and tests the package. If the build fails, the compiler’s message comes back as feedback and the agent diagnoses and corrects within its scope. If a test fails, the same. This is the loop from the previous lesson, repeated until the checks pass or the agent runs out of ideas and says so.

Evaluate

With green tests, the agent compares the result with the acceptance criteria. Bounds covered, arithmetic covered, subtotal unchanged, no file outside the module. It runs the tests of Checkout as well, since that module reads the cart, and reports whether they still pass.

Deliver

It hands back a summary, the list of changed files, the output of the build and tests, what it chose not to do, and the risks it sees. A delivery without evidence is a claim. A delivery with evidence is something you can review in five minutes.

What a failure must not become

If compilation fails at the validate stage, the correct outcome is a return to execute, inside the authorized scope, or an honest stop. The incorrect outcome is a summary that says the feature is done because the code looks plausible.

An environment that lets the second happen has a gap in dimension 6, feedback and validation. Either the check did not run, or its result never reached the agent, or nothing required the result to be green before delivery. Module 5 closes all three.

A rule is not proof

A configuration file that says the agent may not modify a protected directory is a statement of intent. It is not evidence that the control works. Rules get misspelled, settings files get overridden by another settings file, and a tool update changes what a key means.

Assessment tests behavior. If a policy protects Packages/Checkout, the assessment includes a run where the agent is asked to change a file there, and the record shows the execution layer refusing. The same goes for every dimension. The evidence column of the previous lesson is a list of behaviors to observe, not files to check for.

Module 6 turns this into an exercise. You will plant a hostile instruction in the repository and protect a secret file, then prove both protections with runs.

The same parts, two products

The eight dimensions exist in every coding agent product. The names differ. This table was written in November 2026 from the documentation of the two tools, and both change often, so check the current pages before relying on a detail.

Need	Claude Code	Codex
Project instructions the agent reads at startup	CLAUDE.md files	AGENTS.md files
Connecting your own tools	MCP servers	MCP servers
Control over actions	Permission rules and modes	Approval modes
Isolation of commands	Sandboxing	Sandbox

The names matter less than the questions. Whatever tool you use, you should be able to say where its instructions come from, how you add a tool, what it may do without asking and what its commands can reach. When a product renames a setting, the dimension it belongs to has not moved.

Sources

• Claude Code documentation, Anthropic. Instruction files, permissions, sandboxing and MCP.
• Codex documentation, OpenAI. Approvals, sandbox and MCP.