AI for Consultants: Finding & Leveraging Patterns

Last month I was working on three completely different projects.

An assessment platform that needed to interview people about their motivation patterns. A tutoring system that needed to engage students in real-time. A content service that needed to extract stories from business leaders who don't know how to talk about themselves.

Three clients. Three industries. Three sets of requirements documents.

Same problem.

I almost missed it.

Instead, I saw a pattern. And that pattern is the difference between consultants who get commoditized by AI and consultants who become irreplaceable because of it.

Let me walk you through what I found.

Project One: Making Assessments Feel Like Conversations

MCode is our flagship motivation assessment. For years, it's worked the same way: you write down four stories from your life, then answer 32 questions about each story. The assessment takes about 45 minutes. It works. The insights are powerful. But the experience feels like homework.

I wanted to change that.

The vision was simple: collect the stories verbally instead of through writing, and conduct the follow-up as a real-time interview rather than a static questionnaire. Instead of 128 predetermined questions, the system would listen to what you said and ask the next question based on your actual response.

Simple vision. Complex requirements.

Here's what I discovered I needed:

An expert interviewer. Someone who knows how to engage a person in conversation, when to give space, when to prompt, how to make the experience feel natural rather than robotic. This isn't about reading questions off a list. It's about conducting a real interview.

A domain expert. Someone who understands motivation patterns deeply enough to recognize when a response is surface-level and needs probing. When you mention your brother in passing, the domain expert knows that family dynamics are often central to motivation patterns. They flag it: go deeper there.

A timer. Someone watching the clock. We can't let a single story consume 20 minutes when we need to cover four stories in a reasonable session. The timer creates gentle pressure to keep moving.

A producer. Someone orchestrating the whole experience. The interviewer wants to probe deeper. The timer says we're running long. The domain expert just flagged something important. The producer synthesizes these inputs and decides: probe for 30 more seconds, then transition.

Here's the thing: these four roles can't work sequentially. You can't have the interviewer ask a question, then wait for the domain expert to analyze, then wait for the timer to calculate, then wait for the producer to decide. By the time you've taken all those turns, three seconds have passed and the conversation feels broken.

They have to work simultaneously. The domain expert listens while the interviewer talks. The timer runs constantly. The producer synthesizes in real-time. That's what makes a conversation feel like a conversation.

I started designing the architecture for this. Parallel observers. Broadcast communication. Real-time synthesis.

Then the second project landed on my desk.

Project Two: Scaling Forty Years of Tutoring Expertise

A friend of mine has been tutoring students for four decades. He's developed proprietary methods, frameworks for engagement, ways of identifying where a student is stuck and exactly how to unstick them. His results are remarkable. His capacity is limited to the hours in his day.

He wanted to scale.

The vision: a SaaS platform that incorporates his methodology, engages students in real-time, and delivers his approach to thousands of students simultaneously.

I started mapping the requirements. And about ten minutes in, I stopped.

I'd seen this before.

An expert interviewer. Someone who knows how to engage a student, when to encourage, when to challenge, how to make learning feel like discovery rather than interrogation.

A domain expert. Someone who understands the tutoring methodology deeply enough to recognize when a student's response reveals a gap in understanding. When the student says “I think I get it,” the domain expert knows that phrase usually means they don't. They flag it: probe there.

A timer. Students have limited attention. Sessions have fixed durations. Someone needs to watch the clock and balance depth against time remaining.

A producer. The interviewer wants to explore an interesting tangent. The timer says we have five minutes left. The domain expert just identified a critical gap. The producer synthesizes: address the gap now, save the tangent for next session.

Same four roles. Same requirement for simultaneity. Same architectural pattern.

Different domain entirely.

The tutoring methodology would be different from motivation psychology. The interviewer's style would adapt for students rather than adults in self-reflection. The domain expertise would focus on learning gaps rather than motivation patterns.

But the architecture? Identical.

I started wondering if I was seeing a coincidence or a pattern. Then the third project showed up.

Project Three: Helping Leaders Tell Their Stories

Another friend runs a service for business leaders who struggle to differentiate themselves. They're experts in their field, but when it comes to talking about themselves, crafting a narrative, standing out on social, they freeze. They sound like everyone else. Generic. Forgettable.

Her vision: an online interview process that dynamically extracts the stories, perspectives, and experiences that make each leader unique. Not a questionnaire. Not a form. A real conversation that surfaces the content that will distinguish them.

I didn't even need to map the requirements this time. I knew what was coming.

An expert interviewer. Someone who knows how to draw people out, how to get past the corporate speak to the real stories underneath.

A domain expert. Someone who understands narrative and positioning well enough to recognize when a leader says something genuinely differentiating versus something generic. When they mention a failure that shaped their approach, the domain expert flags it: that's the story, go deeper.

A timer. Leaders are busy. The interview can't run indefinitely. Someone needs to ensure coverage across topics within the available time.

A producer. The interviewer is getting great material on one topic. The timer says we haven't touched three other important areas. The domain expert just heard something that could be the centerpiece of their entire narrative. The producer decides: stay here two more minutes, then pivot.

Three projects. Assessment. Tutoring. Content creation.

Three completely different domains. Three different clients. Three different end users.

One pattern.

The TV Studio Model

Here's what I was looking at: a production architecture that works exactly like a live TV interview studio.

Think about what happens in a real TV production booth. The host is on camera talking to the guest. But behind the scenes, there's a whole team. The producer is watching everything, ready to speak into the host's earpiece. The graphics operator is queuing up lower thirds. The floor manager is watching time. The research team is feeding relevant information.

And here's the key: they're all hearing everything simultaneously.

When the producer says “wrap it up” to the host, everyone hears it. The graphics person starts preparing the outro. The floor manager signals the guest. They don't wait their turn. They don't pass messages in sequence. They operate with ambient awareness, each specialist observing from their expertise, the producer synthesizing in real-time.

That's exactly what these three projects needed:

Broadcast communication. Every agent hears everything relevant. No waiting for messages to pass through a chain.

Parallel observation. The domain expert analyzes while the interviewer talks. The timer runs constantly. Nobody queues up for their turn.

Real-time synthesis. The producer doesn't wait until everyone has reported. They take what's available in the moment and make a decision.

Specialized expertise. Each agent does one thing well. The interviewer doesn't watch the clock. The timer doesn't analyze domain content. Specialization enables depth.

I'm sure there may be a formal name for this, but I call it the TV Studio Model, and once I saw it, I couldn't unsee it.

The assessment platform, the tutoring system, and the content service aren't three different architectures. They're three different skins on the same underlying pattern. The domain expertise changes. The interviewer's style adapts. The content of the conversations is completely different.

But the architecture is identical.

What This Means for Consultants

Here's where this gets relevant for anyone working as a consultant in the AI era.

The consultant who doesn't see patterns looks at these three projects and sees three builds. Three scopes of work. Three timelines. Three invoices. Maybe they're efficient enough to reuse some code between projects, but fundamentally, they're solving three separate problems.

The consultant who sees patterns looks at these three projects and sees one architecture with three applications. They build the TV Studio Model once, then configure it for assessment, configure it for tutoring, configure it for content creation. Each subsequent project takes a fraction of the time. The value compounds.

Now here's the thing about AI: it amplifies this difference dramatically.

AI can help you implement patterns at scale. If you've recognized that three problems share an architecture, AI can help you build it faster, document it better, adapt it to new domains more efficiently.

But AI can do more than that. It's great at pattern discovery.

Here's the thing, the systems looked and sounded different the first time I thought about them. Then, the more I dug into the problems I was solving, the closer my mind went to the TV Studio paradigm. All in a conversation with Claude. And when I finally suggested it, Claude was able to ask questions and refine the paradigm.

Human expertise isn't just intuition. It's also articulation. The framing of the framework. That's what clients actually pay for.

The consultants who get replaced by AI are the ones who execute without recognizing patterns. They're order-takers. They build what's specified. AI can do that, faster and cheaper.

The consultants who become irreplaceable are the ones who see what others can't see. They look at three “different” problems and recognize the underlying structure. They become architects, not implementers.

Here's a question worth sitting with: In your last five client projects, how many shared an underlying pattern you could have extracted, turned into a framework and reused?

If you didn't look for it, you probably didn't see it.

The Consultant's Real Advantage

The conversation about AI for consultants usually focuses on tools. Which AI should you learn? How do you use ChatGPT for client work? What about Claude? Should you build custom GPTs?

That's the wrong conversation.

Tools are commodities. Everyone has access to the same tools. If your value is knowing how to use ChatGPT, you're competing with everyone else who watched the same YouTube tutorials.

Pattern recognition isn't a commodity. It's built from years of cross-domain experience. It's seeing that an assessment platform, a tutoring system, and a content service are structurally identical. It's knowing that the solution to a client's “new” problem is actually a pattern you've implemented three times before in different industries.

AI for consultants isn't about collecting capabilities. It's about leveraging patterns and using AI to help create frameworks at scale.

The next time three “different” client problems cross your desk, pause. Ask: What do they actually have in common? What's the underlying structure? Is there a pattern here that I could build once and apply three times? Have that conversation with your favorite LLM.

The pattern you find might be worth more than any individual solution.

That's how you use AI without becoming replaceable.