The brief is never the brief.

You get sent a brief. It is detailed and earnest and almost always about the wrong thing. Not because the person who wrote it was confused, but because the brief is what they could write down. It's the surface of the problem, expressed in the language their procurement team will accept. The actual problem is sitting underneath, usually waiting for a quiet moment in the third meeting.

The first job on any AI engagement, before any tooling decision or any architectural diagram, is to figure out which problem you're actually solving. The one in the brief, or the one that wrote the brief.

What the brief usually says

"We need to use AI to summarise our documents." "We need a chatbot for internal Q&A." "We need to assess where AI can drive efficiency in operations." The wording is generic for a reason. Whoever drafted it has been told to come back with an AI initiative, and they've described a shape that AI can plausibly fit into.

Underneath, the actual ask is something more specific and more uncomfortable. It is almost always one of three things, and they're all variations on the same theme.

What the brief is actually about

One. Someone in the leadership team has spent the weekend on ChatGPT and is now nervous that the company is behind. The brief is downstream of an anxiety that hasn't been articulated. Half the engagement is calibration: what is genuinely changing, what is hype, what should they actually care about. If you deliver the document-summariser they asked for, you have not addressed the thing keeping the CEO up.

Two. A team has a process that nobody enjoys, and AI is the permission slip to fix it. The summariser nobody asked for is, on closer inspection, a way of admitting that the underlying intake form is hostile and the routing logic is broken. The AI piece is a Trojan horse for the operational reform that should have happened three years ago.

Three. The organisation has a knowledge problem dressed up as a data problem. The chatbot brief is really "our institutional memory lives in three Slack channels and four people's heads, and two of those people are about to retire." No model is going to fix that. What fixes it is a serious conversation about documentation, ownership and incentives, with the AI layer added afterwards as the interface, not the substance.

Why this matters for delivery

The temptation, especially under fixed-price scoping, is to build exactly what the brief specified and hand it over. It works in the short term. The client gets a thing. You get paid. Everyone signs off.

It tends to fall apart at month four. The thing you built does what the brief said, but the underlying problem is still there, and the client now has a sophisticated piece of software pointed at the wrong target. They are mildly resentful and not entirely sure why. You don't get the next phase.

The alternative is to spend the first two weeks of the engagement treating the brief as a starting hypothesis rather than a specification. Talk to people who didn't write the brief. Sit in the meeting where the work actually happens. Read the angry email thread someone forwarded you by mistake. The real problem will surface, usually much faster than anyone expects, and usually in a sentence that begins with "well, the honest answer is…"

The shape of the conversation

The conversation that gets you to the real brief sounds something like this. If we built exactly what's in this document and it worked perfectly, would your week be meaningfully different? Most people pause. The pause is the whole game.

If the answer is yes, build the thing. Ship it cleanly, charge fairly, move on. That happens about a third of the time and it's a clean engagement.

If the answer is "well, sort of, but…" you've found the actual problem. Now the brief becomes a working hypothesis you can refine, rather than a contract you have to deliver against literally. That's where the work that's worth doing lives.

One last thing

None of this is an excuse to ignore the brief. Clients don't appreciate consultants who substitute their own preferred problem for the one they were asked to solve. The discipline is reading the brief carefully, taking it seriously, and then asking the harder question about what it's standing in for. Both readings can be true at once.

Most of what makes consulting useful is just being willing to ask the second question.