If you commissioned a consultant this quarter (in Q3 2026), what would you actually be getting? And more so, what do you think you need help with? It’s a question I ask myself every quarter - as I stare at the “services page” on the website…
Two years ago the answer was fairly stable: a discovery, diagnosis, a strategy, a roadmap, and maybe someone senior enough to steer the delivery of it. Ask the same question today and the answer has changed shape dramatically. Not because consultants rebranded, but because the work underneath us did, both in capability (and expectation).
So, in this article, I want to look at what a consultant has to be now that nearly every engagement is, somewhere underneath, an AI integration engagement. And I want to make a case that sounds strange out loud: but is the most valuable thing a ‘modern consultant’ can say in the boardroom at the outset to a project… “I don’t know yet.”
Capability mapping stopped being about people
Start with capability mapping, because it’s the cleanest way in. Enterprises have mapped capability in their workforces for decades. Who can do what, where the gaps sit, what training or hiring closes these gaps and delivering these frameworks and training to correct the imbalance. It’s a mature discipline with a mature language, and it’s one I’ve spent a lot of my consulting time with.
What’s changed is the ‘enterprise population’ being mapped. The modern consultant isn’t just looking for gaps in the workforce any more; we’re looking for gaps in the infrastructure of how the work itself gets done. Because every business now runs two workforces, whether it knows it or not. The physical one, and a growing agentic one. Both have capabilities. Both have gaps. Both fail in characteristic ways and deterministic ways. And the mapping discipline that took decades to mature on the human side actually does transfer across surprisingly well.
I think it’s because the ‘build material’ has changed. We’re not talking code any more, we’re talking language. The working layer of an AI-integrated business is natural language sitting alongside commercial enterprise architecture, which means knowing how to speak, frame, construct and maintain an architecture of AI operations and humans in unison is the winning formula in 2026. That, for me, is the new consultant mandate.
Here’s a diagnostic rule from my own experience that shows how directly the ‘people discipline’ maps onto an agentic one. An agent can be the most capable thing you’ve ever deployed and still, occasionally screw up a simple task that even a first year graduate wouldn’t. Our collective gut reaction is to go hunting for the failure in the build, the deployment, or the training. More often than not, it’s just a context problem. The agent didn’t have what it needed to do the job, and no amount of rebuilding fixes that. Anyone who’s run a capability programme for people will recognise this instinct instantly, because we do exactly the same thing to humans: retrain the person, when the actual failure was the brief or the context of what (and how) we learnt the skill.
It’s okay not to know
Now the part that consultants aren’t supposed to say.
Walking into an engagement without knowing exactly how every part of it will work used to be disconcerting. The whole consultancy model is built on experience and certainty: the consultant arrives with the answer, packaged, referenced, proven, and de-risked. If a capability wasn’t already on the CV, you just didn’t win the work.
I think that model is a bit backwards, and I’ll go further: I think clients are learning to distrust it - especially in 2026. The landscape is moving too fast for anyone’s CV to be cookie cutter relevant. ‘Best practice’ in this space has a shelf life measured in months. And a consultant who claims certainty across all of it is learning on the job or describing an execution that’s SaaS (something you could have bought off the shelf).
PS - let’s be clear, I am not suggesting ‘learning on the job’ is acceptable, or warranted here, I am talking in terms of services, sprints and SOW lines. I am talking about inherent trust.
The analogy I keep coming back to is the surgeon. When a surgeon says they want to do exploratory surgery because they don’t yet know what’s going on, you don’t hear that as incompetence. You consent, precisely because their baseline expertise is high enough that digging around IS their domain, and the discovery is what gets you to the right diagnosis faster. That’s the trust structure the modern consultant works in. It’s okay to not fully know how something will work before starting it. And it’s okay to commission someone who doesn’t, provided their approach and their base capability give you reason to trust they’ll solve it. That, in a sentence, is my take on the modern consultant’s remit.
I’ll put myself inside this, because it’s not a theoretical position. I don’t have the skill set to hand-write deep code, and I’m relaxed saying so. What I do have is the ability to break any work stream into its component parts, find the knowledge gaps, and treat each one as something learnable inside the task itself. That tension and friction is how I’ve picked up NEW skills; debugging, evaluation metrics, architecture planning - functions that were never my nor the consultant’s domain, or the project manager’s, or the creative’s before. What we’re talking about is critical thinking and a digital native competency. The same thing that a capability programme maps.
What actually changes on the ground
This isn’t abstract. A few things from recent enterprise work, offered as independent patterns rather than case studies or war stories.
Because of AI - the desire for ownership and IP has flipped. We used to find solutions, map tech stacks, and connect the two. We now build inside the client’s own architecture rather than renting a third-party SaaS tool: their data, their application layer, their reasoning data, all staying in their domain. Meaning the delta of that business (their IP and data sovereignty) stops being the compromise you accept for speedy builds. Three years ago that wasn’t possible. Hell, six months ago it barely was. Now it is.
Security stops being the blocker everyone expects. In my experience the mood in the room changes the moment you work inside the client’s existing framework, and ask for no more permissions than you can realistically justify. The security lead who arrived braced for a fight becomes the most engaged person on the project. Trust, it turns out, is an architecture decision too.
And everything needs less scaffolding than everyone assumes. The consistent lesson of the last year of discovery and building: we tend to over-engineer when there are too many stakeholders in the project chain. Capability, we assumed, would need heavy model training, but it turns out to be reachable with well-chosen exemplars and a simple rubric. Which makes the result faster, cheaper and far less dependent on any one platform or model - but only if someone in the room knew to challenge the typical assumptions. And that challenge is a capability-mapping call more than a coding one. And before you shout me down - I realise that scale and rigour require deeper conversations around scaffolding, security, monitoring, and evaluation. I’m not talking about the deployed end here, we’re building flexible foundations that we expect to evolve in months - to potentially undefined directional ends.
The service line that won’t fit in a paragraph
Here’s the conundrum this leaves consultants with, and I feel it every time I open the website. Go too broad and you look untested, unverified, a generalist (in the bad sense of the word). Go too specific and you miss the client’s expectation entirely, because they weren’t shopping for that skill in the first place. The capability (with AI) we’re now carrying is fuelling an almost-ADHD character: we can grow anything - if we seed the ground with a thousand different plants without ever asking which crops actually grow together well - we are getting a messy yield. But, if you know what to plant and where - it’s a powerful time to know a competent consultant!
So let me say it plainly, as a service line. The modern consultant maps capability across both workforces, human and agentic. Builds the context and the harness that let each do their best work. Prototypes the answer rather than just describing it in slides. Spots what’s just become possible that wasn’t six months ago. And then - the part I’d argue matters most, and the part most engagements skip - hands it off properly: introducing the agentic workforce to the physical one, and teaching the team the rubric and the architecture well enough that they can support it, extend it, and stop needing you.
That last beat is where this all connects back to capability development in the traditional sense. The handoff is a learning problem long before it’s a technical one, and it’s the beat I’d want a board to hold me to.
What to ask for when you commission a consultancy.
If you’re the one doing the commissioning, the test has changed. The old test was “have you done exactly this before?” The better test now is closer to the surgeon’s: is their baseline experience deep enough, and is the approach candid enough, that not-knowing becomes an asset rather than a risk? A consultant who tells you precisely how everything will work before touching your infrastructure is reading you the past. One who shows you how they’ll find out is offering you the actual discipline.
The work has changed shape; the judgement underneath it hasn’t. And if the last two years are anything to go by, the consultants worth commissioning next year will be the ones comfortable saying which parts of next year they can’t yet see, right?
