Your AI Feature Isn't Dumb. Your Harness Is

Agent = Model + Harness

The Paradox

You're the PM. You did the work. Two quarters of it. Discovery, specs, edge cases handed to engineering in tidy tickets. Your data, your embeddings, your carefully tuned prompts. You even wrote evals. You were one of the responsible ones.

The feature shipped. Then you used it.

It breaks the moment a request is ambiguous.

It forgets what it was told six turns in.

It answers from a script.

And one afternoon someone points Claude Code at the same job. Two MCP servers, one skill file, zero product context. It quietly runs circles around the thing you built.

Your product owns the data, the domain, the users.

The general tool owns none of it.

It should not win. It does.

The gaps that made your feature feel dumb were product calls. The kind that used to be yours.

MCP & Chill

Faced with that afternoon, a reasonable person reaches an obvious conclusion: stop competing. Expose your data over MCP, call yourself agent-friendly, and let the general agents do the work.

You'd be in good company. Your afternoon happened to the entire market in January. General agents had gotten good enough to do what much of SaaS does, cheaper, and investors did the math all at once: a rolling selloff, roughly $2 trillion, ugly enough to earn a name. The SaaSpocalypse.

Your paradox, repriced at market scale.

The cause hands you the lesson. If agents doing your product's job cratered the valuations, the fix is the better agent: yours, built on your data, your domain, your workflows. Make your offering better than the thing eating it.

The industry learned the opposite: make yourself easy for the thing eating you. Expose the platform, welcome the competition in, hope usefulness counts as strategy.

The right lesson: build your own agent.

The lesson learned: accommodate theirs.

Before signing up for the second one, read the contract.

An agent is a model plus a harness: the environment that turns a text generator into something that acts. The labs always had the model. MCP hands them your execution layer; that was its entire point. Consumed from inside their harness, instruction is theirs too: their defaults, their orchestration, their idea of your workflow.

An MCP server instead of a product isn't dodging the fight. It's the wrong lesson, formalized. You've volunteered to be the memory layer: one box of four, held by inertia, not craft.

Salesforce has made this walk, on the record:

Eighteen months, smartest-in-the-room to landing zone. The remaining moat: your customer's world is stuck with you.

The labs are already shipping memory features. What happens when they figure it out?

To be clear: ship the MCP server. Agents are a distribution channel now; unreachable is worse. Kept in its place, it even pays you back: watch a general agent drive your tools, and it shows you, for free, which decisions your native product needs to make. The problem was never the MCP.

The problem is the chill.

The SaaSpocalypse was the market asking one question: if agents can run the workflow, what is your software still for? Stop at the MCP server, and your answer is on record: storage.

You aren't surviving the SaaSpocalypse. You're justifying it.

You Should Be Winning

The other route: bring their model, build the harness yourself. Before you call that pride, price the harness:

Same model. Same weights.

The harness isn't a wrapper around the product; it's most of the product.

Now the arithmetic. The harness moves outcomes that much. You hold the domain, the data, the distribution, and the right to tune every step for one workflow instead of all of them. Your native feature should beat a general harness that has never met your users.

The labs employ some of the best harness engineers alive. That's the craft half, and they hold it. But craft is learnable, and your half isn't copyable. Be precise about which half that is. Not the data in your warehouse; the labs are coming for that. It's the judgment you only get by living in the domain.

Data exports. Judgment doesn't.

Don't be intimidated by the general agent's tricks. It can fork work and launch sub-agents; that's not the advantage. It is still discovering the decomposition during the run, inside a generic harness and one model family. You know the job before the first token is spent.

Which turns the paradox into an indictment:

We're losing on the learnable part.

The Skill Issue

Gamers have a word for losing with the better loadout: a skill issue.

Not the gear. Not the map. The player.

This skill has a name: harness engineering.

So what is it?

If products could be fully specified, every state documented in advance, the PM wouldn't exist. You'd hand engineering the document and go home.

The job exists because the document is never complete.

Any PM who has shipped a complex product knows this in their bones. The Figma covers two screens; the system has eleven states. The PRD reads complete until the legacy codebase throws up something nobody researched, and you're in a hallway, trading scope against a deadline.

No document authorized that call. You made it anyway, on intuition compounded over years.

Call them micro-decisions: closing the gap between spec and reality, one call at a time. They never appear in a document, and they compound into the product. That intuition was the asset you were paid for.

The missing skill is product intuition for a layer we have never lived in. Where a system will fumble, what a user will forgive, which ambiguity is real and which is a flow you were too lazy to define.

We built that feel for screens over fifteen years of shipping and breaking things. For this layer, we have shipped nothing, broken nothing, watched nothing run.

The intuition isn't depreciated.

It was never built.

Nobody's Name on It

Your AI feature has more of these unmade calls than any screen product ever did; non-determinism multiplies ambiguity. Here's one you didn't know you were making.

Does your feature get a conversational layer at all? A real one is hard to build, so we ship wizards instead: three steps, a spinner, one shot at the answer. Look at the math that choice signs you up for:

Then we measure “accuracy,” watch users turn away, and blame the system we knew was non-deterministic when we picked it.

You didn't decide against a repair loop.

Nobody decided. That's the point.

The repair loop is table stakes now for anything bigger than a small job. And read “conversation” as the loop, not the chat box: an editable preview, an inline suggestion, a one-click correction all qualify. The requirement: the correct 80% survives the fix.

It's also why the generic tool wins on page one: it's allowed to be wrong.

A confusing interaction gets pinned on the PM or the designer. On us. For the AI feature, we absolved ourselves: declared it a blackbox, moved the failure into the realm of weather. Each unmade call surfaces one expensive dev cycle later, filed under “the model is being weird.”

It's not a blackbox.

It's a stack of decisions with nobody's name on them.

Those decisions live in the harness, in the very layers we just watched everyone surrender. They set the quality your user feels, and the bill your CFO reads.

A Layer Down

Here's the test; you can run it alone. Five questions that never make it into a PRD:

• Does your user know enough to feed a strict flow, or does the answer only emerge from a back-and-forth that ends in a plan?
• Is your workflow defined enough to chain deterministically? If yes, which steps are you buying a model for?
• Which reasoning tier does each step deserve, and what is each action allowed to cost?
• What does the model see of your data: raw memory, an abstraction, or a pre-processed layer?
• What context can the product hand the model upfront, so the user isn't interrogated for what you already know?

Now pull up the last AI spec you wrote. Did it answer any of these? Or did it define point A, point B, and place a model-shaped capability between them?

Every interaction with the model is UI/UX now. Output quality is a product requirement. So is the reasoning bill.

The spec stayed silent because nobody knew these were decisions. That's the stack with nobody's name on it. It's also your job description, returned.

You can't answer them from a chair, and an eval won't answer them either: it grades a system you've decided not to understand: that it failed, never why. Intuition gets built the way it always was: watch things run, watch them break, make the calls.

If we were losing on structure, this essay would be an obituary. We're losing on the learnable part. That's the best possible diagnosis.

The Whole Magic

Strip the branding. Beyond the model anyone can rent, what the labs actually own is a conversational harness. That's the whole magic. Every other piece is already in your building: your MCP tools and instructions, your data, the customer specifics no lab will ever know.

In their harness, those made you a layer.

In yours, they make you an owner.

So learn harness engineering. Not to become the engineer; so your taste has somewhere to land. Nobody has written the manual, and the AI-PM guides out there are generic for the same reason your specs are: written from the chair. Two ways in.

Do it yourself. Clone openclaw, an open-source harness like the tools you already use. Point Claude at the repo and ask it to walk you through what the harness does around the model. An afternoon buys you half the vocabulary.

Or take the guided route. Part 2 opens the machine: nine parts, one dial. The dial trades reliability against the feeling of intelligence, and it's being set on your product right now, by whoever sits closest to the code. Part 3 runs the method on a real build, Yukta, down to the spec that fell out of it.

Your AI feature doesn't have to feel dumb.

But somebody has to start making the decisions.