Prompts to Harness: The Agent Ladder Is a Design Vocabulary

The ladder is about control, not cleverness

This week a post on X named something I'd been circling for a year. It quoted an Anthropic engineer: "Prompting is no longer the job. I run agents inside loops + graphs + harness." The post claims 5–10x more finished work from the same model. I can't check that number, and I'm not adopting it. What I find useful is the ladder:

Prompts → Agents → Loops → Graphs → Harness

Engineers read that ladder as things to build. I read it as a design vocabulary. Each rung answers: who decides what happens next, who decides when the work is done, and where a person's attention is needed. I spent years as Head of Brand and then Head of Design at Plume; that's the work I recognize — choosing where control lives and making it visible.

Here's each rung, grounded in Anthropic's public engineering writing.

Rung 1: Prompt

What it is. You give a model one instruction, or a few back-and-forth turns, and it gives you a result. You decide what happens next and whether the result is good enough, every single time.

Designer analogy. A command line, or a sketch on a napkin. It's quick and expressive, and nothing about it lasts.

What you design. Very little beyond the input field and how the output renders. All the quality control happens in the user's head.

Stay or climb. Stay here for exploration and one-off tasks. Climb when you notice yourself pasting the same instructions repeatedly, or checking the same things by hand. A project context file (the brief and conventions the agent should inherit every time) is the first step off a pure prompt. A prompt is a gesture. It isn't a system.

Rung 2: Agent

What it is. Anthropic defines agents as systems where the model "dynamically directs its own process and tool use" based on feedback from its environment. In practice that means a model with tools, running in a loop. They contrast agents with workflows, which follow code paths set in advance.

Designer analogy. You stop handing someone a script and start handing them a brief and a toolbox.

What you design. A few things that are easy to underestimate:

• Project context. A short file of conventions, architecture, and commands assembled into the prompt so the agent doesn't rediscover the product via tool calls. For designers: the brief plus the design system the agent inherits every run.
• The agent-computer interface. Anthropic says to put as much care into tool names, descriptions, and parameters as you would into human-computer interfaces. That's information architecture and microcopy, written for a model as the reader. Tools are required for agency; without them you're back to a chatbot. Skills package a repeated multi-step procedure you'd otherwise re-explain every time — operator UX like "/code-reviewer" or "/deploy," not just more prompt text.
• Plan before build. Ask for a plan, then act as PM reviewing it before implementation. Anthropic recommends showing planning steps; Plan mode makes that the default gate. For the person using it, the plan is the main thing they can trust or correct.

Stay or climb. One agent with good tools and a solid context file covers more ground than most people expect. Climb when "done" is fuzzy, or when the agent keeps declaring success too early.

Rung 3: Loop

What it is. Agents repeating cycles of work until a stop condition is met. Anthropic's Claude Code guide describes four types:

• Turn-based. You trigger each round, and it stops when you or the model say it's done. Verification skills let the agent check its own work without you re-explaining the checklist.
• Goal-based. You define "done" and set a turn cap, and an evaluator keeps the work going until the criteria pass. Deterministic checks (does the test pass, does the file exist) beat "looks good." For UI work, a screenshot or target design as ground truth is the visual version of that check.
• Time-based. The loop runs on an interval or schedule, which suits recurring jobs and watching external systems.
• Proactive. Triggered by an event or schedule with nobody watching in real time. It combines goals, skills, and review.

Designer analogy. A design critique cycle with an actual definition of done.

What you design. Stop criteria, verification, and token budgets — product decisions that look technical. Hooks run custom logic at lifecycle points in the loop (for example after a tool use, auto-run typecheck). Think of them as automated quality gates: design-system lint for agent output. The most important rule: the agent that writes shouldn't be the agent that reviews. Models grade their own work too generously. Decide who reviews, what they check (including visual reference), and what the user sees when a loop stops, stalls, or runs out of budget.

Stay or climb. Stay while the process is linear. Climb when it genuinely forks.

Rung 4: Graph

What it is. An explicit state machine: nodes and edges that define branches, parallel work, approval gates, recovery paths, and handoffs between specialist agents. (This isn't a knowledge graph.) It lines up with the workflow patterns Anthropic describes: routing, parallelization, orchestrator-workers, and evaluator-optimizer.

Designer analogy. A user flow diagram that actually runs.

What you design. The graph decides when a person interrupts, which screen appears at each gate, and which path the user ends up seeing. Every approval node needs a screen. Every failure edge needs recovery copy. Every parallel branch needs a way to show progress.

Stay or climb. Graphs are overkill when one agent with tools does the job. Anthropic's advice throughout is to start simple and add structure only when it clearly improves results. Draw a graph only when the forks are real.

Subagents vs. teams. Two coordination patterns matter for the UI you design. Subagents get isolated context, their own tools and prompt, and report only to the main agent — never to each other — so the main thread stays clean. Agent teams let teammates talk to each other against a shared task list until the work is done. Isolate when parallel specialists shouldn't pollute the lead context; design coordination UI and status when the work needs peers to negotiate.

Rung 5: Harness

What it is. The software scaffolding around the model: the loop, tools, context management, and guardrails that, in Anthropic's framing, turn raw intelligence into a working agent. Designing a harness means deciding what belongs in that scaffolding and, as models improve, what you can take out.

Designer analogy. The operating system and the design system together. It's the environment that every interaction inherits.

What you design. Anthropic's harness guidance reads like a design brief:

• Lean on what the model already knows. Don't rebuild what it can already do.
• Strip dead weight. Scaffolding that made up for weaker models becomes friction.
• Set boundaries carefully. Security, observability, UX surfaces — and lifecycle hooks that enforce quality gates without another human pass. When an action goes through a dedicated tool, the harness can intercept it, gate it, show a modal, or ask for confirmation.
• Leave artifacts. Harnesses that write progress files and commits so the next session can pick up. Continuity design, like a good handoff document.

This is where the agentic UX moments live: show the plan, accept results chunk by chunk, stop with one key, ask when a constraint is missing, hand off cleanly. You don't get those from better prompts. They come from the harness and the UI. Protocols like AG-UI are starting to standardize how harnesses surface to people — streaming, shared state, generative UI, and human-in-the-loop.

Brand lives here too. Voice, how the agent refuses, and how it hands off are set at the harness boundary and checked in reviews of agent behavior. Product and brand become one system.

The ladder at a glance

Same judgment, new surface

As a Head of Design, my specs increasingly have to spell out stop conditions, verification, and which skills or hooks fire — not just screens. Design reviews now include how the agent behaves: when it asked, when it should have asked, and when it kept going after it should have stopped. Capturing decisions matters more, because the system makes thousands of small choices you'll never see one by one.

None of this replaces design judgment. It moves it. The job is less about writing the perfect instruction and more about designing the system the model runs in: context the agent inherits, stop rules, plan gates, review surfaces, tool UX, and control revealed gradually so people step in at the right moment. Same craft, new surface.

Source note

• Spark: X post by @hayatomaruu, Oct 15, 2026, https://x.com/hayatomaruu/status/2110845685742367142. It quotes an Anthropic engineer's framing and the ladder. The "5–10x" figure is the post's claim and hasn't been verified. The accompanying course video was not used as a source.
• Anthropic, "Building effective agents": https://www.anthropic.com/engineering/building-effective-agents (agents vs. workflows, ACI, workflow patterns)
• Claude, "Getting started with loops": https://claude.com/resources/articles/getting-started-with-loops (loop types, stop conditions, writer ≠ reviewer)
• Claude, "Harnessing Claude's intelligence": https://claude.com/resources/articles/harnessing-claudes-intelligence (harness definition and patterns)
• Anthropic, "Effective harnesses for long-running agents": https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Anthropic, "Harness design for long-running apps": https://www.anthropic.com/engineering/harness-design-long-running-apps
• AG-UI protocol: https://docs.ag-ui.com/introduction
• Also informed by Lydia Hallie's Claude Code workshop talk circulated on X (Frontend Masters), Oct 2025/2026 context.