A field guide that takes your firm from scattered personal use to AI running real work reliably. You don't read it front to back: you find where you actually are and start there.
Which recurring tasks actually drain your week? You have the basics; the value so far is real but scattered. That is the norm, not a failing, and this altitude is where it stops being scattered.
Most people meet AI as a curiosity: a poem on demand, a recipe from leftovers, a quick answer to a trivia question. The working version is less flashy and far more valuable. This section shows the shape of the opportunity, with one rule of thumb: if the work is made of language, a model can carry part of it today.
This is where a model is strong today: it does in minutes what costs a person hours, and it does not tire on page two hundred.
Reading forty contracts and returning every notice period and renewal date in one table.
This stays yours. The model prepares the decision: it gathers, drafts, and compares, so you decide with better material in less time.
The model summarizes the settlement options overnight; which one to recommend is still your call.
Most professional jobs are a braid of the two, which is why the gains land everywhere once you look for them.
This needs no setup, no connected systems, and no permission from anyone: the account you already have is enough, and free plans are enough to feel the gain. One honest caveat before you rely on it: the model is weakest where a single exact fact or figure must be right without checking, which is why the working habits in the next section matter.
If the work is made of language, a model can carry part of it today, across every desk in the firm. Start with one recurring task this week; the account you already have is enough.
The difference between a party trick and a working tool is how you talk to it. Getting access takes minutes: any of the mainstream tools, in a browser, and a free account is enough to learn on. This section teaches the working habit, with one rule of thumb: brief it like a colleague, review it like a junior's draft.
You get something generic, because it knows nothing about your situation beyond the sentence you typed.
Write a follow-up email to a client.
You get something usable, because the model works from your facts and your constraints instead of guessing them.
Here is the thread and our proposal; draft a follow-up that answers their two objections, in my tone, under 150 words.
Most disappointing first experiences with AI are questions that should have been briefs.
The loop gets far more useful once the model stops being a stranger to your work, which is the next section.
Brief it like a colleague, review it like a junior's draft, and make "look it up" your reflex. The loop is the skill; the tool is just where you run it.
A model that knows nothing about your business starts every chat as a stranger. This section shows you how to give it your world once, with one rule of thumb: set up what it should always know, connect what it may see, and keep both under your control.
Standing instructions, project spaces, and memory carry your background from session to session, and you can read and edit what is stored.
It knows your firm's services and your tone rules without being told again every morning.
Through connectors it can read or act in your calendar, files, or inbox, always inside the access you granted.
It reads this week's calendar and drafts the Friday summary from what actually happened.
Context is what it knows; connections are what it can see and do. With both set up, whole categories of asking disappear.
With your world attached, you can stop asking questions and start handing over whole tasks, which is the next section.
Give it your world once: standing instructions, project spaces, and the narrowest connections that do the job. What it knows and what it may touch stay decisions you make, not defaults you inherit.
Questions save minutes; delegated tasks save hours. This section shows you how to hand over a whole piece of work, with one rule of thumb: delegate the task, keep the judgment.
You ask for a sentence here and an idea there, so the task's shape and its hours stay yours.
Polishing one paragraph of the proposal you spent the afternoon writing.
The model produces the full first version; your time moves from producing to directing and certifying.
Handing over the whole proposal first draft: the brief, the client notes, the outline, then reviewing what comes back.
The real hours live on the delegating side of that line.
Tasks you delegate well once are worth making repeatable, which is the last section of this stage.
Delegate whole tasks with a real brief, and review like the work still carries your name, because it does. The hours come back on the delegating side of the line.
The first delegation is an experiment; the fifth should be a routine. This section shows you how to keep what works, with one rule of thumb: when something works twice, capture it so it works every time.
Next month someone rebuilds it from memory, a little differently, with a little less of what made it work.
The brief that produced the best proposal draft so far, somewhere in March's chats.
Saved as a skill or a template, it runs the same way every time and can be handed to a colleague.
A saved "proposal first draft" instruction that anyone at the firm can run on a new client brief.
Capture is the difference between being personally faster and building something the firm keeps.
This is also the point where paying for the tool earns its keep. A free plan carries you through the working loop; the machinery of capture and context, project spaces, connections, saved skills, and scheduled tasks, mostly lives on the paid plans, from about twenty dollars a month per person. You are not paying for a smarter chatbot; you are paying for the features that turn a chatbot into a delegation system.
That library completes this altitude's outcome; the altitude close below says what operating well here looks like.
When it works twice, capture it: templates, skills, scheduled tasks. Personal speed fades with the person; a library compounds.
One professional habit as the library grows: know what your tool does with what you paste. Two minutes in the data settings tells you whether conversations are used for training and how long they are kept; check once, choose deliberately, and the question is settled. Client material deserves the same care in an AI tool as in any other system, and when colleagues start following you onto the tool, business terms are the natural next step. The later stages pick that up.
Most readers should run at this altitude for a while, and staying here is fine. Operating well at Stage 1 looks like: the setup is trusted, the delegation habit is real, and the starter library grows on its own. Stage 2 is there for the day a shared workflow needs more than personal leverage, not because a next stage exists.
This is where AI stops being a personal trick and becomes something the firm does: one shared workflow, with a quality bar that survives the enthusiast leaving.
Stage 2 starts with a choice: which workflow gets your firm's first real AI effort. The scarce thing is not opportunity; a working firm trips over automatable work daily. The scarce thing is choosing well. This section turns the pile into one commitment, with one rule of thumb: list broadly, filter hard, win one.
If Stage 1 ran its course, part of the list writes itself: the tasks people already hand to a model on their own are votes for what the firm should automate properly.
It is usually judgment-heavy, exception-rich, and tangled in half the firm's systems, which is exactly why it fails as a first build.
An assistant that handles the whole client relationship, from first enquiry to renewal.
It runs often enough to judge, has a clear start and finish, and a mistake is cheap to catch, which is exactly what a first build needs.
Drafting the first version of every proposal from the intake notes.
The filter below turns that instinct into a checklist.
Score each survivor on both, and take the first workflow from the high-impact, low-effort corner. Impressive-but-heavy candidates keep their place on the list; they are what Stage 3 is for, after this win has built the muscle.
Typical first picks include proposal drafting at an agency, first-line support replies at a software business, the seasonal crunch at an accounting practice, and after-hours enquiries at a local service firm. Treat these as places to look, and test whatever you find against the seven tests.
Once the workflow is chosen, the next move is to map it as it really happens.
Candidates are everywhere; choosing is the skill. List broadly, filter with the seven tests, rank by impact against effort, and commit to one bounded task.
You have chosen the workflow; before anything gets built, it needs a map. This section shows you how to make one in a week, with one rule of thumb: capture the work as it actually happens, together with the number it actually costs.
It lives in handbooks and job descriptions, written from memory, often by someone who no longer does the work.
The handbook says every enquiry is logged in the system before anyone replies.
It includes the workarounds, exceptions, and shortcuts people have built over time, and those are exactly what an automation trips over.
In practice, urgent enquiries go straight to a senior's inbox and get logged afterwards, when there is time.
Map the real one. The gap between the two is where the surprises live.
Writing a process down from memory produces the official version. Recording it produces the real one, including the steps nobody thinks to mention.
An automation is only as good as the data it reads, and people repair bad data without noticing they do it: they spot the stale price, remember that this client's address is wrong in the CRM, fill in the field the form left empty. That silent repair is part of the real process, and it disappears the moment a machine runs the step. The old rule "garbage in, garbage out" gets sharper with AI in the loop, because a model handed wrong data does not stall the way a script would; it produces something plausible from it.
The baseline is one real week of the workflow, counted, not estimated. A tally in a shared sheet is enough; the point is that the week is counted while it happens, not remembered afterwards.
Formal mapping traditions exist for all of this, from SIPOC tables to swimlane diagrams to the ISO-standardized process notation, and you do not need any of them. Borrow their three good ideas, listed below as parts of the finished map, and hold the whole thing to one page in plain language. The bar: a new colleague could run the workflow from it.
With the map and its baseline in hand, the next move is choosing the simplest way to automate what you just mapped.
The map is an asset, not admin. Record the real process, check the data it runs on, count a real week, name one owner; everything you build next stands on it.
Your map from the last section lists the workflow step by step. This section shows you how to pick the right amount of automation for it, with one rule of thumb: give every step the simplest tool that can handle it.
These steps run identically every time, so the rule can be written down and handed over.
When an invoice arrives, it goes into the client folder and the amount is entered in the sheet, the same way every time.
Something has to be read, weighed, or worded before the step can happen.
Answering a customer complaint, summarizing a call, or deciding whether a request is urgent.
Mark each step as one or the other. That split does most of the choosing for you.
When is the agent right? If the steps in your map hold for nearly every case, automate them as written. If the rules keep sprouting exceptions until nobody can hold them all, that stretch is agent territory, as in a support inbox where the right response depends on who is writing and what has already happened.
The choice follows the map. Ready-made earns its place where your workflow looks like everyone else's; everywhere the workflow is part of how you win and keep clients, building to fit is the stronger route, and it has never been more attainable.
Where it runs is a separate choice: a vendor's cloud, or systems you run yourself. Data sensitivity, what you already run on, cost at your volume, and who can maintain it all weigh in.
How you prove the new setup beats the old one is the next move: the pilot.
Rules for the steps that never change, AI for the judgment steps, an agent for the stretches that vary. The simplest combination that covers your map is the right one.
The new setup exists; now it has to prove itself against the baseline from move two. This section shows you how to run that proof, with one rule of thumb: run the new way beside the old way, and decide before you start what result means go.
Nothing breaks while you learn, because the old route still produces the real output.
The model drafts the reply, and this month someone still writes theirs as usual; you compare the two.
Everything now depends on a setup nobody has watched under real load, and the way back is improvised.
The old drafting routine is dropped the same week the automation goes live.
Pilot in parallel; switch only after the pilot has passed. The comparison is the whole point of the exercise.
A pilot that passes earns the rollout: making the new way the default is the next move.
Run the new way beside the old, judged by the people who do the work against the counted baseline, with the pass mark set before you start. Stopping is a legitimate result.
The pilot passed; now the new way has to become the way the work is done. This section covers the rollout, with one rule of thumb: a workflow is rolled out when it is the default, not when it is available.
Every old step survives and new ones are added around the tool, so the workflow ends up with more steps than before.
The model drafts the reply, and the draft then passes through every step the manual version had, plus a new review of the draft itself.
Steps that existed only because a person had to do the work by hand are removed rather than preserved.
The meeting where drafts used to be assigned disappears, because the drafts now exist before it would have started.
Rebuild rather than bolt on. If the old process survives untouched beside the new one, the gains stay cosmetic.
Whether the rolled-out workflow keeps earning its place is the last move: measuring the win.
Rolled out means the new way is the default, someone owns its health, and the way back exists. Rebuild the workflow around what runs on its own; don't bolt the new tool onto the old routine.
The workflow runs; the last move decides what it earned. This section shows you how to measure one workflow's return, with one rule of thumb: count verified outcomes against the baseline, and let that number make the keep, revise, or retire call.
It is easy to count and comfortable to report, but a busy tool and a better workflow are not the same thing.
The team runs the drafting step on almost every proposal now.
It counts only when the work product passed the person who signs off on it, at the quality the firm actually ships.
Most drafts go to clients with light edits; the ones rewritten from scratch are counted separately.
Report outcomes. Adoption tells you the tool is alive; outcomes tell you whether the workflow won.
With the dossier complete you have run the whole loop once; operating well at this altitude is a destination in itself, and the next constraint is where the loop runs again.
Count verified outcomes, not usage, and price them against the baseline. The number, not the mood, makes the keep, revise, or retire call.
Many firms should operate here, and some should stay. Operating well at Stage 2 looks like: the workflow runs as the default, its dossier is current, its number gets checked monthly, and no heroics are involved. Stage 3 is there when the next constraint genuinely needs machines acting unattended, not because a next stage exists.
You have won once. Now the loop runs again and again, and the route ladder extends up into automation and agents, with the rule that saves the most pain: rules before agents.
Stage 3 lets machines act without someone watching each run, and what they act on is your systems and your data. This section gets both ready, with one rule of thumb: grant the least access that does the job, and fix unfit data before you build on it.
Fine at Stage 1: the blast radius is your own inbox, and you see everything it does.
The assistant that reads your calendar to draft your week's plan.
It gets its own login and its own narrow permissions, so what it can touch is decided, recorded, and revocable.
The invoice automation reads the accounting system every night under its own account, with invoice access only.
The difference is not the tool; it is the accountability around it. Stage 3 runs on business connections.
Three habits do the work here, and none of them needs a security team. Give each automation the least access that does its job: the invoice workflow reads invoices, not the whole accounting system. Give it its own login rather than borrowing whoever built it, so the access survives that person's departure and can be switched off without touching anyone's account. And never let one system hold all three of: access to private data, exposure to content outsiders can write, and a way to send data out; drop any one of those legs and the worst case collapses.
The proposal drafter reads the CRM and the template folder under its own login, and nothing else. When its builder changes jobs a year later, nothing about the automation changes, and nobody has to remember what was connected through her account.
Stage 1 gave your personal AI its world; this altitude gives the firm one. The firm-scale version is deliberately low-tech: a small set of plain documents the firm owns, in a folder the firm controls: what the firm does and for whom, how it writes, its service conventions, the decisions people keep re-explaining. One routing file on top tells any tool where to look first. Every workflow in this stage starts informed instead of briefed from scratch, and because the files are ordinary documents rather than any vendor's memory, the asset survives every change of tool and model underneath it.
A "how we write" file, a services-and-pricing file, and one page of conventions per major client. The routing file says which applies when. The new intake automation reads it on day one and drafts in the firm's voice from its first run.
Context ages the way data does, so it gets the same discipline as everything else that runs unattended: a scheduled job folds each week's new decisions in and retires what has expired, a periodic check catches duplicates and contradictions, and one named person approves what changes. A firm that adopts a shared context layer without that maintenance owns a contradictory, expensive mess within a quarter.
With access scoped and data triaged, start automating, and start with the predictable work: the next section.
Least access that does the job, an identity of its own, no builds on unfit data, and a context layer the firm owns. Machines act at machine speed; readiness is what makes that a feature.
The fastest wins in this stage are not the cleverest ones. This section is about the predictable work, with one rule of thumb: automate the steps that never change before the ones that think.
Three things make them the right start. The rule already exists, on a checklist or in someone's head, so automating it is transcription rather than invention. They fail loudly and fix cheaply: a file in the wrong folder is visible and reversible in a way a wrong judgment is not. And every step a plain rule handles costs almost nothing per run, which starts to matter once the platforms below begin metering your volume.
A large delivery company automated one boring internal task: account-unlock requests. Around eight hundred a month, each dropping from thirty-five minutes of a person's time to twenty, roughly two hundred hours a month recovered, and the build took five hours on a standard automation platform. No cleverness anywhere: plain rules, with manager approval kept exactly where it was.
The unit matters more than the sticker price: the same workflow can be cheap on one meter and expensive on another. Model a month of your real volume on each before committing.
Two practical companions to that ladder. First, keep the familiar front end: if the team lives in a spreadsheet, let the new workflow read and write that same spreadsheet instead of forcing a new screen; the machinery changes underneath while the habit survives. Second, know the bulk-work boundary: working through a list inside a chat tool, with a person reviewing, is comfortable up to somewhere around one or two hundred items a run, at real usage cost; past that, or the moment nobody reviews each item, the job belongs on an automation platform built for volume. Treat both figures as practitioners' rules of thumb, not physics.
The safe first taste of generative AI inside automation is production work: one approved brief becomes many drafts, variants, or formats, produced by a model inside the workflow. What makes it safe is the brand gate: a person or a hard checklist that everything passes before it leaves the building. The shape is predictable even though the content varies, which is why it belongs in this section.
Once the predictable work runs itself, the interesting question is the varying stretch in the middle: your first agent, next section.
Automate the steps that never change first: they are specified, cheap to run, and cheap to fix. Know your billing unit before the bill teaches it to you, and size every build by what happens if it breaks.
An agent is the first thing you will run that chooses its own path through the work. This section is about the first one, with one rule of thumb: give it a narrow job, real boundaries, and a suggest mode to prove itself in.
First, one word that means two different things. The popular beginner courses use "agent" for a chat persona with standing instructions, and if you have built one of those, that was real work; keep it. This stage means something with more consequence: software that acts in your systems, toward a goal you set, choosing the order of its steps within your rules, without you watching each pass. The caution in the next three sections is about the second kind, and it would be overwrought for the first.
Give a chat persona a mandatory stop phrase and make it end every session with a short report of what it did and where it struggled. You have just rehearsed ceilings, off-switches, and logging, the whole grammar of the next section, at zero stakes.
Inbox and ticket triage is the classic first agent for exactly these reasons: constant volume, quick to check, cheap to correct.
It does the reading and the routing work, while every outcome still passes a human hand.
The agent labels each ticket and proposes a reply; the team sends it or fixes it.
Act mode is earned, not assumed: a category moves up when its suggestions have stopped needing correction.
Routine password-reset tickets route themselves and get the standard reply; anything unusual still goes to a person.
Start every agent in suggest mode. The path from suggest to act is the whole subject of the next two sections.
The harness that makes this safe to leave running is the next section.
First agent: one narrow, frequent, checkable, low-stakes job, launched in suggest mode with its job description written first. Capability is easy to get; the definition is the work.
Everything in this stage that runs unattended needs a structure that keeps it dependable. This section builds that structure, with one rule of thumb: give every unattended run a ceiling, a logbook, and an off-switch.
Four working practices make the harness real for agents specifically. Have the agent produce structured output, a table or a labeled list an owner can audit line by line, rather than prose that can hide a wrong call inside a nice paragraph. Require it to report obstacles instead of improvising around them: "could not find the May invoice" is a good result, while a guessed invoice number is not. Keep its toolkit minimal, because every tool it holds is something it can use at 2 a.m. with nobody watching. And treat shared skills and plugins as what they are, software from the internet: read what one does before installing it, because skills can run tools and execute code.
The triage agent ends every night with a table: ticket, label, action taken, and one plain line at the bottom, "3 tickets skipped: sender not in the client list." That skipped line is the practice working. Obstacles reported, not improvised around.
One special case deserves its own fence: an agent that operates a computer directly, screen, mouse, and keyboard. If you experiment there, isolate it like a contractor on day one: its own user account, a machine that holds nothing else, access granted surface by surface, and a hard payment ceiling if a card goes anywhere near it.
Someone runs this machinery, and deciding who is part of hardening. On a managed platform the vendor keeps it alive while you own the definitions and the checks; that is the practical answer when volume is modest and nobody wants server duties. Running it yourself buys full control of your data and of cost at volume, and it is a real operating job: updates, backups, monitoring. Data sensitivity, what you already run, volume, and who would honestly maintain it make the call; the full where-should-it-run question, including the middle ground between those two poles, gets its own treatment in Stage 4.
Hardened, an automation can start earning more autonomy, one step at a time: the next section.
Ceilings, off-switch, logbook, runbook, and a scheduled look at what it is actually doing. The harness is what makes unattended work dependable.
Autonomy is not a setting you switch on; it is trust the system earns, category by category. This section builds the ladder, with one rule of thumb: promote on measured performance, and keep some doors permanently human.
Promote one category at a time, when its correction rate has been low and stable for long enough to mean something, against a bar you set before you started. If corrections rise after a promotion, the category moves back down; demotion is maintenance, not drama.
Password-reset tickets ran six weeks in suggest mode with corrections near zero, earned a month of act-with-review, and now act and report. Refund requests live in the same inbox and will never leave suggest mode: money is a permanent door.
Worth saying plainly: this ladder is more ambitious than what the model makers teach their own customers, whose courses keep a person in the loop at every tier and stop there. The difference is deliberate, and it is not bravado; it is the gate. Autonomy here is never promised and never assumed. It is graduated category by category on correction rates you can show, and revoked the same way; the graduation bar, and the demotion that mirrors it, is the part most advice skips.
These gates are not training wheels that come off later; they are the design.
With trust building workflow by workflow, the remaining question is how the portfolio grows: the last section.
Autonomy is earned per category, against a correction-rate bar set in advance, and some doors stay human by design. Demotion is maintenance, not drama.
Expansion is not one big program; it is the same loop, run again on the next constraint. This section is about growing well, with one rule of thumb: every workflow gets the full loop, and everything that runs gets watched.
The map from Stage 2 is the brief for every build in this stage: watch the work as it really happens, count a real week, name one owner. Two sentences of that method carry the whole discipline: map the real process, and no baseline, no build.
The Friday pipeline digest broke in March and nobody noticed until May, because a missing nice-to-have looks exactly like a quiet week. The fix took an hour. The two months of decisions made without it did not.
When enough runs that keeping the list current is itself a job, you have arrived at the operating engine: Stage 4.
Grow one constraint at a time, run the whole loop each time, and watch everything you leave running. The current, owned list of what runs is the door into Stage 4.
Operating well here is a complete destination. It looks like: several workflows running under real harnesses, an autonomy log that says what earned trust, and monitoring that catches drift before clients do. Stage 4 is there when keeping the whole picture current becomes its own job, not because a next stage exists.
What changes when AI stops being a project and becomes something you rely on. What this stage builds is light: documents and routines, not platforms, and far lighter than the governance genre implies. Most firms have none of this, which is exactly the opportunity.
If you self-located straight to this stage, here is what the engine gathers up: the personal collections of prompts and instructions become one shared library, the notes on each automation become one list, the guardrails around each build become one page of rules, and the measuring of each workflow becomes one review of the whole. Each earlier stage teaches its piece in full; this stage only assumes they exist somewhere, however informally.
The operating engine starts with two short documents: the rules, and the list of what runs. This section builds both, with one rule of thumb: write down what is allowed and what is running, and keep both current enough to trust.
Six short sections cover it: scope, approved tools, data that never gets pasted, where a person signs off, who fields questions, and when this page is reviewed next.
Client financials never go into consumer tools; the approved tools are listed below; the operations lead fields questions.
One entry per automation: what it does, who is responsible for it, what data it touches, where it runs, where its instructions live, and whether it is still in use. Keep it wherever the firm keeps its working documents; what matters is that there is exactly one.
Anyone can open it and know what runs, who looks after each one, and which ones were retired.
The policy is the rules; the register is the reality. Together they answer the two questions every serious client, insurer, or regulator asks: what do you allow, and what actually runs?
The most important thing on the list is the name next to each entry. An automation nobody is responsible for runs until it breaks, and then fixing it is nobody's job, which in practice means it stays broken or quietly keeps producing the wrong thing. One person per automation, someone who knows the workflow and answers for it; when that person leaves, the entry gets a new name the same week or the automation gets retired. The same goes for the documents your automations rely on as their source of truth, such as a price list or a description of your services: name who may change those, because a quiet edit there changes what everything built on them does.
The "how we price" document feeds three automations, and the register names the operations lead as the person who owns it. When a partner wants a rate changed, the change goes through her, and all three automations change behavior on the same deliberate day instead of drifting one by one.
The biggest software vendors have started building this same kind of inventory into their own products, because even they found that nobody could reliably say what was running. Yours can be far simpler and do the same job. It is also the answer sheet you will be asked for: when an insurer or a client wants to know what touches their data, the list already says. And it makes updates calm: when a tool or model changes, the list tells you exactly what to re-check.
With the rules written and the list current, one question remains that most firms never ask deliberately: where does all of this actually run? The next section decides.
One page of rules, one list of what runs, both owned and current. This is an afternoon's work, and it puts you ahead of most firms of any size.
Every AI tool your firm uses does its work somewhere: on a provider's computers, or on your own. By this stage those choices add up to how much control, cost, and dependency the firm carries, so this section makes them deliberate, with one rule of thumb: for everything that runs, you can say where it runs and why.
Your email almost certainly runs at a provider. Your files might too, or they might sit on a machine in the office. Nobody agonized over those choices; each followed a real need. AI is the same decision in new clothing: most tools are services you rent, some can run on computers you own, and the right answer depends on the work, not on fashion.
You start in minutes and always have the newest version. Your protection is the contract: the plan you are on decides what the provider may and may not do with your data.
The firm's AI assistant and its automation tool, both subscriptions, both the provider's problem when something breaks at night.
It takes real effort to set up and someone has to keep it healthy. In return, nothing leaves machines you own, and the cost stays the same however much you use it.
A firm runs a freely available model on its own server for the documents that may never leave the building.
Between those two ends sit real middle options, and most firms end up using several at once. You can rent a private space at a large cloud provider, where the software runs on their machines but inside a walled-off area only your firm can reach. You can use a provider's tool configured so that your data stays in your own systems, or in your own country. The point is not to pick a camp; it is to match each automation to the protection it actually needs. Everyday work runs comfortably as a service. Work with a hard constraint, such as client confidentiality or a rule about where data may be stored, earns a more controlled option. And paying for maximum control everywhere means paying for a constraint you do not have.
Many firms build up a small set of documents their AI tools read before doing any work: what the firm does and for whom, how it writes, what its services cost. If yours has these, they deserve their own decision, because every tool depends on them. The best home is usually the simplest: ordinary files in a folder the firm controls, such as the shared drive it already uses. Ordinary files can be read by any tool, moved anywhere, and survive every change of provider. Keeping that knowledge inside one tool instead, in its settings or workspace, is more convenient day to day, and it quietly ties you to that tool: switch providers, and the firm's accumulated knowledge has to be rebuilt from scratch.
The firm keeps these documents in the same cloud folder as its client files. When it later changes AI assistants, the new tool reads the same folder and knows the firm on day one.
First: when this breaks, whose job is it? For a service, the provider's; for anything you run yourself, someone at your firm, and that someone should be named before the breakage, not during it. Second: how would we leave? Providers raise prices, retire products, and get bought. Leaving calmly takes three things you can arrange today: the firm's knowledge stays in files you own, you have tried exporting your work from each tool once so you know it works, and each automation's instructions say how the work would get done by hand for a week if it had to be.
The instructions for the invoice automation end with one short paragraph: how to export it, and how invoices get processed by hand from the same checklist it was built from, if the tool is ever down.
You will hear more and more about systems where many agents pass work between themselves. The idea is real, and it multiplies everything this playbook taught you to keep in check: what the system can reach, what it can spend, and what can go wrong while nobody watches. The honest readiness test is simple: your individual agents run reliably, they rarely need correcting, and your list of what runs is current. Until then, several simple agents doing one job each beat one clever fleet.
That settles where things run. What keeps all of it alive is people, and that is the next section.
Match each automation to the protection it actually needs, keep the firm's knowledge in files you own, and know for everything that runs where it runs, who cares for it, and how you would leave. These are decisions, not projects.
The engine is documents and routines, and documents and routines only stay alive when people look after them. This section covers the people side, with one rule of thumb: give every standing piece one named person, and lead adoption by example rather than by announcement.
This stage leaves the firm with a few things that need ongoing attention: the list of what runs needs its reviews to actually happen, the shared collection of proven prompts and templates needs occasional pruning, and people's questions need somewhere to go. Give each of these one named person. These are not new positions and this is not an org chart; in most firms it is a few hours a month folded into jobs people already have, and in a small firm one person can carry all of it. The reason for the names is simple: a responsibility held by "the team" is held by nobody.
In a twelve-person advisory firm, the operations lead makes sure the quarterly review happens, a senior consultant tidies the shared collection now and then, and questions go to the partner who wrote the policy. Nothing changed on paper; three things stopped falling through the cracks.
Adoption follows what leaders visibly do, not what they approve. A leader who uses the tools in the open, drafts with them, shares the instructions that worked, brings their own automation to the review, gives everyone else permission by example. The opposite is just as visible: a leader who announces AI and never touches it teaches the firm that the tools are for other people. This never stops mattering; the steady state is simply the point where working this way has become ordinary.
A partner opens the Monday meeting with the brief she used to draft a client memo, including the two corrections she had to make before it was right. That five-minute habit does more for adoption than the training budget.
Three habits do more than any training program. Hold a build day: each person automates the task they like least, self-chosen, so nobody's work is automated at them, and whatever proves itself goes into the shared collection with the builder's name on it. Ask it in interviews: "show me how you work with AI" says more than any line on a resume, and it tells candidates what kind of firm they are joining. And point the firm's own tools at its own people work, starting with onboarding.
The firm's onboarding manual, converted by a model into short modules with a quick check after each one and a first-day practical task marked against a checklist. A new hire's gaps show up as flagged answers to talk through together, and the manual finally gets read.
People keep the engine alive; numbers prove it is worth keeping alive. What the whole portfolio returns is the next section.
A named person for every standing piece, leaders who visibly use the tools, and people who learn by building. The people side costs hours a month, and without it the documents go stale.
Earlier in the playbook you measured one workflow; the engine measures all of them. This section sets the rhythm, with one rule of thumb: every automation on the list shows what it delivered, on a schedule it cannot skip.
The discipline is the same one that proved your first workflow: compare what the automation delivers against what the work cost before, and decide from the number, not the mood. What changes at this stage is only the scope: you are now looking at everything the firm runs, together.
The person responsible for the intake summaries arrives with this quarter's count of summaries the team actually used, compares it with the best quarter so far, and writes "fix": the new document type it mishandles is already named in its own logs.
Each decision feeds something useful. A keep with a strong number is the argument for taking on the next workflow, with evidence attached instead of enthusiasm. A fix leaves the review as a clear work order, because the automation's own records usually say what went wrong. And a retirement feeds the shared library: what the workflow taught goes onto the shelf before it is switched off, so even a retirement leaves the firm faster than it found it.
A meeting-notes automation whose summaries nobody actually uses gets retired at its second review. Its process notes and its brief go to the shared library first, so the next attempt at the same problem starts warm instead of from zero.
The numbers keep the engine honest. The next section prepares you for the people outside the firm who will ask about all of this.
On a fixed schedule, for every automation: what did it deliver, what did it cost, keep it or not. A firm that never retires anything is admiring its automations, not measuring them.
Sooner or later someone will ask what your firm does with AI: a client before they sign, an insurer at renewal, eventually a rule. This section turns that question into a strength, with one rule of thumb: whoever asks, the honest answer already exists in writing.
Firms rarely lose work for using AI; they lose it for being vague about it. A clear, unhesitating answer signals exactly what the person asking wants to know: that someone here is in charge of this. And because most firms cannot yet answer the question well, answering it plainly sets you apart more than the tools themselves do.
Name the tools and what they are used for. A vague "we may use AI" line protects nobody and reads like it is hiding something.
Drafting and document review are assisted by [named tool] under our review; your data is not used to train it.
Clients and insurers increasingly send question lists: what do you use, what does it touch, who checks the output. The list of what runs already holds those answers; a short summary kept ready turns a week of scrambling into a same-day reply.
The insurer's AI questions get answered from the current list of what runs, the same week, without a meeting.
If your people picked up the habit early of noting what a model touched in each piece of work and who checked it, none of this is new effort: the engagement letter simply says at firm level what the work already says internally, and the honest sentence writes itself from practice.
A client's procurement team sends a twelve-question list about AI use. The answers come from the policy page, the summary of what runs, and the engagement letter already on file, and the reply goes out the same week.
Less than the headlines suggest. For a typical services firm using general-purpose tools, the current rules come down to two things: your people know how to use the tools responsibly, and nobody is misled about dealing with AI, so chatbots say they are chatbots and AI-made content is labeled as such. The heavy obligations target uses like automated hiring decisions, and they sit mostly with the companies that build the models, not with firms that use them. A short internal training and the one-page policy from the start of this stage cover most of what is asked.
The last section turns everything the firm has learned into its most compounding asset: the shared library.
An honest letter, ready answers, and people who can say what they use. Firms rarely lose work for using AI; they lose it for being vague about it.
The engine is a steady state, and it is deliberately light. Operating well here looks like: the list of what runs is current, the numbers are honest, the answers are ready, the library keeps growing, and none of it needs a committee. This is the destination for firms with enough running; there is nothing above it to climb to.
The first three stages run the same six-move loop at rising scale: on your own recurring work, then on one shared workflow, then across many workflows with automation and agents. The fourth stage is different in kind: the operating engine, the light set of standing rules and shared documents that keeps everything you've built running and compounding. Six principles sit underneath all of it.
What actually breaks first, or drains the most hours. One bounded task, not a whole function.
Watch the process as it really happens, capture a baseline, and name one owner. You can't improve or prove anything without the before-number.
Pick the simplest option that clears the bar: a fixed rule, a single model call, a set-up assistant, an automation platform, or an agent. Move up a rung only when the one below genuinely runs out.
Run it beside the current way, decide the go/no-go rule in advance, put a time limit on it, and treat "stop" as a legitimate result.
Add the guardrails, name the owner, and make it the default way the work gets done.
Track verified outcomes, not how many people are using it. Retire whatever stops paying its way.
Start with the bottleneck you actually want to clear, and let that choose the tool, not the other way around.
An AI that runs on its own is only as reliable as the process behind it, so define the workflow as clear steps and rules first, then let it take over.
Let the system do the work, but a person reviews and signs off on anything a client sees or that would be costly to get wrong.
What makes an automation safe to trust is the structure around it: spending limits, clear boundaries, an off-switch, and a record of what it did.
When a model gives you an answer, make it cite and check its sources, because you stay accountable for the result.
Once something works, capture it as a repeatable process, so the next time is faster and someone else can run it without you.
Bring the workflow that bothers you most. We map where the work leaks, tell you what we would run the loop on first, and you keep the notes either way. No deck, no obligation.