Your AI Isn't Failing — Your Specification Is

When AI output disappoints, the bottleneck is usually not the model. It is the quality of what you specified.

This is written for anyone whose AI projects start well and then quietly derail — the ones that demo beautifully in week one and are unrecognisable by week six, without a single moment you could point to as the failure.

Something structural changed when models became capable of running autonomous tasks for thirty, sixty, ninety minutes at a stretch. In the short-prompt era, a bad specification produced a bad paragraph and you corrected it immediately. The feedback loop was tight enough that specification quality barely mattered. Now a vague instruction compounds silently for an hour before you see anything. Output quality has stopped being limited by machine capability and started being limited by human specification.

The map is not the territory

Drawing on Anthropic’s “Finding Your Unknowns” framework, the core principle is one that organisational development has known for a long time under a different name: the map is not the territory.

What you tell the AI is a map. The situation it actually operates in is territory — messier, fuller of exceptions, and shaped by a hundred things you know so thoroughly you have stopped noticing that you know them. The gap between the two is exactly where projects derail. Not in the model’s reasoning. In the space between what you meant and what you said.

What makes this hard is that the gap is invisible from the inside. You cannot review your specification and spot what you left out, because the things you left out are the things you never consciously held. That is not carelessness. It is what expertise does to a person.

The Rumsfeld matrix, applied to human–AI collaboration

The old four-quadrant frame turns out to be unusually useful here, because each quadrant fails differently and needs a different intervention.

Known Knowns

What you know that you know. This is the easy quadrant and the one everybody over-invests in — the part of the brief that gets written carefully, because writing it feels productive. It is rarely where the failure lives.

Known Unknowns

What you know you don’t know. Manageable, because you can name it. You can flag the open question, ask the model to surface options, or defer the decision explicitly rather than letting it be made by default. Most well-run projects handle this quadrant adequately.

Unknown Knowns

What you know but didn’t think to say. In my experience this is the single largest source of disappointing output in expert hands, and it is almost never diagnosed correctly. The regulatory constraint everyone in your team treats as obvious. The reason that approach was abandoned in 2023. The stakeholder who must be consulted or the whole thing dies. None of it is in the brief, because to you it is not information — it is background.

The tell is unmistakable: the output is competent, coherent, and quietly unusable. You cannot say what is wrong with it, only that it clearly does not understand the situation.

Unknown Unknowns

What neither of you knows. These are the project-killers, and no amount of careful specification eliminates them. What you can do is design so that they surface in week one, cheaply, rather than in week six, expensively.

Four techniques that actually work

1. The Blindspot Pass

Before executing, ask the model to interrogate your brief rather than follow it: what is ambiguous here, what am I assuming, what would you need to know to do this well? This targets Unknown Knowns directly, and it works because the model has no access to your background. What is invisible to you because it is obvious is visible to it as an absence.

2. The Reverse Interview

Have the model interview you before it starts — questions first, work second. This feels slower and is dramatically faster. It converts your unspoken context into stated context through the only reliable mechanism there is: someone asking. It is, almost exactly, what a good coach does, and it works for the same reason.

3. Throwaway Prototypes

Build something deliberately disposable, early, purely to find out what you were wrong about. This is your only real defence against Unknown Unknowns, because they cannot be reasoned about in advance — only encountered. The discipline is in the word throwaway: the moment a prototype becomes something you are reluctant to discard, it has stopped generating information and started accumulating sunk cost.

4. The Implementation Notes Log

Have the model record the decisions it made and the assumptions it relied on as it worked. This is the highest-leverage habit of the four and the least practised. Without it you review a finished output and can only judge whether you like it. With it, you review the reasoning — and you can see the precise point where a wrong assumption was quietly adopted, twenty minutes in, and everything after it followed logically.

Why this belongs in an org design conversation

It might look like a prompting article. It is not, quite.

Every technique above is a way of making tacit knowledge explicit — and that is one of the oldest, hardest problems in organisational development. It is the same problem as onboarding a senior hire, as handing over a role, as capturing what someone knows before they retire. We have never solved it well between humans, and we routinely lose enormous amounts of institutional knowledge to it.

What is genuinely new is the incentive. Tacit knowledge was always expensive to lose and easy to ignore, because the cost arrived slowly and could not be attributed to anything in particular. Now the cost arrives in ninety minutes, attached to a specific piece of unusable output. The feedback loop that never existed suddenly does.

The organisations that get the most from agentic systems will be the ones that get good at saying what they know. That capability was always valuable. It has just become measurable.

Framework credit: Anthropic, “Finding Your Unknowns”.

📚 Start here: AI-Native Organization Design — the full research hub, with every article and video in one place.

Watch the full series

This article accompanies a video from AI-Native Operating Model and Org Design — a series on how organisations actually absorb AI, and where they break.

Chunfeng “Breeze” Dong is an executive coach (ICF PCC, CPCC) and founder of Springbreeze Ventures, with twenty years in organisational development inside Fortune 100 companies — Roland Berger, Siemens, ABB and Roche. She writes on AI-native organisation design, human–agent governance and change leadership.

📘 The Living Organization · 📘 A Soulful Transition · 🔗 LinkedIn

Your AI Isn’t Failing — Your Specification Is