A prompt says please
A harness says no.
That difference matters.
Prompts are useful. A good prompt can produce a sharper critique, a cleaner first pass, or a better prototype. But a prompt is still an instruction in one moment.
Serious design work needs more than that. It needs product memory, source trust, design-system rules, critique loops, QA, and a way to save what went wrong so the next run improves.
If all of that lives only in the designer's head, the agent starts every task half blind.
The shift: stop treating the prompt as the system. Build the system around the prompt.
The five-minute version
The model is not the workflow
The model supplies intelligence. The workflow decides what context it sees, what it may change, how the output is checked, and when a human must decide.
Prompts do not preserve memory
If you re-explain the product every time, the designer is doing manual context management. That does not scale.
Rules need teeth
"Follow the design system" is weaker than token checks, source gates, critique steps, and approval boundaries that the workflow actually enforces.
Failures should improve the system
When an agent misses the mark, the answer is not only to fix the artifact. The Harness should gain a better rule, checklist, source, skill, or routing example.
The industry idea
Engineering teams have already named the pattern:
Agent = Model + Harness
The model handles language, pattern recognition, generation, and reasoning. The harness supplies the surrounding machinery: constraints, context, tools, checks, correction, logs, and escalation.
That idea is usually discussed through software agents, frameworks, SDKs, and runtime systems. Designers do not need to become agent-framework engineers to use the principle.
We need the design translation.
Why designers should care
Designers are already running into harness problems.
The agent forgets the product feeling. It invents a pattern that is not in the system. It treats weak source material as truth. It makes a screen that looks polished but misses the user situation. It skips the awkward edge state because the prompt asked for the happy path.
Those are not only prompting problems.
They are missing-system problems.
| Prompt thinking | Harness thinking |
|---|---|
| "Follow the design system." | Load design rules, use approved components, then run a token/design audit. |
| "Remember the product context." | Put product memory in files the agent reads before work starts. |
| "Check your answer." | Run source checks, screenshot review, accessibility checks, and human approval. |
| "Do better next time." | Update the Harness so the same mistake is harder to repeat. |
The five jobs of a Harness
Every useful Harness surface does one of five jobs.
| Verb | What it means for design work |
|---|---|
| Constrain | Limit off-system moves with design rules, token gates, permissions, and approval boundaries. |
| Inform | Give the agent product context, design standards, source files, examples, and project memory. |
| Verify | Prove the work with critique, screenshots, accessibility checks, source trust, logs, and human review. |
| Correct | Turn mistakes into routing updates, checklist edits, skill changes, and known-issue records. |
| Escalate | Ask the designer when the decision depends on taste, ambiguity, risk, politics, or product judgment. |
The useful sentence: a prompt asks. A Harness constrains, informs, verifies, corrects, and escalates.
Inner harness vs outer Harness
The inner harness belongs to the model maker: safety layers, model behavior, context windows, built-in tools, and default guardrails.
Designers do not control that.
The outer Harness is what the team controls: files, rules, skills, routing, sources, gates, checks, logs, and approval paths.
The Design Harness is an outer Harness for design workflows.
Models will change. The project still needs memory, taste, constraints, and proof.
What it looks like in files
A Design Harness is not a mood. It is a folder of files and habits around the agent.
| Piece | Job |
|---|---|
AGENTS.md / CLAUDE.md | Project entry rules and where the agent should look first. |
DESIGN.md | Design memory: tone, density, components, banned moves, and visual judgment. |
context/ | Product, company, source, research, and design-system context. |
skills/ | Reusable workflows with inputs, steps, checks, and output formats. |
projects/ | Briefs, sources, findings, decisions, logs, artifacts, and QA evidence for each task. |
| QA and source rules | The proof layer before anything becomes approved or shareable. |
Where this is already real
This is not a prompt-pack idea.
The lab version exists in the Booksy design-system work: real design-ops pressure, routing, research, approved briefs, token-first prototypes, critique isolation, audit gates, and team artifacts.
Planark is the production proof: a real iOS app with users, APIs, source trust, product constraints, UI judgment, bugs, and launch pressure.
The public site is the teaching layer. The future downloadable Harness is the reusable package.
| Proof | What it shows |
|---|---|
| Booksy lab | The team workflow: context, constraints, skills, gates, and audit. |
| Planark | The product workflow: source trust, logs, real data, product judgment, and QA. |
| AI Design Hub | The publishing workflow: notes, articles, docs, examples, and reusable artifacts. |
The work is not the prompt
The prompt is the interface.
The Harness is the operating system around it.
When the output is wrong, the useful question is not only "how do I prompt this better?" It is also: what context was missing, what rule was unclear, what check failed, what source was weak, and what should the system remember next time?
That is why I am building the Design Harness.
Core principle: a prompt can create one good answer. A Harness makes the next answer less random.
Read next
This gives the frame. Keep going with the workflow or the build proof.