Prompting & Instructing Agents

The everyday skill most designers already have is one-shot prompting: type a request, read the reply, refine, repeat. It is a conversation, and it works because you are the loop - you catch a wrong turn on the very next line. Instructing an agent removes that safety net. Between your instruction and the result the agent takes many steps you never see: it interprets the goal, decides an order of work, searches, reads, drafts, revises, and only then reports. Every one of those steps inherits whatever was unclear in your brief. This is why an instruction that would be a perfectly good chatbot prompt - 'give me some ideas for a small clinic waiting room' - is a poor agent brief: it leaves the agent to invent the scope, the constraints, the audience and the definition of success, and it will invent them plausibly and run with them.

The move, then, is from a question to a brief: a piece of writing dense enough that a literal, capable worker could execute it without asking you a single clarifying question and still land close to what you wanted. The test is exactly that - could a smart new hire who has never met you and cannot read your mind do this and get it broadly right? Wherever the answer is 'no, they would have to guess', you have found a gap the agent will fill with a guess of its own.

There is a practical rhythm to this. For quick, low-stakes, reversible work, a light instruction and a glance at the output is fine - treat it like a conversation. For work that will run long, touch real files, cost money, or feed into something you will rely on, invest in the brief up front, because the cost of ambiguity scales with the autonomy you are handing over. And notice the shift in your own role: your value moves from typing the perfect phrase to specifying the work clearly and judging the result rigorously - the higher-value end of the same skill. The designer who briefs well and verifies hard gets the productivity; the one who fires vague prompts at an autonomous system gets confident, expensive noise.

A strong agent brief is not longer for its own sake; it is complete along a few predictable axes. Learn the axes and you can write a solid instruction for almost any task. Goal - the outcome you want, stated as an outcome, not a vague topic: not 'research fire codes' but 'produce a one-page summary of the means-of-escape requirements that apply to a two-storey office of about 400 square metres, with the clause references, so I can brief the team.' Role - who the agent should be while doing it, which sets tone, depth and defaults: 'act as a meticulous technical researcher who flags uncertainty' pulls very different behaviour from an unframed request. Constraints - the hard limits: what it must not do, the boundaries of scope, the sources it may or may not trust, the budget of time or steps, the confidentiality rules. Context and inputs - the specific material it should work from (the brief, the drawing schedule, the client's requirements) rather than the generic web, which is the single biggest lever on quality and the subject of Lesson 2.3 on grounding. Success criteria - the explicit picture of what a finished, acceptable result looks like, covered in the next section because it is where most briefs are weakest.

A useful discipline is to separate two layers. System (or standing) instructions are the durable rules that should hold across everything this agent does for you - your role framing, your studio's non-negotiables, the house style, the safety rules ('never invent a code clause; if unsure, say so and cite nothing'). Task instructions are the specific job in front of it today. Keeping them apart means you write the standing rules once and reuse them, and each task brief stays short and focused.

One caution runs through all of it: be specific about substance, not just verbose. Piling on adjectives ('a beautiful, innovative, world-class concept') tells the agent nothing operable. Naming the constraint ('must fit a 3.2 metre ceiling, budget-grade materials, step-free access throughout') tells it everything. Specificity is information the agent can act on; decoration is not. And note what none of these axes can do: none of them transfers your judgement. The brief shapes the work; deciding whether the work is good remains yours.

The most common failure in an agent brief is not a missing goal or a missing constraint - it is a missing definition of success. Humans carry an unspoken picture of 'done' and assume the worker shares it; an agent has no such picture unless you draw it. If you do not say what a finished, acceptable result looks like, the agent will decide for itself when it is finished, and its threshold will rarely match yours. So the single highest-leverage sentence in most briefs is the one that describes the deliverable concretely: its form, its length, its structure, and the checks it must pass.

Think of it as writing acceptance criteria the way a good brief to a consultant would. Form and format: 'a table with columns X, Y, Z', 'a one-page memo under 400 words', 'a bulleted checklist grouped by room' - the shape you can actually use, not whatever shape the agent prefers. Scope boundaries: what is in and what is explicitly out, so it neither stops short nor sprawls. Quality bars: 'every claim about a regulation must carry a clause reference or be marked unverified', 'every product suggested must have a real supplier', 'flag anything you are unsure about rather than smoothing it over.' Examples are extraordinarily powerful here: one short example of a good output entry teaches the agent more about your standard than a paragraph of description, because it shows rather than tells.

Defining done also gives you something to verify against, which is the point. A brief that ends 'and it is acceptable when every row has a source I can click and the total does not exceed the budget' has handed you your own checklist for judging the result. Without it, verification becomes a vague feeling of whether the output 'looks right' - exactly the state in which confident, plausible errors slip through. This connects to the course's spine: because you remain responsible for the output, you must be able to check it, and you can only check crisply against a standard you set in advance. Vague in, unverifiable out. The discipline of saying precisely what good looks like is therefore not bureaucratic - it is the thing that makes an autonomous run safe to rely on, and it is squarely a matter of your professional judgement, not the agent's.

Even a careful brief will not be perfect the first time, and the skilled move is to treat the instruction itself as the thing you improve - not to keep hand-fixing the outputs. When an agent returns work that is off, the amateur reaction is to correct this particular result and move on; the professional reaction is to ask what in the brief let it go wrong, and fix that, so the next run and every run after is better. If the agent invented product prices, the brief needed a rule about sourcing and flagging uncertainty. If it wrote a wall of prose when you wanted a table, the success criteria needed the format. If it went out of scope, the constraints needed a boundary. The output is a symptom; the instruction is the cause you can actually treat.

This is where standing instructions earn their keep. The rules you discover the hard way - 'always cite the source for any regulatory claim', 'never proceed past a step that would spend money without pausing', 'match our drawing-list naming convention' - belong in the durable system layer, so they are enforced everywhere without you retyping them. Over a few weeks of real use, a studio accumulates a small, hard-won library of standing rules that encode its judgement and its scars. That library, more than any clever one-off prompt, is what makes agents dependable in a practice.

Two honest limits keep this in proportion. First, no instruction, however good, removes the need to verify - a perfectly briefed agent can still be confidently wrong, so the brief reduces error rates but never your obligation to check what matters (Module 8.1). Second, more words are not automatically better; past a point, an overloaded brief buries the important constraints and the agent loses the thread. Aim for complete, not maximal - every sentence either states the goal, a real constraint, needed context, or the definition of done, and anything that does none of those is noise. Instructing agents well is, in the end, the ordinary professional skill of briefing work clearly and reviewing it honestly - raised in stakes because the worker is fast, literal and autonomous, and lowered in forgiveness because it will not stop to ask.