How to build an AI assistant for consultancies
6 minutes read
An assistant is a workflow with enough of a firm's own methods and sources built in that someone can hand it a brief and get a first draft that already looks like the firm's work. Here is what to define before building one.
An AI assistant for client work is a workflow with a firm's own methods, approved sources, and output format built in, so a person can hand it a brief and get back a first draft that already looks like the firm's work. Rather than one automated step, it bundles a small set of workflows and rules around one recurring kind of engagement, scoped tightly enough that a team member reaches for it instead of starting from a blank window.
That scoping is the part worth getting right. A tool that calls itself an assistant but answers anything, drawing on whatever it can find, is closer to a general chat window with a firm logo on it. The useful version is narrower: built for one kind of brief, restricted to the sources approved for that brief, and set to produce output in a shape a reviewer already recognises.
When a single workflow is not enough
A reusable workflow captures one repeatable method: the sources, the steps in order, and the shape of the output for one kind of task. Most recurring work only needs that. A competitor scan, a market sizing, a first draft of a recurring report: each is a single workflow, and building three separate ones for three separate tasks works fine.
An assistant earns its place when several related workflows, plus the judgement calls about which one applies, get requested often enough as a group that packaging them together saves real time. A team fielding new-client research requests, for example, might run a competitor scan, a positioning check, and a stakeholder brief on nearly every engagement, in a similar order, drawing from an overlapping set of sources. At that point, three loose workflows and a person deciding which to run and when is worse than one assistant that already knows the sequence and the source list for that category of work.
| A single workflow | An assistant | |
|---|---|---|
| Scope | One repeatable task | A category of related work |
| What it holds | Sources, steps, output shape for that task | Multiple workflows plus rules for which applies when |
| Typical request | "Run the competitor scan for this client" | "Start the new-client research for this engagement" |
| Best fit | Work that is already a single clean method | Work that recurs as a cluster of related tasks |
What to define before building one
Building an assistant means writing down more than a single workflow document does, because it has to cover the boundary of what it handles as well as the mechanics of how.
Scope: the category of brief it is built for, stated narrowly enough that a person can tell in one read whether a given request fits. "New-client research" is scoped. "Research" is not.
Sources: which external sources, prior firm work, and permitted client material it can draw from, and just as importantly, what it cannot touch. An assistant that can reach into every client's files because nobody restricted it is a data-handling problem waiting to surface, not a convenience.
Output shape: the sections, format, and structure the finished draft needs, matched to what a reviewer on that kind of work already expects to see.
Refusals: what the assistant should decline or flag rather than attempt, such as a brief that falls outside its defined category, or one that would need a source it is not approved to use. An assistant that quietly does its best on a brief it was not built for produces a draft that looks finished but is not, and a wrong-looking-right draft is harder to catch in review than one that simply flags the mismatch.
Owner: who updates the assistant's sources, steps, and output rules as the firm's methods change, the same as any workflow needs a named owner or it drifts.
A worked example
Take the new-client research case from above. Before it was an assistant, three consultants each ran their own version of a competitor scan, positioning check, and stakeholder brief, in whatever order and from whatever sources they personally favoured. Results varied by who was staffed.
Scope: new-client research for a strategy engagement, not a single-competitor deep dive and not ongoing account work.
Sources: the firm's prior scans for similar clients, the client's own positioning material, and a fixed list of public sources the firm has already vetted for this kind of research.
Steps: pull relevant prior scans for structure, identify the client's most relevant competitors from the brief, research each against the same set of dimensions, draft the comparison, then the stakeholder brief, then the positioning summary.
Output shape: a competitor comparison table, a one-page stakeholder brief, and a short positioning summary, in the order a reviewer expects to open them.
Refusals: a request for ongoing competitive monitoring after the engagement starts, which is a different, recurring workflow, not part of this assistant's scope.
Once this was written down and built as one assistant, any consultant staffed on a new engagement could start from the same setup instead of reconstructing it, or worse, reaching for whichever version their most recent project happened to use.
Where review still applies
None of this changes what happens after the draft comes back. An assistant produces a first draft built from defined sources in a known format. It does not decide that the draft is ready for a client. The person reviewing it still checks the sourced claims against the evidence, still applies the judgement the brief actually needs, and still signs off, the same as with any reliable client work built with AI.
What an assistant changes is the starting point. A well-scoped one means the reviewer is checking a draft built the way the firm already works, instead of a generic answer to a generic question. That is a better use of a reviewer's time, not a reason to skip the review.
