Vibe Marketing Needs a Harness, Not Another Model

The model is a shared input

A plumber in Leeds can ask ChatGPT to draft a post. The plumber across the road can ask the same model for the same thing. Both get competent copy. Neither has acquired much of an advantage.

Access to a good model is no longer scarce enough to be a marketing strategy. The useful differences sit elsewhere: what a business knows about its customers, what it has actually made, what it is prepared to say, and whether it follows through consistently. A model can work with those differences. It cannot supply them because someone opened a chat window.

That is why the argument in YC's Why The Harness Matters More Than The Model matters beyond coding. The same model weights, YC says, score 30% on ARC-AGI and then 95% with a better harness. The weights stay fixed. The surrounding system changes.

It's a coding benchmark, not a marketing one, but it puts the engineering question in the right place: before reaching for a more capable model, look at what the existing model can remember, access and execute.

In marketing, the model stopped being the differentiator earlier than almost anywhere else. Generating a plausible caption was the easy part. Turning that caption into useful, sustained work for a particular business is the part a prompt box leaves unresolved.

Rheos is the harness for that work.

Drafting is not shipping

A bare chat window has no reliable record of what the business published last month. It does not know which posts worked. It has the brand voice someone described in a prompt once, not necessarily the voice the business uses now.

Nor does it inherently have an authenticated connection to the right LinkedIn account, permission to publish there, or somewhere to record the result. Without that surrounding machinery, it can draft. It cannot ship.

The operator becomes the missing infrastructure. They find the previous posts, paste in the context, locate an asset, correct the tone, move the draft to a scheduler and check the result later. The model produces words quickly while the person carries state between disconnected tools.

That work does not disappear when the caption gets marginally better. It just becomes more conspicuous.

A harness is the environment that lets a model do useful work beyond its next response. It supplies context and tools, preserves state between sessions, and controls what happens when the model asks to act. In marketing, the unit of work is not a generated paragraph. It is a post moving from an intention to an approved publication, then becoming evidence for the next decision.

Treating the draft as the finished product leaves most of that loop outside the system. The person still has to operate it from memory.

Treat the model as the CPU

The sharpest reframe in the talk comes from Seth Karten's Prime Agent segment: stop treating the model as an oracle expected to hold everything, and treat it as a processor with external memory attached. Being "able to do these read and write operations on external memory", he argues, makes the system powerful on "another class of problems than just what a Turing machine is able to express on its own". The harness supplies the RAM, the layers of cache and the persistent memory. His design rule follows from it: "you want it to be the most expressible thing you can imagine".

That's a far better starting point for product design than asking how much brand information will fit in a system prompt.

For marketing, the brand is the state. Its voice, assets, content plan, previous posts and performance history need somewhere to live. Some of that state belongs in the immediate context. Some should be retrieved when relevant. All of it should not depend on a single conversation surviving indefinitely.

Rheos is the RAM and persistent memory for the brand in this picture. Not literally hardware memory, but the durable working environment around the model. A new drafting session should be able to pick up the business's work without the operator reconstructing the business from scratch.

The I/O is the operational side: authenticated platform connections, image generation, scheduling, publishing and analytics. Reading a previous post and publishing a new one are different operations, with different consequences. Neither is equivalent to generating text about doing it.

The CPU can change without the brand starting again.

Increasingly, that CPU can be the customer's own chosen model, in the client they already use. Rheos ships a real MCP server today, bringing its brand context and publishing tools directly into Claude and ChatGPT. The customer can work there rather than requiring every interaction to happen through a model Rheos operates on their behalf.

MCP provides the interface. It is not itself the memory, the connected account or the approval. The value sits behind the tool calls: a persistent brand and the means to act on its behalf. Swapping the model should not mean losing either.

Vibe marketing needs a working environment

Vibe coding became useful because the model had somewhere to work. The editor, file tree, terminal, test runner and diff made a request actionable and its consequences inspectable. Better models mattered. But model capability in isolation does not explain the difference between receiving a code snippet and changing a working application.

The files persist after the conversation. Tests can expose a bad assumption. A diff gives the operator something concrete to accept or reject. Those are properties of the harness, not hidden intelligence inside the weights.

Vibe marketing needs the same seriousness about its environment. The phrase already exists as a category; the useful argument is about what should qualify. Typing a prompt and receiving a caption is a generation demo. It is not yet a way to operate marketing.

A prompt-to-post demo without persistent state is the marketing equivalent of a coding model without a file system. Impressive for one turn. The next day, the work has to be reconstructed. Nothing has accumulated that makes the next request better informed.

For a marketing harness, the equivalent of a working tree is the brand's current plan, assets and publication history. The equivalent of execution is an actual platform action. Feedback comes from what happened after publication, not from a test suite.

Natural language is a useful control surface for that environment. It is not a substitute for building the environment. Removing buttons does not remove the need for state, permissions or a record of what happened.

One post, through the whole loop

Consider a hypothetical joinery in Leeds. This is an illustrative walkthrough, not a Rheos customer case study. The owner wants a LinkedIn company-page post about a fitted wardrobe installation, aimed at local homeowners.

They ask an agent in Claude, connected through the Rheos MCP server, to draft it. The owner supplies the project details and a photograph they took themselves. Rheos is creative tooling, not someone arriving to photograph the installation or an agency producing the business's visual content.

Before the agent writes, it needs the brand's state. Rheos supplies the context: a practical voice, the previous posts and what performed, and the connected account the business publishes through. In this scenario, posts explaining an awkward space have outperformed generic promotional captions, and the business posted about wardrobe materials just last week.

The resulting draft can focus on how the installation used an alcove without repeating last week's subject. It can use the business's established language rather than inventing a new personality. The model is composing, but the reasons for this particular draft come from outside its weights.

The owner reviews it. They remove a sentence that sounds too polished and correct a project detail. Then they give final approval. Only after that approval does the publishing step send the post to the connected LinkedIn company page. A caption in a chat has become an actual publication under the business's name.

Performance data from the published post comes back into Rheos. The publication history and its results become part of the state available to inform the next draft. The next request is not another cold start with the same brand prompt.

None of this means the agent has proved why the post worked. One response is not a causal experiment. But the operator and model now have evidence to consider, rather than a recollection that something similar seemed to go well.

The loop is the product. Drafting is one step inside it.

Approval belongs in the architecture

There is a limit to borrowing the coding analogy. Marketing has to sound right to a particular audience, at a particular moment, under somebody's name. Taste cannot be reduced to whether a tool call succeeded.

Coding has taste and social constraints too. But a technically successful marketing action can be the failure: the post published correctly, to the correct account, and embarrassed the person responsible for it. The API cannot tell you that a joke was inappropriate or that a customer relationship made an otherwise harmless detail sensitive.

The talk ends on exactly this problem, in the section on QM, YC's internal harness: "agents really don't understand social contexts". The example given is that telling a colleague something means they intuitively know where it is okay to repeat it, and "it takes some actual work to recreate this with an agent". The consequence is put plainly: "the information that you can put in the brain is effectively like bounded by how good your permission system is". YC has a fine-grained permission system built up over years to contain that. Most companies do not.

For marketing, this is not an unusual edge case. Choosing what to say, who should hear it and whose authority it carries is the job. An authenticated account establishes a technical ability to publish. It does not establish that a particular message deserves publication.

That makes human approval part of the architecture, not a safety feature bolted onto an otherwise autonomous publishing machine. The operator needs to retain creative direction and decide what they are willing to stand behind. A better model does not remove that responsibility.

Rheos keeps that division explicit. The platform does the planning and creation. The operator keeps creative direction and gives final approval before anything publishes. The harness should remove the repetitive work around that judgement, not pretend the judgement is unnecessary.

The model will keep changing. The brand's state, the publishing connections and the operator's responsibility remain. That is the work worth building around: a system that remembers, can act, and leaves the final word with the person whose name is on the post.