# Chapter: Why Design Needs A Harness, Not Just A Prompt Status: Second draft - following harness properly Template target: `editorial-template.html` **Harness Compliance:** - ✅ Checked `routing-table.md` before starting - ✅ Loaded `marco-writing-voice/SKILL.md` - ✅ Loaded `article-to-marco-voice/SKILL.md` - ✅ Read required context: `BRAIN.md`, `FOUNDATION-IA.md`, `FOUNDATION-GLOSSARY.md`, `INDUSTRY-OVERVIEW.md` - ✅ Followed 4-block structure before writing - ✅ Used transformation pattern: External idea → Marco's interpretation → Planark example → Harness artifact Primary sources: - `BRAIN.md` - harness engineering vocabulary, five verbs framework - `docs/INDUSTRY-OVERVIEW.md` - industry context - `docs/HARNESS-ROADMAP.md` - harness definition and vision - Skills: marco-writing-voice, article-to-marco-voice ## Working Title Why Design Needs A Harness, Not Just A Prompt ## Reader Promise Understand why prompts alone cannot carry the weight of serious design workflows, and why the AI agent industry formalized the concept of harnesses to turn intelligence into reliability. ## Core Argument In 2026, the AI agent industry formalized something designers need to understand: **Agent = Model + Harness**. The model supplies intelligence. The harness turns intelligence into reliability. For engineers, this insight led to frameworks like Vercel AI SDK, Anthropic's agent loops, and OpenAI's Agents SDK. For designers, this same discipline needs to shape how we work with AI: not better prompts, but better systems around the prompts. ## Article Spine ```text prompts are instructions -> instructions are not systems -> serious work needs structure -> harness engineering vocabulary exists -> Design Harness applies it to design workflows -> five verbs framework -> inner vs outer harness -> designers own the outer harness ``` ## Draft Article A prompt says *please*. A harness says *no*. That difference matters more than most designers realize. For the past two years, the conversation around AI and design has been dominated by prompting: better instructions, smarter phrasing, clever techniques to coax better output from models. That conversation is not wrong, but it is incomplete. Prompts are instructions. Instructions are useful. But instructions alone cannot carry the weight of serious design work. ### What The AI Agent Industry Figured Out In 2026, the AI agent industry formalized something that had been emerging across engineering teams: the concept of the harness. The equation is simple: **Agent = Model + Harness** The model supplies intelligence: language understanding, pattern recognition, generation capability, and reasoning. The harness supplies everything else: constraints, context, verification, correction, and escalation. This insight has already shaped how engineers build with AI. Vercel created the AI SDK. Anthropic formalized agent loops. OpenAI released their Agents SDK. LangChain built tooling around the same principle. All of them understood that the model is not enough. You need a box around the model. Not to limit it arbitrarily, but to make it reliable. That box is called a harness. ### Why Designers Should Care Designers are not writing agent frameworks. Most designers will never need to understand the inner mechanics of LangChain or the Vercel SDK. But designers need to understand the principle behind those frameworks, because the same principle applies to design workflows with AI. If you only have prompts, you have instructions. If you have a harness, you have a system. The difference shows up in real work: - A prompt asks the agent to follow the design system. A harness *prevents* the agent from violating it. - A prompt reminds the agent about product context. A harness *gives* the agent access to project memory, design standards, and source files. - A prompt suggests a review step. A harness *requires* mechanical checks and human approval before any change counts. - A prompt asks nicely. A harness *catches mistakes* and turns them into permanent fixes. When Planark needed a new feature designed and implemented, I did not write better prompts. I wrote better context files. I clarified the design rules. I built verification checks. I documented the sources that should be trusted. I saved the critique loops so the next feature would start from the right place. That is harness thinking. ### The Five Verbs Harnesses are not abstract theory. They are practical systems built from five repeatable jobs. Every harness surface does one of five things: **1. Constrain** Limit what the agent can do. This is not about suppressing creativity. It is about making sure off-brand UI, token violations, and structural drift get blocked automatically, not fixed after someone notices. In the Design Harness, this looks like: - Design-system rules that agents cannot override - Token gates that flag violations before they merge - `preToolUse` hooks that stop bad moves early **2. Inform** Give the agent what it needs to do good work. The model does not automatically understand your product, your users, your constraints, or your taste. You have to make it legible. In the Design Harness, this looks like: - `AGENTS.md` carrying project memory - `DESIGN.md` explaining taste and visual rules - `context/` folders with product briefs and source files - Skills that document reusable workflows **3. Verify** Prove the work before it counts. AI output can be plausible and wrong. Verification is the proof layer: mechanical checks for structure, human checks for judgment. In the Design Harness, this looks like: - Design-detector checks that scan for token drift and antipatterns - Critique isolation: run the critique separately from the implementation - Review boards that compare output against sources and standards **4. Correct** When something fails, fix the harness so it never happens again. This is the ratchet: every caught mistake becomes a permanent rule. In the Design Harness, this looks like: - Routing audits that turn missed tasks into new skill entries - `KNOWN-ISSUES.md` that tracks patterns worth blocking - Skill benchmarking that surfaces output drift over time **5. Escalate** When the harness cannot decide, send it to a human. Not everything should be automated. Some decisions need judgment, taste, or tradeoff awareness that only a person can provide. In the Design Harness, this looks like: - Designer profile gates that require approval for visual changes - Handoff menus that make human review explicit - `AskQuestion` UI patterns that pause for clarity These five verbs are not my invention. They are formalized patterns from harness engineering across the industry. What I am doing is applying them to design workflows. ### Inner vs Outer Harness There is one more distinction that matters: inner harness vs outer harness. The **inner harness** is what the model maker controls: Claude's context window, GPT's safety layers, Gemini's built-in guardrails. Designers cannot change the inner harness. It is shipped by Anthropic, OpenAI, or Google. The **outer harness** is what you configure: the context files, skills, design-system rules, routing logic, validation checks, and critique loops. The Design Harness is an outer harness. That means designers own it. Models are replaceable. The harness adapts to the project, not the other way around. When GPT-6 or Claude Opus 5 or Gemini 3 ships, the outer harness stays. You swap the model. The system continues. ### Why This Is Not Just Engineering Terminology Some designers might read this and think: "This sounds like engineering. I am a designer. Why should I care about harnesses?" Fair question. The answer is simple: because the work is already becoming this. Designers are already writing context files. Designers are already documenting project memory in `AGENTS.md` or `CLAUDE.md` files. Designers are already asking "how do I make the agent understand my design system?" Designers are already frustrated when AI output drifts off-brand or misses the product feeling. Those problems are harness problems. The difference is that engineers formalized the vocabulary and patterns. Designers have been improvising. This is not about designers becoming engineers. This is about designers recognizing that the same discipline that makes agent frameworks reliable can make design workflows reliable too. ### What A Design Harness Actually Looks Like A Design Harness is not a tool. It is a folder of files, rules, examples, and checks that make agents more useful for design work. It includes: - **Project memory** (`AGENTS.md`) that explains what the product is, what matters, and what not to touch - **Design memory** (`DESIGN.md`) that explains visual language, components, tone, and anti-drift rules - **Skills** that document reusable workflows, not just one-off prompts - **Context files** that carry product briefs, user research, source material, and constraints - **Validation rules** that check output against design tokens, antipatterns, and product standards - **Critique loops** that separate judgment from implementation - **Source-trust checks** that ground changes in logs, data, and proof instead of plausible AI text This is not vaporware. The lab version of this already exists. I built it for Booksy's Design Discovery Lab: real squad work on checkout flows, referral systems, settings IA, and calendar features. The harness includes all five verbs: constraint (token detector, `preToolUse` hooks), inform (orchestrator, context files, skills), verify (audit skill, critique isolation), correct (routing audits, benchmarking, ratchet), and escalate (designer gates, handoff menus). Planark is the production proof: a real iOS app with users, APIs, constraints, and publishing pressure. The public version is what I am building here: Agentic Design Ops, the learning library, and the future downloadable Design Harness. ### The Work Is Not The Prompt Here is the shift I want designers to internalize: The work is not writing a better prompt. The work is building a better system around the prompt. Prompts are the interface. The harness is the infrastructure. When you ask an agent to design a feature, the quality of the output depends more on the harness than the phrasing of the request. Did the agent have access to the right context? Did it know the product rules? Did it understand the design system deeply enough to avoid generic moves? Did it get reviewed before implementation? Did the output get validated against real sources? Those are harness questions. And they matter more than prompt tricks. ### Prompts Are Not Enough Let me be concrete. A prompt can say: "Follow the design system." A harness **prevents violations** with a token detector that scans output and blocks off-system values before they merge. A prompt can say: "Here is the brand feeling." A harness **documents taste** in a `DESIGN.md` file that agents read before every design task, with examples, anti-patterns, and density rules. A prompt can say: "Check if this is correct." A harness **runs verification** through separate critique isolation, logs-before-fixes workflows, and source-trust checklists. A prompt can say: "Remember this for next time." A harness **saves learning** in project memory, build logs, skill benchmarks, and routing audits that improve over time. Prompts ask nicely. Harnesses enforce. That is the difference. ### What This Means For Designers If you are a designer working with AI agents, you have two paths: **Path 1:** Keep optimizing prompts. Write better instructions. Hope the agent understands. Fix drift manually. Start from zero every time. **Path 2:** Build a harness. Document your design system in agent-readable formats. Create project memory. Write reusable skills. Set up verification checks. Turn mistakes into permanent rules. Treat the system as the asset. Path 1 works for experiments. Path 2 works for products. This is why I am not building another prompt library. I am building the Design Harness: the context files, skills, standards, checks, and workflows that make design agents reliable instead of just fast. ### What Human Writing Looks Like vs AI Writing Here is a concrete example of the difference. When I wrote the first draft of this article, I followed prompts informally. The output was good, but it had AI tells. Here is what that looked like compared to human writing from other designers: **AI-sounding (what to avoid):** "In the context of modern design workflows, it's important to understand that artificial intelligence systems require comprehensive documentation to function optimally. This documentation should include design principles, component specifications, and quality standards. Additionally, organizations must consider the various factors that influence successful implementation, including team readiness, technical infrastructure, and organizational culture." **Human writing (Jeff Gothelf):** "Most people run it in reverse: they start with a tool and ask whether they should use Claude or ChatGPT, then search for a task to apply it to. The last thing they consider is how they naturally do their best work." **Human writing (Buzz Usborne):** "I'm intentionally keeping this post unpolished because the conversation is evolving rapidly, and I don't want this to come across as instructional." **Human writing (Linear):** "That changes with AI and LLMs. Without form, function gets lost." **What makes the human examples different:** - Short sentences. Direct. No setup. - Takes a stance ("most people run it in reverse") - Shows thinking ("I'm intentionally keeping this unpolished") - Judgment language ("changes", "gets lost") - No filler phrases - Specific, not abstract **What makes the AI example wrong:** - "It's important to understand that" (filler) - "Additionally" (transition word that adds nothing) - "Various factors" (vague) - Abstract before concrete - Could be about anything - Perfectly smooth, no edges The difference is not personality. The difference is that human writing has friction, stance, and specificity. AI writing smooths everything into corporate nothing. This matters because when you build a harness, you need writing skills that produce human output. Not to trick anyone. To be clear, concrete, and useful. The anti-AI writing skill I built for this project does exactly that. It teaches agents to write with punch, take stances, show thinking, and avoid the tells that make writing feel generated. That skill is now part of the harness. Every article, every chapter, every field note written in this project must follow it. ### The Harness Is The Operating System When I talk about Agentic Design Ops, I am not talking about a new category of tools. I am talking about a new way of organizing design work with AI. The harness is the operating system. Skills are the reusable workflows. Context files are the memory. Critique loops are the quality gates. Source-trust checks are the proof layer. Agents run inside this system. They do not replace it. And that system is what designers can own, adapt, and improve—regardless of which model OpenAI, Anthropic, or Google ships next year. ### What Comes Next This article is the foundation. The next pieces will show the system in detail: - What the five verbs look like in real design workflows - How to write `AGENTS.md` and `DESIGN.md` as agent-readable memory - How to design skills, not just prompts - How to set up critique loops, source-trust checks, and validation habits - How to assemble a lightweight Design Harness for your next project But the principle starts here: A prompt is an instruction. A harness is a system. And serious design work needs the system. --- ## Reusable Artifacts From this chapter, extract: 1. **Harness definition card** - one-page explainer of Agent = Model + Harness 2. **Five verbs poster** - visual breakdown of Constrain, Inform, Verify, Correct, Escalate with design examples 3. **Inner vs outer harness diagram** - what designers control vs what model makers control 4. **Prompt vs harness comparison table** - side-by-side of what each approach can/cannot do ## Derivatives - Email lesson: "Agent = Model + Harness" - LinkedIn post: "A prompt says please. A harness says no." - LinkedIn article: full chapter adapted for LinkedIn long-form - Course exercise: "Audit your current AI design workflow - is it prompt-based or harness-based?" - Social snippet: the five verbs as a short carousel ## Next Chapter Next: **"The Five Verbs Of A Design Harness"** A deeper dive into Constrain, Inform, Verify, Correct, and Escalate with Planark examples and practical implementation patterns. ## Notes This chapter introduces harness engineering vocabulary to designers without requiring them to become engineers. It grounds the abstract concept in practical design work, uses Planark and the lab as proof, and sets up the foundation for the detailed harness articles that follow. Key moves: - Start with the punch: "A prompt says please. A harness says no." - Establish industry credibility: this is not just Marco's idea, this is formalized practice - Make it relevant: designers are already doing this, they just lack the vocabulary - Show the five verbs as practical, not theoretical - Distinguish inner/outer harness so designers understand what they control - Use Planark as the real-world proof - End with urgency: Path 1 vs Path 2, and what serious work requires