The Designer–Agent Loop

Module 1 ended with the loop diagram: brief, plan, review gate, generate, critique, revise, ship. This module takes that diagram and runs it at working speed. The risk with a diagram is that it stays a diagram — people nod at it and then go back to typing one-line requests. The goal here is to make each box concrete enough that participants can picture what they would actually be doing at 10:14 on a Tuesday.

Set the frame early: this is a rhythm, not a ceremony. A full loop on a bounded task is twenty to forty minutes, most of which is the agent working while the designer does something else. The two gates — the plan review and the critique — are minutes each. If the loop in someone's head feels like a process document with sign-offs, they have the wrong picture, and they will skip it the first time they are busy.

Flag what this module does not cover. It does not teach how to write the brief in detail — that is Module 3 — and it does not cover the harness that makes the loop repeatable across sessions, which is Module 4. Here the brief and harness are treated as inputs that exist; the focus is on what happens between them and the ship decision.

This mental model comes straight from the school's briefing article: treat the agent like a fast design partner with weak taste memory. Each property on the slide has a practical consequence. Fast means the cost of a wrong run is low — minutes, not days — which is why showing early and iterating small works. Literal means the gap between what you said and what you meant is the agent's whole world; it cannot read the product's politics, the reason the screen exists, or the level of polish a stakeholder review needs. No taste memory is the one designers underestimate most: the correction you made yesterday does not exist today unless it was written into the harness or the brief, so the same generic pattern will come back.

Eager is the property that makes the gates necessary rather than nice. Given a vague request, the agent fills the gaps with the most common pattern it has seen — oversized hero, rounded cards, marketing copy — and presents it confidently. It will rarely stop and ask whether that is what you wanted unless the brief explicitly makes the questions part of the deliverable.

The junior-designer framing also sets the right tone for the relationship. You do not abdicate to a junior, and you do not micromanage every keystroke either. You brief them, you review their plan, you critique their work against criteria you stated up front, and you decide what ships. That is the loop, described as management rather than as process.

Keep this slide at the level of what the step produces, because Module 3 spends a full session on how to write it well. The brief is a written artifact — usually under a page — that carries everything specific to this task: the user job, the audience, the direction for this surface, the constraints that bite here, the output shape, and the review criteria. It explicitly does not restate the design system; durable rules live in the harness, and the brief points at them.

The two-jobs framing from the briefing article is worth saying out loud: facts and standards. Facts are what the agent needs to work inside the project — which page, which components, which tokens, which files. Standards are what it must use to judge its own output — what counts as a bad answer, what the review will check, which anti-patterns are off the table. Most weak briefs supply some facts and no standards, which is why the output looks plausible and fails review.

The last bullet is the bridge to the next two slides. Ending the brief with plan first and a request to restate the task is what turns the brief into the start of a loop rather than a fire-and-forget request. The restatement alone catches a surprising share of misunderstandings, because the agent has to show you what it thinks the job is before it spends any time on it.

The point of this slide is that the review gate from Module 1 is not a discipline you have to maintain by willpower. Every major CLI agent now ships a mode that keeps the session read-only until the plan is approved: Claude Code's plan mode is a permission mode, Codex CLI documents a plan mode plus the PLANS.md pattern of keeping the plan as a reviewable file, OpenCode makes planning a separate read-only agent role, and Gemini CLI's Plan Mode requires explicit approval of the finished plan. The capability is stable even though entry points and shortcuts change; the school's briefing article keeps the documentation links current.

What the designer reviews at this gate is also worth restating, because it is the cheapest correction point in the whole loop. A good plan restates the user job in a sentence, names the sections and hierarchy, names the components it will reuse, lists the states and checks, and surfaces assumptions and contradictions. You are not reviewing code — there is none. You are reviewing the agent's judgment about structure and intent before that judgment becomes work.

Give the honest caveat early: a plan previews judgment, it does not bind the implementation. In the field-notes run from Module 1, the approved plan named the right components and the implementation still invented a prop the component does not have. The type check caught it, not the plan. That is why the loop has a second gate.

Generation is the step people picture when they imagine agentic work, and it is the step where the designer does the least. The skill is in the setup. The first decision is scope: one run should produce one bounded outcome you could name in a sentence — the anatomy strip for the field-notes page, the empty state for the upload flow, an audit of the settings forms. Runs scoped to redesign the dashboard produce sprawling changes that nobody can review honestly, and the review gate quietly dies because reading the whole diff is too expensive.

The second decision is where the output lands. Scratch branches and scratch folders are not bureaucracy; they are what makes the rest of the loop honest. If the work lands somewhere disposable, critique can be ruthless and a bad run costs nothing but the minutes it took. In the field-notes case study, both runs were written to a scratch folder and deleted afterwards — whether the strip ever ships is an editorial decision, not a by-product of running the loop.

The last bullet about reusing existing components is the single highest-leverage constraint you can put on a generation run, and it usually lives in the harness rather than the brief. An agent told nothing will build new primitives; an agent pointed at SectionBand, SectionHeading, and the token file will mostly stay inside them. When it does not, the audit catches it — which is the next step.

This step gets a full module later in the course, so keep it to the working shape. Critique starts from the review criteria the brief stated before anything was generated — that is the critique contract. Asking an agent for general feedback gets you general taste language: clean, modern, needs polish. Asking it to inspect the artifact against a named user job, with screenshots and the design files as evidence, gets you findings you can act on.

The order matters. Executable checks run first because they are free and unambiguous: the token audit, the type check, the project's verify script. In the field-notes runs, those checks did real work — the audit caught ten hardcoded colours in the weak run, the type check caught the invented prop in the briefed run. Then comes the evidence-based review: screenshots at desktop and mobile widths, with content lengths that are realistic rather than convenient. Then the human judgment that no check covers: does the hierarchy read in the right order, does the copy hold the product's voice, does the section actually serve the job the brief named.

Two working rules keep critique useful. Findings carry severity — blocker, important, polish, question — so you triage instead of wading through an undifferentiated list. And critique stays read-only: the agent reports findings, you decide which ones matter, and only the approved findings go into the revision pass. An agent that critiques and fixes in the same breath takes the decision away from you.

Revision is where the loop either converges or thrashes, and the difference is almost always the feedback. The left column is feedback the agent can execute directly: it names a location, a change, and implicitly a way to verify it. The right column is real feedback too — often the more important kind — but it contains an unmade decision. Handing it to the agent unprocessed produces one of two failure modes: the agent guesses at the decision and you get a new direction you did not ask for, or it makes a token gesture at the words and nothing meaningful changes.

The working habit is translation. When your reaction is this does not feel trustworthy, the design work is figuring out why — the price is hidden below the fold, the renewal terms are vague, the error state is a dead end — and then handing the agent the specific, checkable version. That translation is not overhead; it is the same skill as writing good critique for a human team, and it is exactly the judgment work that stays with the designer.

The other discipline at this step is scope. The revision pass acts only on approved findings, does not address rejected ones, and does not introduce a new visual direction. The critique article's revision prompt makes this explicit, and it is worth borrowing verbatim: list what changed and what still needs review, then recapture the same screenshots used in critique so the next look is a comparison rather than a fresh impression. Recurring fixes — the kind you have now typed three sessions in a row — are a signal that a rule belongs in the harness, which is where Module 4 picks up.

Ship is deliberately the shortest step and the one with the clearest owner. The checks passing is the entry condition, not the decision. The decision is whether this artifact, with this evidence, against this brief, should go in front of users or stakeholders with your name attached. Sometimes the honest answer is hold — the work is fine but the timing or the surrounding product is not — and sometimes it is one more bounded round, with a specific finding, not a general wish for better.

The recording habit is what separates teams that get compounding value from the loop from teams that get a series of one-off wins. Two things are worth writing down, and neither takes more than a few minutes. First, a short note beside the work: what shipped, what was cut, and why — the kind of trail the critique loop naturally produces if you kept findings and severities. Second, and more important, the recurring feedback gets promoted into the harness: the anti-pattern you have rejected three times, the component the agent keeps forgetting exists, the tone rule you keep restating. That promotion is the dashed line on the loop diagram, and it is the mechanism by which next month's first drafts get better than this month's.

If nothing else from this slide survives, keep the accountability point. The agent generated the work, the checks verified parts of it, and the decision to ship it is still a person's. That was true in Module 1 as a principle; here it is true as the literal last step of every session.

This slide names the habit that keeps the loop healthy at session scale: show early, iterate small. The failure it prevents is drift. An agent that runs unsupervised for a long stretch makes a chain of small judgment calls — a layout choice here, an invented label there, a component it decided to write rather than reuse — and each one is individually reasonable while the sum walks away from your intent. By the time you look, the rework is large enough that the temptation is to accept it as is, which is how generic work ships.

The second bullet is the structural reason this matters: review capacity, not generation capacity, is the bottleneck of the whole loop. The agent can produce a forty-file change faster than you can read it honestly. A change you cannot review is a change you either rubber-stamp or discard, and both outcomes waste the run. Sizing runs to what the next gate can actually absorb is the practical version of holding the gates.

The tactic is simple and the agent does not mind it: ask for the riskiest or most uncertain part first — the layout approach, one representative card, the empty state — look at it, then let the rest follow the corrected pattern. This is the same instinct as showing a stakeholder a direction before polishing all five screens. It costs a few minutes of latency per session and saves the forty-minute correction loops the Module 1 case study put numbers on.

These three failures are the ones the school sees most often in teams adopting agents, and each one maps to a specific point in the loop. Vague briefs break the loop at the start: the agent fills missing intent with the most common pattern on the public web — the marketing band, the gradient, the invented call-to-action from the Module 1 case study — and the session becomes a series of corrections that re-supply, one round at a time, the context the brief never carried. The fix is not a longer prompt; it is doing the design thinking — user job, direction, review criteria — before generation rather than during it.

Skipped gates break the loop in the middle. The output is fast and plausible, which is exactly what makes it dangerous unreviewed; the problems surface in front of stakeholders, or in production, where they cost the most. The fix is to make the gates structural rather than willpower-based: plan mode keeps the agent read-only until you approve, and a scratch branch means nothing reaches main without a deliberate decision. People skip rituals when busy; they skip enforced modes much less.

Feedback that never reaches the harness breaks the loop across sessions. Each individual session looks fine, but the same corrections recur because they live only in scrolled-away conversations — the agent has no taste memory. The fix is the recording habit from the ship step: when a correction shows up for the second or third time, it gets promoted into the harness or a skill. The shared tell across all three failures is repetition: if you notice you are typing the same thing again, the loop is leaking somewhere upstream of where you are standing.

Walk the trace left to right and call out the ownership at each stage, because the diagram is really a time-and-attention budget. The brief takes the first ten minutes, and most of that is not typing — it is deciding what the section is for, which is design work the one-line request from the weak run simply skipped. The plan review is four minutes: the agent restated the user job, named the components it would reuse, and flagged a real contradiction in the brief; resolving it cost one written sentence, before any code existed.

Generation is about seven minutes of agent time on a scratch folder, during which the designer is not watching every keystroke. The screenshot critique is the second gate: the agent runs the token audit and the type check and captures desktop and mobile screenshots; the human judges hierarchy, tone, and states against the criteria the brief wrote down. This is where the invented component prop surfaced — a TS2322 the plan had no way to prevent — which is the concrete argument for keeping both gates rather than trusting the plan. The revision is three minutes and scoped to that one finding, and the ship decision plus the harness note closes the session at roughly half an hour.

Make the honest caveats explicit. These timestamps describe one bounded task on a small, well-harnessed site; a heavier task stretches every stage, especially the brief and the critique. And the numbers come from the school's traced run, not a benchmark — the proportions are the lesson, not the absolute minutes. Of the thirty-one minutes, agent time is about ten; the other twenty are thinking, reviewing, and deciding, which is a fair preview of what the job feels like when the loop is working.

This exercise is the first time in the course participants touch an actual agent, and it is deliberately constrained to plan mode so the cost of getting it wrong is zero: nothing is built, nothing is edited, and the whole session is reading and judging. The input is the one-page brief from the Module 1 exercise; if someone skipped that, ten minutes writing it now is part of the exercise rather than a blocker.

The two questions at the end carry the learning. One thing the plan got wrong that your brief caused surfaces the gap between what people wrote and what they meant — usually a missing user job, an unstated constraint, or review criteria that exist only in their head. One thing it got wrong on its own surfaces the agent's defaults: the generic pattern it reached for, the state it ignored, the component it planned to invent. Distinguishing those two failure sources is the skill the rest of the course sharpens — the first is fixed in the brief, the second is fixed in the harness or caught at a gate.

If running this live, have a few people read out the contradictions or assumptions their agent flagged. The variety makes the point better than any slide: the same exercise produces different gaps for every brief, and a plan that flagged nothing usually means the brief was so loose the agent had nothing to push against. Keep the page and the plan; Module 3 rewrites this brief properly and runs it for real.

Recap by walking the loop one more time, but at the speed of the worked trace rather than the diagram: ten minutes of brief, a four-minute plan review, an unattended generation run, a critique built on checks and screenshots, a scoped revision, and a human ship decision with a note for the harness. The proportions are the message — most of the half hour is design thinking and judgment, and the agent's share is the production in the middle.

Reinforce the two structural ideas that make the rhythm sustainable. The gates are enforced by the platform and the branch strategy, not by discipline, which is why they survive busy weeks. And the loop compounds only if the ship step writes something down: recurring feedback promoted into the harness is what makes session fifty meaningfully better than session five.

Preview Module 3 concretely. Everything in this module assumed the brief existed and was good; the next module is about making that true — the seven-line canvas, vague versus specific prompts with the costs measured, turning taste adjectives into behavioural constraints, briefing states rather than just the happy path, and the brief review prompt that makes the agent find the gaps before you do. Participants who did the exercise already have the raw material: the plan-only session showed them exactly where their current brief leaks.