Why Your AI Product Sucks

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, 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.

Hold that.

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. Half the industry is reaching the same conclusion with you.

Before you take the exit, look at what you'd be signing.

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. And once your product is consumed from inside their harness, instruction is theirs too: their defaults, their orchestration, their idea of how your workflow should run.

Shipping an MCP server instead of a product isn't dodging the fight. It is the surrender, formalized. You've volunteered to become the memory layer: one box of four, and the only one you hold by inertia, not craft.

To be clear: ship the MCP server. Agents are a distribution channel now, and being unreachable is worse. The surrender is the strategy that stops there, the roadmap that shelves native AI because “the agents will handle it.”

The problem was never the MCP. It's the chill.

Kept in its place, the server even pays you back: watch a general agent drive your tools, and it will show you, for free, exactly which decisions your native product needs to make.

Salesforce has already made this walk, on the record:

Eighteen months, smartest-in-the-room to landing zone. So the moat is that your customer's world is already stuck with you.

The labs are already shipping memory features.

What happens when they figure it out?

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. If the harness moves outcomes that much, and you hold the domain, the data, the distribution, and the right to tune every step for one workflow instead of all of them, then your native feature should beat a general harness that has never met your users.

Yes, 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.

And don't be intimidated by the general agent's tricks. Yes, 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.

The field tilts your way.

You just need to know how to swing.

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.

So what's the skill?

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 small 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.

For anything bigger than a small job, the repair loop is table stakes now. And read “conversation” as the loop, not the chat box: an editable preview, an inline suggestion, a one-click correction all qualify. The requirement is that 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

So here's the test, and you can run it alone. Five questions of the kind 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 and what the labs actually own — beyond the model anyone can rent — 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 in the same family as 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 product doesn't have to suck.

But somebody has to start making the decisions.