Spend any time designing with an agent, and a peculiar kind of repetition sets in.
You direct the agent to the product’s component library. It uses the right button, then builds a new card instead of using the one that already exists. You correct the card and remind it to use the spacing tokens; on the next screen, it hard-codes a gap. The following request now has to carry both corrections before you can even describe what you want made.
And if you’re working on a pitch, you have another problem altogether. You can generate a screen to make an idea tangible before a design system exists, which means the agent also starts filling in the system for you. It chooses a card pattern here, changes the navigation there, adds its own spacing and handles the same interaction differently on the next screen. The prototype may look polished in the room, while the team is left with a set of decisions nobody actually made and no coherent system to keep building from.
Designers have largely treated this as part of working with the tools. We explain more, attach another reference and keep correcting the output until it behaves.
Often, you are simply bringing the output back to standards that already exist.
When those standards have to be reintroduced across screens and sessions, however, the information probably belongs somewhere more permanent than the conversation: in the environment the agent begins with.
Enter the design harness
Software engineers have a name for the system around an agent that carries this information: a coding harness.
It supplies the context an agent works with, the tools it can reach, the state it remembers and the checks applied to what it produces.
The phrase design harness is still new. It has appeared in a handful of research papers, open-source projects and experiments around agentic design, while designers have been building parts of the idea under other names. Some are making their design systems easier for agents to read. Others are adding visual checks, persistent project instructions or rules that send an agent back to an existing component when it begins making up its own.
Put together, these parts create the working environment around the model. A prompt can direct one attempt, and a design system can supply the visual language.
A design harness, however, determines how that language enters the work, how the result is inspected and when a designer needs to step back in.
At Canvs, we are beginning to build this design harness through Omni, a tool suite built to put design-system foundations in place in minutes. Some parts of the larger platform will be agentic, while others will be products working together. The ideq is to increase both the pace and quality of the work by making more of the design process practical across projects.
We’ll be sharing more of the tools, experiments and decisions that make up the harness as it takes shape.
So what makes a harness?
To make this a little less abstract, it helps to look at tools many of us already work with every day.
First, there is the model and the product built around it. GPT and Claude refer to families of large language models. ChatGPT, the Claude app, Claude Code, and Codex are products built around those models. A product may contain a harness, but it also contains the interface and other features intended for the person using it.
Then there is the agent. When a tool such as Claude Code or Codex can inspect a repository, change a file, use another tool and respond to what happens next, it is carrying the task through a series of actions rather than returning a single answer. Tools working in this way are commonly described as coding agents. For the purposes of this piece, this is what we mean when we refer to an agent.
A harness guides how that agent works. It is the part of the setup that determines what information enters the task, which tools the agent can use, what it remembers and which checks its work must pass. Claude Code and Codex already contain general-purpose harnesses that help an agent work with software.
A design harness makes that guidance specific to a design practice. It brings the relevant parts of the product into the task, gives the agent access to the atoms, components, tools, libraries, decision documents, tests and guidelines it needs, and determines how the result will be inspected and when a decision must return to a designer.
What changes when a design harness is in place
Without a design harness, a coding agent can still open the repository, use the available files and produce a working billing screen. What it may not know is which patterns in the account area are still current, which of several form fields the team has standardised on or why the hierarchy works differently here than it does elsewhere. Each of those decisions has to be explained in the request or corrected afterwards.
With a design harness, the same task begins with those decisions already in reach. The agent can be directed towards the components used in the account area, given the available tokens and relevant project decisions, and allowed to work with the real components rather than approximating them.
The difference continues after the screen has been made. The harness can render and inspect the result. If the agent introduces a colour outside the palette, recreates a component that already exists or breaks the layout at a smaller width, the work can be sent back through the loop. If it reaches a decision that no existing rule can settle, the harness can return that decision to a designer.
The design system, project memory, visual feedback and checks all contribute to this process. What makes them a harness is the way they work together before, during and after the agent produces the screen.
A design harness does more than connect an agent to the design system
At this point, a design harness may sound like a more elaborate way of putting the design system in front of an agent. That is an important part of it, but it only answers one question: what should the agent draw from while it works?
For an existing product, the design system is often where the harness begins. It already holds d0-ecisions meant to remain consistent across screens.
The difficulty is that most design systems were made for people to interpret.
A designer can open a library, look at the surrounding product and work out which component belongs in the screen. They may know that a component’s name does not match the language used in the brief, that one variant has replaced another or that a pattern is technically available but no longer preferred. But an agent cannot reliably infer the same history from a collection of files.
This is why people have begun describing the design system as an API for agents. The phrase does not mean designers need to start writing APIs. It means the system’s decisions have to be available in a form the agent can find and act on. The words used in a brief need to connect to the components inside the product. Variants and states need to be identifiable, tokens need to be available as values rather than visual references, and the agent needs access to the implemented component rather than an image it can only imitate.
This does not mean a design harness requires a mature design system. During a pitch, for instance, those decisions may still be taking shape. Once the team settles on a type scale, a spacing rhythm or a way of handling navigation, the harness can carry those choices into every screen that follows. In this way, the underlying implementation may remain provisional while the design becomes more coherent.
At Canvs, we built Omni for exactly this part of the work. It turns early choices around colour, type and grids into a structured foundation, shows those choices in use and exports them as tokens. Request a demo for Omni here.
However, giving the agent a visual language is only one part of the job. Even a perfectly organised design system can only tell the agent what is available and how it is meant to be used. It cannot see what happened when those parts were brought together on the screen.
That requires another part of the harness: the screen itself has to enter the loop.
A design harness needs a visual feedback loop
When you ask a coding agent to build or change an interface, it works with the files behind the screen. It can use the specified components, produce a functioning interaction and pass the available tests without seeing the result in the way a designer would. The resulting interface may still have a heading that wraps awkwardly, an action that gets lost in the page or a layout that falls apart at a smaller width.
These problems are not unique to work made with AI. The difference is that a designer working directly on a screen sees it taking shape and can respond as they go. An agent may be working from the files it changed and the messages it received, with no view of what those decisions produced once the interface was rendered.
What a visual feedback loop does is bring that rendered interface back into the work. A design harness can give the agent access to a browser or design tool and require it to open the screen at the relevant sizes and states. The resulting images can then be returned alongside the original brief or reference, giving the agent something it can inspect before making another attempt.
Without that loop, the designer has to create it manually. You open the screen, notice that the navigation has wrapped or the modal runs beyond the viewport, describe what happened in another prompt and wait for the next version.
The agent may be making the changes, but you are still carrying the result from one attempt into the next.
When a visual feedback loop is part of the harness, the agent has an opportunity to notice and correct those visible problems before the work reaches you. The rendered result also gives the rest of the harness evidence it can act on.
Saying “no” is built into a design harness
Now, evidence only changes the work if the harness can act on it. Otherwise, the designer still has to interpret every finding and decide what happens next.
For that loop to address more than surface problems, the harness needs to be able to say “no.” This does not mean that it voices an opinion about the design. It means the workflow contains conditions that can stop the work from moving forward. If the result breaks a rule the team has chosen to enforce, the agent must revise it before the task can be treated as complete.
This works best for decisions that have already been settled. Approved colours and spacing values, component usage, required states and some accessibility requirements can all be checked without reopening the underlying design decision.
For instance, telling the agent to use spacing tokens still leaves room for it to hard-code a value instead. A check can identify the hard-coded value and send the work back for another attempt before it is treated as complete. The designer no longer has to spot the same departure and restate the standard in the next prompt.
This changes the role of the design system as well. It is no longer only a source the agent draws from while making the interface. Its components, tokens and rules also become part of what the finished work is checked against.
Not every design decision can be handled this way. Checks work only where there is a clear condition to pass or fail. The rest still needs a designer.
Human judgment is a non-negotiable part of the process
Some design questions do not have a pass-or-fail answer. A harness can make their review more rigorous, but the findings should inform the designer’s judgment rather than become another gate the work must clear.
One way to do this is through an adversarial review, where a second agent is asked to question the first agent’s choices, look for inconsistencies and identify where the work may have drifted from its intended direction. The additional pass makes a level of scrutiny practical that time or team size might otherwise rule out, allowing the harness to improve quality by examining more of the work rather than simply producing it faster.
But another reviewer does not create ground truth. It can draw attention to a possible problem; deciding whether that problem matters still depends on the project.
We saw this in one of the examples we worked through with Omni. The darker end of a generated orange scale began to drift into red, something that became clearer once the colours were applied across an interface. Seeing the drift was one thing. Deciding that it was wrong for the project, and correcting it, still required human judgement. (Read more about how Omni works.)
Human judgment is therefore an important part of a design harness: agents can inspect and challenge the work, while the designer ultimately remains responsible for decisions that depend on intent, context and taste.
Designing the harness is itself an exercise in craft
Building a harness quickly reveals how much of a design practice still lives in people’s heads: which component is current, where an exception is deliberate and when a rule should give way to judgment.
Deciding what the harness should carry forward, and what it should leave to the designer, becomes part of the design work itself
Omni is where this work has begun for us. We are building the harness around our own practice at Canvs and putting it to work across projects. Our ambition is to turn that working harness into a product for other design teams, shaped and tested through the demands of real design work.
