Brett Queener, a partner at Bonfire Ventures, uses “harness” at the scale of an entire product in his newsletter Tales from The Bonfire:

The Horse is the LLM model: enormously powerful, fundamentally unpredictable, not something you command so much as ride.

The Harness is the application layer fitted to that animal for one rider and the entire job that rider does, holding the ontology, the interaction model, and the learning loop.

The Hay is everything the horse and harness need to stay healthy at scale: orchestration, governance, cost routing, security, observability, data infrastructure.

The horse is the AI model. The hay is the collection of services that keeps it running. The harness is the product someone uses for the whole job. It holds what the system has learned about that job: the facts, relationships, exceptions, and rules Queener calls its “ontology.” It also decides which steps need the user’s attention and uses previous results to improve the next attempt.

The developer harness keeps its instructions, tools, and files stable while models change. Queener applies the same principle to an AI business. A company can use cheaper models for routine tasks and save the most capable models for difficult judgment. This keeps its cost of goods sold (COGS) low and protects its profit margins:

First, no smart harness maker will wed themselves to one model provider. Every good CTO I talk to has already abstracted the model away from the product. Not out of loyalty. Out of survival: which model is best changes every 60 to 90 days, and prices move by an order of magnitude.

Portability is also a margin discipline, and it’s most of the difference between the companies quietly running healthy gross margins and the ones complaining in public about COGS. A large share of what runs in production never touches a frontier model: classification, extraction, routing, summarization, retrieval. Reserve the frontier for the hard, ambiguous, high-stakes judgment and send everything else to a pony. Run every call to the biggest model because it’s easier and your gross margin belongs to somebody else’s price list.

The graph describes how jobs and results move through the system. Queener shows that the same graph can serve two roles. An off-the-shelf tool for coordinating any AI system is hay. Once a company fits that coordination to its own agents, rules, and way of working, it becomes part of the harness.

But coordinating the work is not enough. The harness must retain what it learns even when larger customers reach it through another interface, such as Claude, instead of a screen provided by the harness itself. It must also learn from results. Queener calls the tests that score its work “evals.” The system that feeds those scores and corrections back in so future behavior changes is the reinforcement learning, or RL, platform:

It owns the interaction model for that role. Not a chat box, and not necessarily a UI at all. What the rider is asked, what they approve, what they never have to look at again, what escalates and how. Which doesn’t require pixels: upmarket this increasingly gets consumed headless, rendered inside Claude or something the customer built on Vercel. Serve that, but treat headless demand as a scoreboard rather than an architecture, because yours is the surface holding the ontology and the loop and the memory of this rider, so its ceiling should be higher than a general assistant’s at your rider’s own job. The test is what survives a change of surface. Swap the front end next year: if everything they taught the system is still there, you were the harness. If not, you were endpoints with good docs.

It owns the eval and RL platform. The dividing line is whether a graded outcome changes future behavior without an engineer deciding what to change. Everybody has dashboards, and a human reading one and then writing code is a feedback process, not a loop. The test: can you point at a behavior your product has today that nobody on your team designed?

And it is singular. One rider, one harness. Nobody runs three of these at once any more than they drive to work in two cars. Not “fewer apps,” but one, per rider, per job.

It took Marek Minor about a year to redraw Cursor’s icon system: more than 600 icons in two sizes and two styles, with every exploration and final variant drawn by hand.

The scale only hints at the effort. Minor tested differences as small as 0.25 pixels, made 156 explorations of the hamburger icon, and tracked more than 155 recurring elements and visual properties. He also built the Figma files, migration dashboard, companion site, and release pipeline needed to migrate an old font with 645 codepoints without breaking references. Writing on his blog, he explains the construction method that holds the set together:

The icons in this set are closer to technical drawings than to organic shapes – diagrams with a friendly finish. The construction method is consistent across the set: start with lines that run horizontally, vertically, or at 45°, allow other angles where the concept demands them, then round the corners until the shape follows the idea. A cloud, for example, isn’t built from circles. It starts as straight segments that get rounded joins. A fire icon is built the same way, from angled segments with rounded corners. Freeform curves, or curves taken from circles, are extremely rare in the set.

This construction logic is what makes 600+ icons feel like the work of one hand. It also suits a coding tool: precise and engineered, with the rounded corners and round stroke caps keeping it from turning cold.

Thariq Shihipar, a member of Anthropic’s technical staff, offers a field guide for finding the context an agent needs before and during implementation:

The difference between the map and the territory is what I call unknowns. When Claude runs into an unknown, it needs to make a decision based on its best guess of what I want. The more work being done, the more unknowns Claude might run into.

Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.

Importantly, just planning ahead isn’t always enough. You can find unknowns deep in implementation, or your unknowns may point you to the fact that you should actually be solving the problem in a different way altogether.

The design-specific version is tacit judgment: criteria that become visible only after there is something concrete to react to. Shihipar’s recommendation is to use prototypes to surface those criteria while changing direction is still cheap.

When I’m working in an area with a lot of unknown knowns, involving criteria I only know to define when I see it, I like to ask Claude to brainstorm and prototype with me.

It’s extremely valuable to identify and verbalize unknown knowns early during prototyping, because finding them out during implementation can be (relatively) expensive. Small changes in a feature or spec can cause drastically different implementations in code, and it can be more difficult for your agent to revert previous changes.

For example, you may just want to see how a button added to a frame looks without having to wire up a backend route or maintaining additional state in the frontend.

This makes exploration part of specifying the work. The prototype helps the designer discover what the brief could not yet contain, while implementation notes preserve the choices that emerge after the plan meets the code.

The better models get, the more you can achieve with the right approach. When a long-horizon task comes back wrong, it’s likely you need to spend more time defining your unknowns or creating an implementation plan that allows for you and Claude to adapt through them.

Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn’t know before it gets expensive to fix.

Karo Zieminski spent nine days breaking Claude Cowork before writing this guide:

I’ve seen enough of shallow tutorials that simply rephrase the official docs to know I wanted to do something different. So I rebuilt some of my workflows from scratch, tracked what failed, measured what saved time, and mapped 56 practical tips into the resource I wish existed when I started.

I appreciate her methodical breakdown of the app, especially when to use which flavor of Claude, which for me TBH, has been an issue.

Zieminski’s nice breakdown of the differences between Claude Chat, Cowork, and Code.

The guide barely talks about prompting. It’s almost entirely about the pre-work: dedicated folder structures, global instructions via CLAUDE.md, chunked skills, delegation patterns that define end-states instead of steps. The distinction Karo draws between Chat skills and Cowork skills:

Skills in Chat were useful. Skills in Cowork are operational. They shape autonomous work. Your brand guidelines skill doesn’t just influence a reply. It governs every file Claude creates. Your writing guidelines skill doesn’t just shape a draft. It governs every article Claude writes autonomously.

Zieminski on skill architecture:

Chunk your skills instead of building one giant skill that tries to handle everything. I’ve tested both approaches and the results from one giant skill were much worse. For example, I use three separate writing skills instead of one: an overall voice skill, a corporate writing skill, and a newsletter writing skill. Each handles its own context. Claude never confuses who I’m writing for.

If you’re already using Claude Cowork or just Cowork curious, bookmark this one.

A harness is the environment around agentic work: the models, instructions, skills, tools, and files that let agents do the job. A graph describes how work moves through that environment. Anatoli Kopadze, writing an article on X, starts with two familiar parts:

A graph is just a plan for your AI work, drawn out so you can see it. It answers two questions: which jobs need to happen, and which job has to wait for which.

There are only two parts, and getting them straight fixes most of the confusion.

A box is called a node. It’s one job: one agent doing one task, with one thing going in and one thing coming out. Researching a competitor. Writing a draft. Checking a claim.

An arrow is called an edge. It just means one job needs what another job produced, so it has to wait for it. And the arrow only counts when something real actually passes along it.

That last condition changes how you design the workflow. A list written as “do A, then B” looks sequential even when B never uses A’s result. Kopadze’s test is to remove those false dependencies so independent jobs can run at the same time:

Look at the AI workflow you run today and walk it step by step. At each step, ask one thing: does this step actually need the result of the one before it?

If yes, the edge is real. Keep the order. If no, there is no edge, and the wait is wasted. Those two jobs can run at the same time.

Take a simple one: “review file A for bugs, then review file B for bugs.” It reads like a sequence, but the check on file B never looks at what file A returned. They only run one after another because that is the order you typed them in. Run them side by side and the whole thing finishes in the time of the slower single file, not the two added together.

This resembles building an automation in n8n: each node has a job, and the connections determine what data it receives and when it can run. AI adds another requirement, though. The agent checking a result should not inherit the worker’s reasoning and simply agree with it:

So you never let the agent that did the work check the work.

You put a separate node on the edge. Its only job is to try to kill the finding before it moves on. If it survives, it passes. If not, it dies right there.

Here is the catch nobody names: that checker needs a clean context.

Give it the same chat the worker had and it is not checking anything, it is nodding along to itself in a different font. A graph of agents sharing one context is just a single loop in a costume, and it breaks the same way, only later and pricier.

So make the verifier fresh. Own context. Checking a real signal, not “did the agent say it is done” but “does the test actually pass.”