The AI-native advice firm needs a better work queue

Start with the unfinished work

Consider an advice firm giving every employee an AI assistant while unfinished work remains scattered across inboxes, notes and individual memory. Drafting becomes faster. The review queue still depends on someone remembering to chase it.

A more useful definition of an AI-native operating model starts with the work: machine-generated output enters a controlled process with ownership, evidence and visible completion.

The licence count tells you how many people can access a tool. It says little about whether the firm can turn the output into completed client service.

Choose a workflow and define its states in ordinary language. Waiting for evidence, ready for review, approved for action and complete might be useful stages, provided the team agrees what each means.

Give each item an owner, supporting context and a clear next step. Define what moves it between states and what evidence is required for completion. Keep uncertainty visible rather than forcing every item into a confident status.

Then decide where AI can help: preparing a document, extracting a proposed fact, finding relevant evidence or suggesting an action. Each capability should improve a particular transition in the workflow.

Separate proposal from permission

A system able to generate a plausible answer is not automatically authorised to change a record or contact a client. Assign permissions around the action and its consequence, not around how convincing the output sounds.

For an early release, the system might prepare work and leave consequential actions to an authorised reviewer. Later, a narrow action could become automatic if evidence supports that decision and the firm can recover from failure.

Keep that expansion explicit. A useful drafting assistant should not acquire operational authority accidentally because someone connects another tool. This is our proposed design principle, not a claim that every workflow needs the same approval pattern.

Treat exceptions as product work

Every repeated exception teaches something about the process. Missing evidence might suggest a weak intake step. Frequent reviewer corrections might expose an ambiguous policy. Failed transfers might reveal an integration problem.

Track those categories and assign someone to reduce the causes. Otherwise the firm risks scaling the happy path while leaving people to absorb an expanding tail of difficult cases.

The FCA's ongoing-advice review focuses attention on delivery of services. That is a useful anchor for evaluating automation: the relevant finish line is completed work, not generated text. The review does not establish that AI is needed to achieve it.

The NCSC's AI-development guidance includes monitoring and update management after deployment. That gives the queue owner a further job: notice when a system change alters how work is created or routed. Review the affected transition after an update rather than assuming last month's behaviour will persist.

Measure the whole journey

Compare total elapsed time, staff effort, rework and unresolved items before and after a change. Keep the case mix visible so an easy pilot is not mistaken for evidence about the hardest work.

Also examine whether a quicker first step moves the bottleneck elsewhere. Faster drafting can increase the review queue. That may still be progress, but it changes the next operating decision.

An AI-native firm should be able to explain what its systems proposed, what they were allowed to do and how the work ended. Start with one queue where those answers are clear. Expand when the evidence shows the team can handle the result.

The aim is a firm that completes the right work more reliably. The assistants are useful when they help it do that.