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: find the stage you are at 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.
If a piece of work is made of language, a model can carry part of it today: the reading, the drafting, the comparing, the summarising. What stays with you is the judgment. Most professional jobs turn out to be a braid of the two, which is why the gains show up on nearly every desk once you know what to look for.
Language work can be handed over. Judgment stays with you, and the model's job is to prepare it: gathering, drafting and comparing so that you decide with better material.
Going through one real week of your own work and marking each task by what it is made of, then handing over one recurring item properly.
A marked-up week that shows where your own gains are, and one task delegated by the end of it.
Most people meet AI as a curiosity: a poem on demand, a quick answer to a trivia question. The working version is less flashy and worth a great deal more. The useful rule of thumb is that if the work is made of language, a model can carry part of it, and it is strongest exactly where a person tires: volume, the reading and comparing that costs hours and does not get better on page two hundred. It is weakest where a single exact fact or figure has to be right without anyone checking. Both of those facts shape how the tool is best used, and the next article turns them into working habits.
One person's task list at one firm, each item marked for what it is made of rather than how important it feels. The marking is the part to copy.
the PDFs in the shared drive, into one table for checking
Extracting and tabling is language work.
the shared inbox, replies in the firm's tone
The model drafts; you read and send.
the model compares this year's hours against the fee; you make the call
Judgment, prepared by the model.
two exports that never quite agree, matched line by line, variances explained
Comparing is language work too.
drafted in your voice from the week's notes and sent messages
Your review puts your name on it.
the last read before it carries the firm's name
The final word is the job.
Three marks are enough. Most knowledge work lands in the middle one: the model produces, you certify.
These six cover most of what firms find in the first month. None of them needs special software; the mainstream tools can do a version of all six today, in a browser, from a plain-language instruction.
A lawyer hands over a stack of agreements and gets back every deadline, obligation and unusual clause, matched and tabled for checking.
Messy enquiry emails become clean, structured entries for the case or project system, drafted and ready to file.
Two exports that never quite agree get reconciled line by line, with the variances explained in plain language.
One announcement gets drafted in the firm's tone, then reshaped for the newsletter, the website and a client email.
A raw spreadsheet export comes back as the finding: what moved, what did not, and what is worth a closer look.
A week of industry and regulatory news becomes a briefing note, with the two developments that matter on top.
Language work (reading, drafting, comparing, extracting, summarising) can be handed over; decisions, advice and the final word stay with you, with the model preparing them. The test is what the task is made of, not how important it feels.
Marking real work tends to beat brainstorming about work. The items that show up every week are worth the most, because whatever you learn about them pays back weekly.
The weekly update is a good first choice: the material already exists in your notes and sent messages, and you can judge the result at a glance. Your corrections to the first draft are what make next week's better.
By the end of the week you have something more useful than an opinion about AI: your own task list, marked for where the language work sits, and one recurring task already running with your review on it. Nothing here needed setup, connected systems or anyone's permission, and a free plan is enough to feel the difference.
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 mostly how you talk to it. A question gets a generic answer, because the model knows nothing about your situation beyond the sentence you typed. A brief, with the material and the standard attached, gets something you can use.
Brief it the way you would brief a colleague, and review what comes back the way you would review a junior's draft. The loop of instruct, review, improve is the skill; the tool is only where you run it.
Handing over the situation, the material and the standard; checking the specifics rather than the structure; saying what is wrong and asking for the revision; and knowing when to start a fresh conversation.
One real task run through the whole loop, and a brief that worked, which is worth keeping.
Most disappointing first experiences with AI are questions that should have been briefs. "Write a follow-up email to a client" can only produce something generic, because the model has nothing to work from. The same request with the thread attached, the objections named, the tone specified and a length given produces a draft that is nearly right, and the correction that follows is where the quality jumps. That loop, instruct, review, improve, is what this article teaches, and it carries through every later stage of the playbook unchanged.
The same follow-up email, asked for twice. The difference between the first panel and the other three is most of what this article has to say.
"Write a follow-up email to a client."
Generic by necessity. The model knows nothing about this client, this thread, or what the follow-up needs to achieve.
"Here is the email thread and the proposal we sent. Draft a follow-up that answers their two objections, in my tone, under 150 words."
The situation, the material and the standard to hit. The model now works from your facts rather than guessing them.
The draft comes back well structured. The day rate it quotes is from the old proposal.
Read it the way you would a junior colleague's draft: the structure is usually sound, and the specific facts, names and numbers are where to check.
"The rate is from the old version. Use the one in the attached proposal, and tighten the middle paragraph."
The second pass with real feedback is where the quality jumps. This brief worked, and it is worth keeping.
The same loop carries whole-task delegation in 1.4, and it is the loop the Stage 2 build runs on a schedule.
State the task, hand over the material, and name the audience and the standard to hit. What you would tell a colleague taking over the task is very close to what the model needs.
The thread, the notes, the document itself. A model works far better from your actual material than from your summary of it, and the summary is more work for you anyway.
The structure is usually sound. The specific facts, names and numbers are where to look, because that is where a model is most likely to be confidently wrong.
When a fact matters, it is worth asking the model to search and cite its source rather than answer from memory, and opening the source yourself when the stakes are real.
Saying what is wrong and asking for the revision tends to get a better result than silently fixing it yourself, because the correction improves this draft and teaches the next brief. A brief that produced a usable draft is worth saving as written; the last article of this stage turns those into a library.
A long conversation full of corrections drags old misunderstandings forward. When that starts to happen, the good output can be taken into a clean session and the rest left behind.
Once the loop is a habit, the tool stops being a novelty and starts being a colleague you brief and check. You will also have noticed how much of the loop is about what the model knows before you start, which is what the next article sets up once, so that you stop repeating it.
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 conversation as a stranger. It is possible to give it your world once, through standing instructions, project spaces and the narrowest connections that do the job, and to keep all three under your control.
Context is what the model knows before a conversation starts. Connections are what it can see and do, live, inside the access you have granted. Both are decisions you make rather than defaults you inherit.
A page of standing instructions, one project space per ongoing matter, connections granted one at a time with the smallest access that works, and a short standing check on all three.
A setup where whole categories of explaining disappear, and where you can say at any time what the tool knows and what it can reach.
From standing knowledge to live systems. Each layer reaches further than the one before it, and each stays something you decided.
Who you are, what the firm does, how you like output. Written once, applied to every conversation.
Your controlYou can read it and edit it at any time, and fix what has gone stale.
One space per ongoing matter, loaded with its documents, so every conversation inside it starts informed.
Your controlYou decide what goes in, and the space holds only what you loaded.
The systems the work needs: calendar, files, inbox. It reads or acts inside the access you granted, and nowhere else.
Your controlGranted one at a time, with the smallest access that does the job, and revoked when the work stops needing it.
The Stage 2 build runs on exactly these three: the saved instruction is layer one, the loaded documents are layer two, and the systems it reads and writes are layer three.
Each of the three layers saves a different kind of repeating yourself. The standing instructions save re-explaining who you are; the project space saves re-attaching the background to every conversation about a matter; the connections save copying things in and out by hand. The other half of the setup is control, and it is worth taking as seriously as the convenience: you remain accountable for what the system reads and does, so narrow scopes, per-use approvals and an occasional look at what memory has stored are what keep that accountability real.
A page at most: the firm's services, your role, the tone rules, the formats you want by default. Stale instructions quietly degrade every conversation, so they are worth re-reading whenever something feels off.
Loaded with the real documents, the engagement letter, the notes, the drafts, rather than descriptions of them. That is what turns "let me explain the background" into a sentence you stop writing.
Like a key card to named rooms rather than the whole building: approve actions per use rather than choosing "always allow", let the work pull the connection rather than connecting things because it feels like progress, and disconnect what you stop using.
The data settings say whether conversations are used for training and how long they are kept. Checked once and chosen deliberately, the question is settled, and client material gets the same care in an AI tool as in any other system.
With the three layers in place, the tool stops starting from zero, and you can answer at any moment what it knows, what it can reach and what it may do on its own. That is the personal version of a check Stage 4 runs for the whole firm, and it is the footing the next article's larger delegations stand on.
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. Handing the model a whole task with a proper brief, and making yourself the reviewer, moves your time from producing the work to directing and certifying it. The judgment stays on the page; the hours of production in between are what disappear.
Dabbling uses the model for fragments of work you are already doing, so the task's shape and its hours stay yours. Delegating hands over the whole task and makes you the reviewer.
Picking work with a known good shape, writing a brief that holds the standard, reviewing as if the work carries your name, and planning for one round of corrections.
A five-section brief for one task you currently produce by hand, and the first version of that task produced without you writing it.
What handing over a whole task looks like in practice. This one hands over a proposal first draft; the five sections fit any task with a known good shape.
One firm's task and systems. The five sections are the part to copy, and this brief is the personal ancestor of the saved instruction a Stage 2 build runs automatically.
Delegation changes where your time goes, not how much care the work gets. A real brief plus a serious review still puts your judgment on the page; what disappears is the hours of production in between. The brief is also where your judgment enters the work in the first place, which is why the section on what must not happen ("anything the notes don't cover is flagged, not invented") matters as much as the description of the task. The model follows the standard you state, not the one you assume.
Proposals, summaries, reports, first-pass reviews: work where you can describe what good looks like, so you can check what comes back. First versions rather than final calls, and language-shaped work first; tasks whose output you cannot verify are better held back until the review habit is solid.
Material, audience, tone and what good looks like, stated up front, along with what must not happen. Most of the quality of the first draft is decided here rather than in the correction round.
Facts, names and numbers checked against the material; structure judged; nothing forwarded unread. It does carry your name, which is the whole reason the review is not optional.
One revision with pointed feedback is part of the job rather than a failure of the tool. It is the same loop as the last article, applied to a bigger unit of work; the habits carry over unchanged, and what grows is the size of what you hand over.
After the first delegation you will have a brief that works, a draft you reviewed rather than wrote, and a clear sense of how much of your week is made of tasks with this shape. Tasks you delegate well once are worth making repeatable, and that is what the last article of this stage is about.
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. A good result that disappears into the chat history gets rebuilt from memory next month, a little differently and with a little less of what made it work. Capturing it is the difference between being personally faster and building something the firm keeps.
When something works twice, it is worth capturing, so that it works every time and can be handed to a colleague. Personal speed fades with the person; a small library compounds.
Saving the briefs that worked, turning the most-repeated task into a reusable skill, scheduling the genuinely recurring work, and keeping all of it in one agreed place.
A starter library: five briefs that work, one skill, and one piece of recurring work that arrives on its own.
Each one captures a different kind of repetition. Most people build all three within a few months of starting.
A saved instruction for one task, reused each time it runs. The proposal brief from the last article is one.
A multi-step instruction the model applies on demand: how the firm writes summaries, structures reviews, formats deliverables. Shareable and improvable in one place.
Recurring work set to run on a rhythm, so the Monday summary arrives instead of being produced. You review what arrives and improve the instruction, not each output.
What capture looks like a few months in for one person: five briefs, one skill, one scheduled task, kept in one agreed place.
The full brief from the last article: task, material, audience, standard, review.
From the week's notes and sent messages, in my voice, to the person who actually reads it.
The transcript in; owners and deadlines out, with open points flagged.
Agreements in; every deadline and notice period tabled for checking.
A messy enquiry email becomes a clean, structured entry, ready to file.
The firm's structure and tone as a multi-step instruction, shared with two colleagues.
Arrives at the start of the week, built from the connected calendar and the CRM. The instruction gets improved, not each output.
One person's entries. The shape is the target: your most-repeated tasks captured and named, the most-delegated one written as a skill, one piece of recurring work arriving on its own.
This is also the point at which paying for the tool starts to earn its keep. A free plan carries you comfortably through the working loop, but the machinery of capture and context, project spaces, connections, saved skills and scheduled tasks, mostly lives on the paid plans. What you are paying for is not a smarter chatbot; it is the features that turn a chatbot into a delegation system.
The brief that produced the best draft so far is sitting in this week's conversations right now. Saving it takes a moment; rebuilding it from memory next month loses a little of what made it work, which is why capture is easiest at the moment it works.
A skill is the first asset you build that belongs to the firm rather than to a conversation. It can be handed to a colleague and improved in one place, and it tends to be the point at which your habits start becoming the firm's.
The Monday pipeline summary now arrives instead of being produced. The rule that you certify what the model produces still holds; what changes is when your attention enters, and the quality compounds because you improve the instruction rather than each output.
One agreed place, improved in the master copy, reviewed now and then for what has gone stale. Scattered private variants are how capture quietly dies: three colleagues each running a slightly different version of the same brief, none of them the best one.
With five briefs, one skill and one scheduled task in one place, you have a starter library, and that completes what this stage set out to build. Many readers should operate at this level for a while, and staying here is a perfectly good outcome. Stage 2 is there for the day a shared workflow needs more than personal leverage, not because a next stage exists.
When it works twice, capture it: templates, skills, scheduled tasks. Personal speed fades with the person; a library compounds.
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.
The right first workflow is one your firm can actually win, rather than the one that would look best in a demo. In practice that means something that runs often, has a clear start and finish, and is cheap to get wrong while the build is still learning.
The workflows worth winning are not always the ones people complain about. What matters more is where work sits and waits, and where your most qualified people lose their week.
A list of where work piles up, a question to the team about what they already hand to AI, seven tests for every candidate, a ranking of the survivors, and one bounded commitment in writing.
A one-page shortlist memo with five candidates and one recommendation, ready for your management team to read and challenge.
Stage 2 starts with a decision: which workflow gets your firm's first serious AI effort. Finding candidates is rarely the problem, since any working firm has plenty. The hard part is choosing one you can win. The workflow that would impress in a demo is usually heavy on judgment, full of exceptions and wired into half your systems, and that combination is exactly why it tends to fail as a first build. Something less glamorous, that runs every week and can be checked at a glance, is a far better place to start.
One clear no is usually reason enough to set a candidate aside for now. Whatever passes moves on to the ranking.
Every survivor goes on the grid, and the first workflow comes from the top-left corner. These are one firm's candidates.
The first win: real hours every week, three systems, few exceptions.
Worth winning, but too heavy for a first build. This is what Stage 3 is for.
Easy wins that move little. Good later, once the habit exists.
Neither first nor soon. Off the list until it can be bounded and measured.
Impact means the hours it drains, how often it runs, and what delay and errors cost. Effort means the systems it touches, the exceptions it produces, and the judgment it needs.
Five candidates and one recommendation, short enough for a management team to read and challenge in one sitting.
One firm's candidates. A software business might recommend support replies, and an accounting practice the seasonal crunch. The shape of the memo is the part to copy.
The most useful list comes from the queues and handoffs: quotes waiting to be written, tickets waiting to be answered, invoices waiting to be checked. Add every place someone retypes data between systems, and every report or first draft that gets produced to the same pattern each week.
Shared inboxes and handoff points tend to hold more waiting work than any job description shows.
"What do you already hand to AI?" tends to get concrete answers, where "What should we automate?" gets opinions. The tasks people already delegate on their own initiative are a strong signal of what the firm could automate properly.
In many firms the proposal queue shows up on its own, because associates are already drafting from intake notes with a model and tidying the result by hand.
The same seven questions for each, without exceptions for favourites.
Once they are on the grid, the choice usually makes itself, even when the top-right corner looks more exciting.
One line is enough: the task, where it starts and ends, and the person who owns the win. It helps to keep the commitment to a single task rather than a department. If proposals are the bottleneck, the first win is drafting the first version of one, not reinventing how the firm sells.
Proposal drafting at an agency, first-line support replies at a software business, the seasonal crunch at an accounting practice, after-hours enquiries at a local service firm. These are places to look rather than answers; whatever you find still goes through the seven tests.
With the memo written, your firm has made its first real decision about AI: one bounded task, chosen because it can be won rather than because it would impress, with a named owner and a management team that has seen the reasoning. The next article maps that task as it really runs.
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.
Every workflow exists twice: the official version in the handbook, and the real one that runs this week, with all its workarounds. Builds tend to fail when they are made from the first and run against the second, so the map you make here is of the real one, with the number it actually costs attached.
The gap between the official process and the real one is where the surprises live. Part of the real one is nearly invisible: people fixing bad data on the way through without noticing that they do it.
One real pass recorded, a first draft of the map from a model, corrections from the person who does the work, a check of the data each step runs on, one real week counted, and one owner named.
A one-page map a new colleague could run from, with a counted baseline and a named owner. Everything built afterwards stands on it.
The official version of a workflow lives in handbooks and job descriptions, usually written from memory, often by someone who no longer does the work. The real version runs this week, with the workarounds, exceptions and quiet fixes people have built up over time. The two can look quite different, and the difference matters, because the build that follows will run against the real one whether or not anyone wrote it down.
The person who does the work records one real pass, screen and voice, the way they would show a new joiner. It helps to narrate the off-screen parts ("here I would normally ring the client back") and to resist tidying anything up, since the workarounds are the most valuable footage.
Whatever recorder is already on the machine will do; the transcript matters more than the video. If several people touch the workflow, each records their own part, and the handoff between them is usually the most important footage of all.
Given the transcript and an instruction describing the output, a model will return a structured first draft: the steps in order, who does each, the systems read and written, exceptions marked as such, and the decision points. One page, in plain language.
Saving that instruction once in a dedicated project space means every transcript comes back in the same shape, and the space keeps the earlier maps. The fifth map tends to cost a fraction of the first.
The person who does the work checks the draft against the recording and fixes what it missed: the wrong order, the skipped steps, the exceptions that happened not to occur in the recorded pass. A person certifies the map, not the model.
One page, plain language, and a new colleague could run the workflow from it. If they could not, it is not finished yet.
For each step, the map names what it reads and writes. Spot-checking a few real records at each one tends to surface the quiet fixes: the stale price, the address one system gets wrong, the field the form left empty. Each of those is then either cleaned at the source or written into the build, rather than left silent.
A model handed wrong data does not stall the way a script would. It produces something plausible from it, which is harder to notice.
A shared sheet where the work happens is enough. Every pass that week is counted and timed from arrival to finished, including the waiting, because delay usually hides in the handoffs rather than in the doing.
People's sense of how long something takes, or how much time was saved, is not reliable in either direction. That is why the baseline is counted while it happens rather than remembered afterwards.
One person owns the map, the count and the decisions the next articles will ask for. Naming them now, rather than after something goes wrong, means that when the pilot needs its go or no-go, everyone already knows whose name is on it.
One page. The left side is the workflow as it runs; the right side is what recording found and memory would have missed.
front office · reads the shared inbox · writes a new record in the CRM
Urgent requests skip the web form and arrive by text. They are logged in the CRM afterwards.
partner · reads the enquiry and that client's past work · judgment call
Standard pitch or custom. This is the fork the next article builds a stop on.
associate · reads past proposals and the rate sheet · writes the draft
The day rate the CRM still shows is stale. It is corrected by hand from the rate sheet, every time.
partner · marks up the draft · prices against the rate sheet
Rush requests jump the queue. Labelled as such rather than smoothed over.
associate · sends the PDF · writes the log entry on the CRM record
Worth knowing too.
One firm's systems; yours might read Gmail for Outlook or Salesforce for HubSpot. What matters is that every step names its real ones.
Spot-checking real records at every step against these four tends to surface a quiet fix someone is making today.
The value is simply incorrect.
ExampleThe day rate the CRM shows is not the one the firm charges.
It was right once.
ExampleThe contact who left last year is still the named client lead.
The field is empty or partial.
ExampleThe web form never asked for the budget, so the record has none.
Two systems disagree.
ExampleThe address in the CRM and the one on the last invoice do not match.
With the map finished, your firm has something more durable than a plan: a one-page record of how the work actually runs, the data it depends on, what it costs in a normal week, and who is responsible for it. The next article decides, step by step, how each part of that map gets done.
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.
Most steps in a workflow need nothing cleverer than a fixed rule. AI earns its place where someone has to read, weigh or write something, and an agent only where the cases keep changing shape. The simplest tool that can handle a step is usually the right one.
Every step on your map either runs the same way every time, or needs someone to think first. That one distinction settles most of the decisions in this article.
Marking each step as one kind or the other, giving the same-every-time steps a rule and each thinking step a single AI task, and building in a stop wherever a person needs to decide.
A map where every step says which tool does it and where the people stay in, ready to be built.
The map from the last article lists the proposal workflow step by step, and any one of those steps turns out to be one of two kinds. Either it runs the same way every time, as when an enquiry arrives and a client record gets created, or someone has to read, weigh or write something before the step can happen. Once each step is marked as one or the other, most of the routing is already decided, because the simplest tool that can handle a step is usually the right one, even when something more capable is available.
Each size can do more than the one before, and each is a little harder to predict. The smallest one that can handle the step is normally the one to choose.
If this happens, do that. The same action every time. Most of the systems a firm already uses offer these built in.
On the proposal workflowAn enquiry arrives, so a client record is created with the enquiry attached.
Entirely predictable, and unable to handle anything it was not told about.
One piece of judgment work, done from instructions you have written down, after which it stops.
On the proposal workflowDraft the proposal from the intake notes, in the firm's tone, and flag whatever the notes do not cover.
Flexible in its wording, predictable in its shape. The written instruction is the real asset.
Given a goal and boundaries, it works through several steps on its own, in whatever order the case in front of it needs.
On the proposal workflowNothing needs one. A support inbox, where every reply depends on who wrote and why, is the classic case.
Handles cases that vary, and is the hardest to predict, so it needs the most looking after.
One trigger, two rules, one AI task, and two points where the workflow stops and waits for a person. No agent is needed.
The automation watches the shared inbox and the website form, and either one starts a pass. Nobody has to notice the enquiry for the workflow to begin.
writes a new CRM record with the enquiry attached. It is the same action every time, so it is set up once and rarely thought about again.
The partner receives a task and the pass waits for the answer: standard pitch or custom. This was the decision point on the map, and here it becomes a built-in stop rather than a habit.
reads the intake notes, past proposals and the rate sheet · writes a first draft with the gaps flagged. It runs on one saved instruction, written once and improved deliberately.
Nothing leaves without this sign-off. This firm drew the line at everything a client sees; where a firm draws it is its own written choice.
writes the PDF goes out, the file is stored, the CRM record is updated. The step is mechanical again, so a rule closes the pass.
An agent earns its place where rules keep producing exceptions until nobody can hold them all. On this firm's map that is the support inbox, which Stage 3 takes up.
The systems are one firm's. What transfers is the shape: a trigger, rules for the same-every-time steps, one AI task for the judgment, and stops that are built in rather than remembered.
A short session with the map's owner is usually enough; the decision points already on the map show where the judgment sits.
Most of your systems already offer these, and an automation platform bridges the gaps between them.
One written instruction, saved inside the workflow, is the asset; it outlives the tool it runs on.
A stop that is configured cannot be skipped on a busy day, which is exactly when a habit would be.
Where rules keep producing exceptions until nobody can hold them all; on the proposal workflow, nowhere.
If your workflow looks like everyone else's, a vendor has probably built it and your process adapts to the product. If the map is your own, it can be assembled from standard parts in weeks. Either way, three lines go on the map first: what it may see, what it may do alone, and who is alerted when it fails.
With the map marked up this way, you know for every step which tool does it and where the people stay in: rules for what never changes, one AI task for each judgment, a built-in stop wherever a person decides, and an agent only where the cases keep changing. That is the build the next article puts to the test.
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 safest way to find out whether the new way works is to run it next to the old one for a fixed stretch, with the pass mark agreed before the first run. A pilot that ends in a clear no has done its job just as well as one that passes.
The old way keeps doing the real work while the new way runs beside it, so nothing breaks while the team learns what the new way can and cannot do.
A pass mark written before the first run, a fixed end date, judges who do the work rather than the person who built it, the difficult cases pushed through on purpose, and a decision on the date.
A one-page pilot plan with the sign-off boxes still empty, and at the end of the month, a decision that rests on counts rather than impressions.
Once the build exists, the temptation is to switch over and see what happens. Doing that puts everything on a setup nobody has watched under real load and leaves the way back improvised. A parallel run avoids both problems: the new way handles the same cases as the old one, and the old one keeps producing everything clients see. The counted week from your map is the referee, and the pass mark is agreed before the first run, because a pass mark chosen afterwards tends to bend toward whatever result came in.
For the whole pilot, the old way keeps producing the real output while the new way drafts the same cases. Its drafts are compared, not sent, which is what makes an honest pilot affordable: a bad week costs some learning rather than a client.
Two or three numbers on one page, each set against the counted week: how long a pass takes from arrival to sent, and what share of drafts are accepted without rework. Nothing on the page needs to be estimated, because both reference numbers already exist.
It is better to go back and extend the counted week than to guess. A comparison without a referee tends to turn into an argument about how things felt.
A month is typical for a weekly workflow: long enough for it to run often enough to judge, short enough that a decision has to come. The people who do the work every day are the right judges, and the person who built the setup supports them rather than judging alongside them.
A demo run by the builder almost always looks good. The real test is an ordinary Tuesday under real load, in the hands of the people who will live with the workflow afterwards.
The workarounds and exceptions your map recorded, like the urgent request that arrives by text or the client record with the stale rate, are the natural test set. If nothing broke by the end of the month, the pilot was probably too gentle.
Each one goes in the log with a line on why. That log becomes the first work list for the rollout, which is a more useful way to read it than as a mark against the pilot.
The owner reads the counts against the pass mark and marks one box: go, no-go, or one extension in writing with its own end date. A clear no at this point has saved the firm quarters of running a workflow on hope, which is why it counts as a result rather than a failure.
One of them is real. The counts decide which one survives.
Keeps producing everything clients see, exactly as before. Every pass is timed.
Drafts every proposal too. Timed and reviewed by the partner; nothing it produces is sent.
The counts are read against the pass mark. Go, no-go, or one written extension. One box is marked and signed by the owner.
One page, written before the first run. Only the counts and the log are added while it runs.
One firm's plan. What transfers is that everything except the counts is written before the first run.
At the end of the month you have something most firms never get: the same passes done both ways and counted, judged by the people who do the work, against a pass mark that was agreed before anyone had seen a result. Whatever the box says, the decision is a real one.
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.
A workflow is really rolled out when a new case follows the new route as a matter of course, rather than when someone remembers to choose it. Getting there usually means rebuilding the routine around what now runs on its own, not adding the new tool on top of the old steps.
Many rollouts fail quietly. The tool is added on top, every old step survives, new checks grow around it, and the workflow ends up longer than it was before.
A date from which the new way is the default, a walk through the map to remove steps that only existed for manual work, a champion beside the owner, measures that point at the new way, and a way back that still works.
A workflow that runs the new way without anyone choosing it, and three simple tests to confirm that it does.
Once the pilot has passed, the next job is to make the new way part of how the team normally works, and this is where a lot of firms lose the value they have just proved. The first few weeks after a rollout usually run slower than the pilot did, simply because the whole team is now learning what the pilot group learned over a month. It helps to expect that dip and say so in advance, so nobody reads it as the workflow failing.
The proposal routine, step by step. A rebuilt routine tends to have fewer steps than the one it replaced; more steps than before is usually a sign that the tool was added on top.
A pass starts the same way it always did, now by rule rather than by hand.
It only existed because drafting was manual. The drafts now exist before the meeting would have started.
The hour that went into assembling now goes into reading, checking and sharpening.
An add-on rollout would probably have created one. The partner's review already exists and stays the single check.
The sign-off this firm chose to keep.
Automated work drifts as inputs, tools and models change around it, and unwatched it degrades quietly.
One firm's routine. What transfers is the pattern: some steps removed, one changed in kind, one watchful step added.
It is worth setting a date from which new cases are handled the new way by default, with the old way kept only as the documented fallback. While both routes stay open, a busy week will tend to pick the familiar one, and the date is what closes that choice.
A second walk through the map, asking of each step whether it still needs to exist now that the drafting runs on its own. The assignment meetings, chasing lists and status check-ins that existed to coordinate manual work are usually the first to go, and each one removed gives time back to the team.
Some steps change rather than disappear: the associate's hour moves from assembling the draft to reviewing it. People take that far better when it is said plainly during the rollout than when they discover it on their own.
New routines tend to survive a busy month when there is one person on the team who uses the workflow daily, answers colleagues' questions as they come up, and collects what annoys people. It is a lighter job than it sounds, a few questions a week rather than a new role, and it stops small frustrations turning into reasons to go back to the old way.
The champion lives inside the workflow and speaks for the team. The owner holds the map, the numbers and the decisions. In a small firm one person may do both, and the two jobs still exist.
If people are still judged by numbers that reward the old way of working, the old way tends to come back on its own. It is worth checking that nobody is scored on something the rollout deliberately removed; a team praised for the volume of hand-written drafts will, quite reasonably, keep writing drafts by hand.
Someone looks at the workflow's output on a schedule, and the owner can switch back to the documented old way at any time without having to call a meeting. Both are part of what makes the new default safe to commit to.
When all three hold, the rollout is done: the new way is how the work happens, someone is looking after it, and the way back still exists. Anything less is an experiment that has been given a rollout's name, which is fine, as long as everyone knows.
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 last move in the loop is working out what the workflow actually earned: how many results were accepted and used, what each one cost, and how that compares with the week you counted before. The decision then rests on a number rather than on how the team feels about it.
A busy tool is not the same as a better workflow. What counts is a result that was accepted and used, at the quality the firm actually ships.
Counting the accepted results, counting the full cost including the human hours still inside the workflow, dividing one by the other, comparing with the counted week, and deciding on a date set in advance.
A one-page review for your first workflow, with a keep, revise or retire decision that you can defend.
One page per workflow, filled in on the scheduled date. This one shows a workflow that earned its keep.
One firm's page. The form transfers as it is: whatever your firm automated, these entries are the whole file.
Once the workflow is running, the tempting thing to measure is how much it gets used, because usage is easy to count and comfortable to report. It is also the wrong measure. What matters is the result that was accepted and used, such as the draft that went to the client at the quality the firm actually ships. Counting those, pricing them, and comparing with the week you counted before is what turns "it seems to be going well" into a decision.
Accepted results over a set period, taken from the workflow's own records rather than from memory. It helps to agree what counts as accepted before the counting starts, so the definition is not adjusted afterwards.
Drafts sent with light edits are wins. Drafts rewritten from scratch are counted separately, and their reasons are useful later, because they usually point to what a revision would have to fix.
The tools' price for the period is the easy part. The larger part is usually the human time still inside the workflow, and leaving it out flatters every workflow equally.
In three places: preparing what the AI reads, reviewing what it produces, and correcting what it got wrong. The review hour is part of what a result costs, even when it feels like ordinary work.
Cost per success, set beside the same number from the counted week. If a good result now costs less, in money or in scarce hours, the workflow is earning its place. If the comparison is not clearly in its favour, that is what the revise option is for, and the pilot's log usually says where the cost is hiding.
Keep, revise or retire, on a date that went into the calendar when the rollout ended. A review that happens whenever someone remembers to ask tends not to happen, or to happen only when something has already gone wrong.
The before and after, the decision with its date, and two or three lines on what you would do differently, written while it is fresh. With the page filed, the firm has run the whole loop once, and everything the loop produced, from the map to this page, is reusable the next time it runs.
It beats the counted week. It stays, and its page stays current.
It almost does. The pilot's log usually says how, and the revision gets its own review date.
It does not. A retired workflow is not wasted; it has taught the firm what the next one needs.
With the page filed, your firm has done something it will be able to do again: picked a workflow, mapped it, built it, tested it, rolled it out and measured what it earned. Many firms operate well at exactly this level for a long time, and there is no obligation to go further until the next constraint genuinely needs machines working unattended.
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 same six steps run again on the next workflow, and the tools grow from fixed rules to automation and, where the cases keep changing, an agent. The rule that saves the most pain: fixed rules first, agents last.
Once software starts acting in your systems without someone watching each run, what it can reach and what it reads both need to be decided in advance. That comes down to four things: a login of its own, no more access than the job needs, data that has been sorted before anything is built on it, and a small set of documents the firm owns that tell any tool how the firm works.
In Stage 1 a connection acted as you, and a mistake landed in your own inbox. Something that runs unattended needs its own identity and narrow permissions, so that what it can touch is decided, written down and easy to revoke.
A login per build, the least access that does the job, a sort of every dataset the build touches into three piles, and a folder of plain documents that carries what the firm keeps re-explaining.
Four questions you can answer before any build in this stage, and a clear view of which data is ready and which is not.
This stage lets machines act without someone watching each run, and what they act on is your systems and your data. The difference from what came before is less about the tools than about the accountability around them: a build that runs on its own needs a name, a defined reach and a record of what it did. The map from Stage 2 has already done half the work, because it marked every point where a person quietly repairs a bad record on the way through, and a machine repeats that error faithfully, at speed, in every run.
Every dataset a build touches lands in one of three piles, and the pile decides what happens next. The sort is quick to do and expensive to skip.
Accurate, current and consistently structured. The build can read it as it is.
At this firmThe template folder: current versions only, one naming pattern.
Build on it now.
The right data in a messy shape. The build includes the clean-up as one of its own steps.
At this firmClient records where half the phone numbers carry a country code and half do not.
Standardise inside the build.
Wrong, stale or contradictory. Nothing is built on it until it is fixed, because automation does not clean data, it multiplies whatever is there.
At this firmTwo systems that disagree about which contact is current.
Fix first. Blocks the build.
One firm's examples. The quiet fixes recorded on the Stage 2 map tell you where to look: each one is a pile-two or pile-three finding that has already been made.
The worst case for anything that runs unattended needs three things to be true at once. Remove any one and it cannot happen, which makes this the most useful access rule at this stage, and it costs nothing to apply.
Client records, financials, anything the firm would not want outside the building.
An inbox, a web form, a shared document: anywhere a stranger's text arrives and gets read.
Email, an upload, a message to an external service.
The support inbox agent in article 3.3 reads outsiders' messages, so at this firm it gets no way to send anything outside the client list. That is the rule in use.
Each automation gets a login of its own rather than borrowing whoever built it. The access then survives that person's departure and can be switched off without touching anyone's personal account. The proposal build reads the CRM and the template folder under its own login; when its builder changes jobs, nothing about it changes.
The invoice workflow reads invoices, not the whole accounting system. It helps to grant access as if it will be audited one day, because a narrow grant is also the easiest one to explain to a client who asks.
Where a build would hold all three legs, it is usually two builds, or the sending step stays with a person.
Clean, improvable or unfit, as in the figure, for every dataset the build touches. The Stage 2 map is the starting point: every place where it recorded a person correcting a record on the way through names a dataset and usually says which pile it belongs in.
Stage 1 gave your personal AI its world; this move gives the firm one. The firm-scale version is deliberately low-tech: a small set of plain documents, in a folder the firm controls, covering what the firm does and for whom, how it writes, its service conventions and the decisions people keep re-explaining. One short routing file on top tells any tool where to look first.
Because they are ordinary files rather than any vendor's memory, they survive every change of tool and model underneath. They also age the way data does, so one named person approves changes and a scheduled job folds each week's new decisions in and retires what has expired. Without that, a shared folder tends to become contradictory within a quarter.
The four questions below, asked before anything gets connected. An afternoon on them is usually cheaper than the weeks that follow a build on unsorted data.
With those four answered, you have a build that can be named, bounded and switched off, standing on data you have looked at, and informed by documents the firm controls. That is the footing every build in this stage stands on, starting with the predictable steps in the next article.
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 rarely the cleverest ones. The steps that run the same way every time go first, because the rule for them already exists and a mistake in them is visible and cheap to undo. Every build then gets sized by one question: what happens if it breaks?
A step that never changes is already specified, somewhere on a checklist or in someone's head, so automating it is transcription rather than invention. A step that involves judgment is not, and it fails more quietly.
Starting with the predictable work around the build you already have, learning what unit your platform bills in, placing every build in one of three bands by what a failure would cost, and noticing when a platform has been outgrown.
Your next three builds placed in a band, and a clear idea of which meter you pay on.
Every build in this stage lands in one of three bands, and the band sets the rules it is built under. The band follows from the cost of a failure, not from how much the build does, so a small client-facing automation outranks a large internal one.
Dashboards, digests, morning summaries. If it breaks, someone sees a stale number.
On the proposal workflowThe Friday pipeline digest.
Build these freely. They are how the firm learns the platform.
Trackers, bookings, filing, handover notes. A mistake costs an internal correction.
On the proposal workflowThe filing and chasing rules that never made it into the first build.
Build with the limits, off-switch and log from article 3.4 in place.
Anything that leaves the building. A mistake reaches a client under your name.
On the proposal workflowAny automated message to a client about the proposal's progress.
Runs beside the current way first, exactly as the Stage 2 pilot did, before a client sees it.
Predictable steps go first for three reasons: the rule already exists, they fail loudly and fix cheaply, and each run of a plain rule costs almost nothing once the platform starts metering your volume.
The proposal workflow from Stage 2 is surrounded by predictable work that never made it into the first build: the filing, the logging, the chasing, the weekly digest. Those steps are worth taking before anything that thinks, because a file in the wrong folder is visible and reversible in a way that a wrong judgment is not. There is also a cost reason. Once a platform starts metering your volume, the unit it bills in matters more than the sticker price, and the same workflow can be cheap on one meter and expensive on another.
It is worth modelling a month of real volume on each before committing to a platform, because the unit decides which of your workflows are cheap.
A charge for each step executed. Cheap for short workflows, adds up on long ones. Built-in helper steps are often free.
A standard step costs one credit, but AI steps consume by size and complexity, so the bill tracks what the AI actually does.
A charge per workflow run, however many steps it contains. Predictable for long workflows, expensive for very frequent short ones.
The filing, logging, chasing and digest around the proposal workflow are already specified, so building them is writing down what the firm does, and they rarely surprise anyone.
Per task, per credit or per run, modelled on a month of your real volume, because the unit matters more than the headline price.
Read-only freely, internal records with the safety setup in place, client-facing through a parallel run first. The band is about failure, not importance.
If the team lives in a spreadsheet, a build that reads and writes that same spreadsheet tends to survive, because the machinery changes underneath while the habit does not. Working through a list inside a chat tool, with a person reviewing, is comfortable for a list that person could still skim in one sitting; past that, or the moment nobody reviews each item, the job belongs on a platform built for volume. Where a model produces many drafts or variants from one approved brief, a person or a hard checklist should sit between the output and the door, since the shape is predictable even though the content varies.
The usual signs are workflows split in two to fit its limits, exception handling that fights the tool, and costs climbing faster than volume. That is a normal milestone rather than a mistake, and the map from Stage 2 moves with you.
With the predictable steps built and every build placed in a band, the firm has the cheap, visible wins in hand and knows the rules each of the next builds will be held to. The step that involves judgment, the one where the right answer varies, is what the next article takes up.
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, in the sense this stage uses, is software that acts in your systems toward a goal you set, choosing the order of its own steps within rules you wrote, without you watching each pass. The first one works best with a narrow, frequent, checkable job, a job description written before it exists, and a starting mode in which it proposes and a person decides.
The capability comes built into the platforms you already use, so the work is not in the technology. It is in the definition: what the job is, what the agent may touch, what always goes to a person, and what a right answer looks like.
Deciding whether the work should be delegated at all, picking a job that is narrow, frequent and easy to check, writing its job description first, and launching in suggest mode with a scorecard running from day one.
A job description for one inbox-shaped task, and a scorecard that the next two articles will use to decide what the agent may do on its own.
Written before the agent exists. This one is for support inbox triage, which is the classic first job because the volume is constant, each decision is quick to check, and a wrong one is cheap to correct.
The systems and the routing list are this firm's. What transfers is that every section exists before the agent does, and that it has the same shape as the delegation brief from Stage 1 and the saved instruction from Stage 2, one size larger.
The word "agent" is used for two different things, and it helps to separate them before building one. The beginner courses often use it for a chat persona with standing instructions, and if you have built one of those it was real work and worth keeping. This stage means something with more consequence, and the first one gets a narrow job, real boundaries, and a mode in which it proposes rather than acts. The support inbox has been waiting since Stage 2, when it sat on the shortlist marked "kept for later" because the right reply varies too much for a fixed rule. That varying shape is what an agent is for.
A chat assistant with standing instructions and a name. It answers when you type, and it acts only inside the conversation.
Useful as a rehearsal space: a stop phrase and a short report at the end of each session rehearse the habits the next article makes real.
Given a goal and boundaries, it works through several steps on its own, in whatever order the case in front of it needs, inside systems the firm relies on.
Because it chooses its own path and nobody watches each pass, it is the first build whose definition matters more than its capability.
One kind of work in one place. Triaging this inbox, not "handling support". Agents with sprawling toolkits tend to choose badly.
It runs daily, and a person can tell at a glance whether a given decision was right.
A mislabelled ticket costs a correction, not a client.
The platforms you already use offer agents as a built-in option, so capability is not the question. The first question is whether this work should be delegated to an agent at all. Two kinds usually fail that test: work you could not check, because you would never know whether it was done right, and work a fixed rule already handles, because an agent adds variability where none was needed.
The three tiles above. Inbox triage passes all three at most firms; a firm without a busy shared inbox may find the same shape in its intake or scheduling queue.
The goal, the boundaries, what always goes to a person, and real examples of right answers, as in the specimen. The boundaries belong in the platform's permissions rather than only in the instructions, and ten real tickets answered the way the team would beat any description of qualities.
An agent judged against "helpful and accurate" is judged against a feeling, and feelings drift with the reviewer's week. Ten answered tickets are a standard that stays put.
In suggest mode the agent does the reading and the routing work, drafts each decision, and a person confirms it, so every outcome still passes a human hand. The tally of right, wrong and escalated, kept per category from the first day, is what the promotion decisions ahead will run on, and it cannot be reconstructed later.
With the job description written and the agent proposing rather than acting, you have the first build in the firm that chooses its own path, held inside a definition you wrote, and a scorecard filling with the evidence that will decide what it may do next. What to put around it so it can be left running is the next article.
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.
Anything that runs while nobody is watching needs four things around it: limits it cannot exceed, a way to stop it, a record of what it did, and one page that tells a colleague what to do. None of this calls for a security team. Most of it is an afternoon of configuration.
Errors in unattended runs add up. A bad night that nobody is watching is an open-ended cost unless something bounds it.
Spending and time limits set in the platform, an off-switch that more than one person can reach, a log in a shape you can check, one page written for the colleague who is not you, and a check that sits in the calendar.
Three simple tests you can run on anything you leave running: overnight, absence and drift.
Each guard is set up in the platform rather than remembered. The same four fit every unattended build in this stage, whether or not it is an agent.
A spend it cannot exceed, a time limit per run, a cap on steps and retries. Together they turn a bad night into a bounded cost rather than an open one.
What it read, what it decided, what it did. This agent ends every night with a table (ticket, label, action) and one plain line at the bottom: "3 tickets skipped: sender not on the client list."
An alert reaches the owner. The off-switch is one known way to stop it now, that works, and that more than one person can reach. The documented old way from the rollout is still there to fall back on.
A person reads a sample of runs and asks one question: is this still doing what we meant? Drift tends to arrive quietly, as inputs, tools and models change underneath the workflow.
What changes from one build to the next is the size of the limits and how often the check runs, both of which follow from what would happen if it broke (article 3.2).
Everything in this stage that runs without someone watching needs a structure that keeps it dependable, because errors in unattended runs compound in a way that errors in supervised work do not. The four guards above are what turn something that works in a demo into something a firm can lean on. They are less work than they sound: an afternoon of configuration, and the handful of habits described below.
Spend, time per run, steps and retries, set in the platform itself rather than remembered.
One known way to stop it that more than one person can reach, and one page for the colleague who is not you.
A table or labelled list, because prose can hide a wrong call inside a reasonable-sounding paragraph.
Anything it holds it can use at two in the morning. Shared skills and plugins are software from the internet and deserve the same care as any software the firm adopts.
Its own account, a machine that holds nothing else, access granted one surface at a time, and a hard payment limit if a card is anywhere near it.
The calendar entry is what keeps the habit alive once the novelty has worn off. Who runs the machinery, the vendor or your own firm, gets its own article in Stage 4.
With the four guards in place, an unattended build becomes something the firm can rely on rather than something it hopes about: the cost of a bad night is bounded, the log shows what happened, a colleague can act without the builder, and someone is still looking. That is the footing the next article's promotions stand on.
Ceilings, off-switch, logbook, one page of instructions, and a scheduled look at what it is actually doing. The harness is what makes unattended work dependable.
How much should an agent be allowed to do without a person checking? Most firms answer by feel, so a good week builds confidence and a bad morning revokes it, and the answer is really a mood. The alternative is a ladder: each category of work climbs one level at a time on a correction rate you can show, and a short list of actions stays with a person regardless of the numbers, because you decided so in advance.
Trust is given per category of work rather than per agent, against a bar written before the first run. A level is decided by numbers. The human-only list is decided by you, and it never enters the ladder.
Cutting the work into categories you can score, writing the bar and the human-only list first, making corrections countable, holding a short promotion review on a schedule, and stepping a category back down without ceremony when its corrections rise.
One bar line per category and the firm's written list of what always stays with a person.
Every category starts at the bottom, however good the demo looked. It climbs on a low, stable correction rate measured against a bar written before it started, and it steps back down when corrections rise.
Every category starts here. The agent drafts the decision and a person sends it or fixes it; each fix is a correction that gets counted.
The agent completes the step and a person looks at it soon afterwards, while undoing it is still easy.
The agent works unattended and a person reads a sample of the log on a schedule. This is as far as the ladder goes.
Actions your firm keeps behind a person regardless of how well a category scores. Exempt by your decision, not by performance, and written down before the first promotion.
Six weeks in suggest mode with corrections near zero, a month of act with review, and now act and report.
Same inbox, scores just as well, and stays in suggest mode anyway, because this firm keeps movements of money with a person.
One firm's list and one firm's inbox. Many firms choose what clients see, movements of money and the irreversible; yours may be shorter or longer. What transfers is that the list is written before the first promotion.
The ladder replaces a mood with a page, and the page is short: one line per category saying what counts as a correction, how low the rate has to stay and for how long, and beside it the list of actions the firm keeps with a person whatever the numbers say. Promotion day then becomes a check against that page rather than a debate about a feeling, which is easier to defend to a partner and to a client. It is worth saying in advance that a category stepping back down is the ladder doing its job.
Same kind of request, same kind of answer: password resets, renewal questions, refund requests. Corrections that swing week to week for no visible reason usually mean two categories under one label.
How low the correction rate has to be and for how long, in weeks rather than days and through at least one busy stretch, with the human-only list written next to it.
Suggest mode runs through a visible review step, so the approve, edit or reject action is the record. Most platforms keep it; where one does not, a per-category tally does the job.
The three questions below, category by category, then one level up at a time, with the decision logged and dated in the list Stage 4 keeps of everything that runs.
Each one becomes a required approval that no promotion can remove. If the platform cannot enforce the stop, the category is not eligible for promotion at all, because a stop only counts if it cannot be walked around.
When corrections rise, down one level for a set period, with no meeting and no blame. A system that can only ever gain autonomy is not earning trust, it is accumulating risk.
With one bar line per category and the human-only list written, you can say for every kind of work the agent handles how much it may do alone and why, and you can show the numbers that earned it. That is what makes the next workflow, and the one after it, safe to add.
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 large programme. It is the same loop from Stage 2, run again on the next place where work waits, with one addition: everything left running gets watched, because ten quiet automations that nobody looks at fail in a different way from one that breaks loudly.
One workflow that breaks is an incident. Ten automations without a watcher are ten slow degradations, each waiting to be discovered by a client. Growth changes the failure mode, and the watching habit is what keeps ten manageable.
Choosing the next constraint the way the first was chosen, running the whole loop each time, deciding build, buy or hire per workflow, watching everything, and keeping one current list of what runs.
A one-page board showing every workflow, where it sits in the loop, who owns it and how it is watched.
The same loop at different points, on one page. This is what growing well looks like a few months into the stage: five entries, each with an owner, a place in the loop and a way of being watched.
The review page said keep. Its number gets checked monthly; the owner is named and the one page of instructions is current.
The agent proposes and the team confirms. The per-category scorecard counts toward the first promotion review.
The recording is done and certified, and the baseline week is counting now. Nothing gets built until it has.
Still on the shortlist from the first win. It waits its turn rather than running as a side project.
Read-only band, so it gets a scheduled look sized to its stakes, because a broken digest looks exactly like a quiet week.
Five entries at one firm. The board is one page; when keeping it current becomes its own job, Stage 4 has arrived.
The map from Stage 2 is the brief for every build in this stage: record the work as it really happens, count a real week, name one owner. Those three habits carry the whole discipline, and the steps that feel skippable on the fifth workflow tend to be the ones that fail on the sixth. What changes as the list grows is not the loop but what can go wrong around it, which is why the board above gives every entry a watcher as well as an owner.
Where work waits now. The shortlist from the first win is usually still the list, and one constraint at a time lets each build stand on the last one's assets: the map habit, the context documents, the platform experience. Building several at once tends to compound maintenance rather than wins.
Map, choose the simplest way, pilot against the baseline, harden, measure. A team that has done it once will be tempted to skip the count on the second workflow, and the count is the part that later says whether the second workflow was worth it.
Some workflows a standard platform covers, some arrive as finished products, and for some the right answer is a specialist who builds and hardens it to fit. The question from article 2.3 decides it workflow by workflow, and it rarely works as a firm-wide policy.
Unwatched automations degrade quietly, and the cheap ones degrade quietest, because nobody is looking. The client-facing build gets an alert the moment it fails; the digest gets a monthly glance. What nothing gets is no watcher at all.
At one firm the Friday pipeline digest stopped arriving 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.
The board from the figure, kept honest against the three tests below: nothing without an owner, nothing unwatched, nothing that neither pays for itself nor gets retired.
Operating well at this level is a complete destination: several workflows running inside real limits, a record of what each agent has earned, and watching that catches drift before a client does. When keeping the whole picture current becomes a job in itself, the firm has reached the next stage, and the current, owned list of what runs is the door into it.
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 inside real limits, a written record of what each agent has earned the right to do alone, and someone looking at every automation on a schedule, so drift is caught before a client notices. 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. One page says what the firm does and does not do with AI. One list names everything that runs, with a person responsible for each entry. The page is the rules and the list is the reality, and together they answer the two questions any serious client, insurer or regulator tends to ask: what do you allow, and what actually runs?
Ask a leadership team what AI actually runs in their business today and few can answer with confidence, in firms of any size. The fix is lighter than the governance literature makes it sound: six sections on one page, one list, one review date.
Writing the one-page policy, building the register, deciding for each entry what it does on its own, putting one name on every entry, naming who may change the documents the automations rely on, and checking that both documents are in use.
Both documents drafted, in an afternoon, in a form that answers a client's question the day it arrives.
One list, everything that runs, a name on every entry. The first two entries are shown in full and the rest as rows; the fields are the same on every line.
Checks each invoice line by line and explains any variance. Touches invoices only.
Matches every line by itself; every variance goes to a person.
The finance lead
A short summary of the week's pipeline for the Monday meeting. Reads the CRM and the calendar.
Reads and reports only, so nothing needs a sign-off.
The operations lead
Retired at its second review because nobody used the output. Its brief went to the shared library first, and the entry stays here, dated.
—
—
Feeds three automations, so a change here changes all three.
Changes go through one person, and all three change behaviour on the same deliberate day.
The operations lead
The entries are this firm's. The labelled fields are the part to copy, and the retired entry is what keeps the list honest. Keep it wherever the firm keeps its working documents; what matters is that there is exactly one.
Most firms have none of this, and the ones that try often reach for the heavy version: a programme, a steering committee, a policy that runs to twenty pages and is read once. Light is the point, because heavy governance tends to die of neglect within a year, while a single page with a review date that is actually honoured keeps working. Anyone at the firm can open the register and know what runs, who looks after it and which entries were retired, and when an insurer or a client asks what touches their data, the list already says.
Six short sections. Each answers one question a client, a new hire or an insurer might ask, and none of them needs more than a paragraph.
What this page covers, and for whom.
Listed by name. Anything else is a question for the person in section five.
This firm's line: client financials never go into consumer tools.
The approval line the firm chose, stated once, for the whole firm.
A name, so that questions have somewhere to go rather than being guessed at.
A date, honoured. A policy without one drifts out of truth quietly.
Section three is one firm's line. Section four is where the human-only list from article 3.5 becomes a firm-wide sentence.
The six sections above, in plain sentences, on one page. Most of the content already exists in the decisions the firm has made along the way; the page gathers them where a new hire or a client can find them.
One entry per automation, with the same fields as the specimen, and no automation without an entry. New builds start by adding one, which is a small habit that keeps the list current without a separate effort to maintain it.
Where it lives matters less than there being exactly one, because two lists tend to disagree within a week of being created.
Each entry says which parts of the work the automation does by itself and which it hands to a person. Article 3.5 is where that line gets earned; the register is where it is written down, so that the list always says where the line sits today.
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. When the named person leaves, the entry gets a new name the same week or the automation is retired.
A price list or a description of the firm's services can feed several automations at once, so a quiet edit there changes what all of them do. Those documents get an entry of their own, with a named owner, so that a change goes through one person and every automation built on the document changes on the same day.
The three tests below, run at the first review. A policy and a register that pass them are doing the job that a much heavier programme would do, at a fraction of the cost.
With both documents drafted and owned, the firm can say what it allows and what actually runs, which is more than most firms of any size can do today, and it took an afternoon. Where each of those entries runs, and why, is the next article.
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. Your email almost certainly runs at a provider; your files may, or they may sit on a machine in the office. Nobody agonised over those choices, and AI is the same decision in new clothing. By this stage the choices add up to how much control, cost and dependency the firm carries, so it is worth being able to say, for everything that runs, where it runs and why.
Most tools are services you rent, and your protection is the contract. A few can run on machines you own, at real effort, and in return nothing leaves your control. Between the two sit real middle options, and most firms use several at once.
Matching each automation to the protection it actually needs, keeping the firm's knowledge in files you own, naming whose job it is when something breaks, and arranging now how you would leave a provider calmly.
A one-page placement page that says, for everything on the register, where it runs, why, whose job it is, and the way out.
The point is not to pick a camp. Everyday work runs comfortably as a service, and a hard constraint, such as client confidentiality or a rule about where data may be stored, earns a more controlled option. Paying for maximum control everywhere means paying for a constraint you do not have.
The provider runs everything. You start through an account, and the plan you are on decides what the provider may do with your data.
The software runs on their machines, inside a walled-off area only your firm can reach.
A provider's tool set up so that your data stays in your own systems, or in your own country.
Real effort to set up, and someone has to keep it healthy. Nothing leaves computers you control.
Most firms' honest page has nearly everything at stop one and one or two hard constraints handled deliberately further along.
One page that says, for everything that runs, where, why, whose job when it breaks, and how the firm would leave. Read against the register, and reviewed when a provider changes something.
The placements are this firm's. The columns are the part to copy: where, why, whose job, and the way out.
The documents your tools read before doing any work deserve their own line on the page, because every tool depends on them. Ordinary files in a folder the firm controls 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 the firm to that tool, so that a change of provider means rebuilding the firm's accumulated knowledge from scratch.
Everyday work as a service; a hard constraint earns a more controlled stop on the spectrum. The right answer depends on the work rather than on fashion.
A folder the firm controls, readable by any tool, because knowledge kept inside one tool leaves with that tool.
For a service, the provider's. For anything the firm runs itself, a named person, and named before the breakage rather than during it.
Providers raise prices, retire products and get bought. The three things below can all be arranged today, and they turn provider news into an item on a list.
Any automation on the register should find its answers here: where it runs, whether you could leave, and whether you could change calmly. When a provider updates or retires something, the register says what to re-check.
With the placement page written, you can say for everything on the register where it runs, why, who looks after it and how you would leave, which makes each of those a decision the firm made rather than a project it has to run. Who keeps these documents alive is the next article.
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 someone looks after them. The people plan is deliberately small: one named person for each standing piece, and adoption led by example rather than by announcement, because a team rarely uses the tools more than its leaders visibly do.
A responsibility held by "the team" is held by nobody. Announced tools tend to get quietly ignored, and demonstrated tools tend to get copied.
Naming one person for the list, one for the shared library and one for questions, leaders using the tools where the firm can see, a build day where each person automates the task they like least, and the tools pointed at the firm's own onboarding.
Three names, and one Monday demonstration in the calendar.
What holding each piece looks like at a twelve-person advisory firm. None of these is a new position; each is a few hours a month folded into a job someone already has, and in a small firm one person can carry all three.
The operations lead makes sure the quarterly review happens. A few hours a quarter, inside the job she already has.
A senior consultant prunes the shelves occasionally: retires what has gone stale, re-tries the important pieces when tools change.
Questions reach the partner who wrote the policy. Because there is a name, they get asked instead of guessed at.
Nothing changed on paper at this firm; three things stopped falling through the cracks.
Adoption is cultural before it is technical, and the habits in this article are cheap on purpose. The expensive version, a rollout programme with mandatory training, mostly produces attendance. What changes behaviour is a partner opening 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. 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.
The list, the shared library and the questions, each with a name folded into an existing job, because a piece without a name goes stale in the first busy month.
Five minutes at the Monday meeting, with the corrections shown, tends to do more than a training budget. The same question in interviews, "show me how you work with AI", says more than any line on a résumé and tells candidates what kind of firm they are joining.
Each person automates the task they like least, chosen by themselves, so nobody's work is automated at them. Whatever proves itself goes into the shared library with the builder's name on it, and the credit is why the next build day has volunteers.
The onboarding manual, converted by a model into short modules with a quick check after each and a first-day practical task. A new hire's gaps show up as flagged answers to talk through, and the manual finally gets read.
The three questions below, answered without a pause.
With three names given and one demonstration in the calendar, the documents from the last two articles have people who will keep them true, at a cost of a few hours a month. Whether each automation is still earning that attention is what the next article measures.
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. The discipline is the same one that proved the first workflow, comparing what an automation delivers with what the work cost before and deciding from the number rather than the mood. What changes at this stage is the scope: everything the firm runs, together, on a schedule it does not skip.
A firm that never retires anything is admiring its automations rather than measuring them. The retired entries are what make the kept ones credible, because a list where everything supposedly works convinces nobody.
The responsible person brings the numbers from the automation's own records, the comparison is against its best stretch rather than its launch, and the decision is written into the register with a date, retirements included.
One quarter's review for every automation on the register, done in a morning.
Every automation on the register, three questions each, a written decision with a date. If it takes more than a morning, the measuring has grown too clever.
Results accepted and used since the last review, from the automation's own records.
The tools' price plus the human hours still inside the workflow.
Against its best stretch, not its first quarter. Keep, fix or retire, dated.
Delivered its best quarter. The number, with evidence attached, is the argument for taking on the next workflow.
Two categories promoted since the last review, corrections low and stable. The scorecard came with the responsible person, not reconstructed in the room.
The count of summaries the team actually used is down against its best stretch. The new document type it mishandles is already named in its own logs, so the fix leaves the room as a work order.
Nobody uses the output, and the second review says so twice. Its brief and process notes go to the shared library before it is switched off, so the next attempt starts warm.
One firm's quarter. Decisions are dated and written into the register, retirements included.
These numbers are what earn the engine its budget. A measured win argues for the next build better than any enthusiasm, and the retirements are what make the wins believable to a sceptical partner. Automations also fade as inputs, tools and models shift around them, and the review is where fading gets caught on a schedule rather than by accident, which is why the comparison is against the best stretch rather than the launch quarter.
Results and costs since last time, taken from the automation's own records, brought by the responsible person. A meeting that reconstructs numbers from memory tends to produce the numbers the room wanted, and it takes the whole morning to do it.
An automation that merely matches its launch quarter while volume grew has quietly got worse, and only the comparison against its best stretch shows it. Flat is a finding too.
Keep it, fix it or retire it, dated, in the register. Retiring things is normal, and a retirement that leaves its brief on the shared shelf leaves the firm faster than it found it.
A keep gives the firm a number to argue for the next workflow with. A fix leaves the room as a clear work order, because the automation's own records usually say what went wrong. A retirement puts what the workflow taught on the shelf before it is switched off.
Three plain questions per automation, with the dates set in advance so that nothing skips its turn. Quarterly suits most automations; anything new or busy is worth a monthly look, and twice a year is enough for the stable and quiet ones.
With one quarter reviewed this way, the firm has an honest number for every automation it runs, a work order for each one that is fading, and a list that a client or an insurer could read without finding anything that supposedly works. Answering that client is the next article.
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. A clear, unhesitating answer tells the person asking what they actually want to know, which is that someone here is in charge of this. Firms rarely lose work for using AI; they tend to lose it for being vague about it.
Because most firms cannot yet answer the question well, answering it plainly sets a firm apart more than the tools themselves do. Whoever asks, the honest answer already exists in writing.
One sentence in the engagement letter that names the tool, the use and the training answer, a short summary kept current from the register, and one conversation with counsel written into the policy.
The engagement-letter sentence, and a questionnaire answered from the shelf within the week it arrives.
A client's procurement team sends its AI question list. Every answer comes from a document that already exists, and the reply goes out the same week without a meeting.
Named in the policy's approved-tools section, and named again in each engagement letter with what they are used for.
Listed per automation: what it does, what data it touches, where it runs. The summary attached is current as of this month.
Work that reaches the client is signed off by a person. Where that line sits is written in the policy, and each automation's entry names its responsible person.
No. The engagement letter states it: drafting and document review are assisted by the named tool under the firm's review, and client data is not used to train it.
Each automation carries one page of instructions, including how the work runs by hand, and a named person responsible for it.
The questions are typical of the lists clients and insurers now send; the answers are one firm's. What transfers is that every answer names the standing document it came from.
This is what the whole stage buys: a week of scrambling becomes a same-week reply, assembled from the policy, the register and the letter that already exist. 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 tends to write itself from practice.
Clients learn from the letter which tools touch their work and what they are used for, before they have to ask. The sentence in the callout is one firm's; the three parts, the tool, the use and the training answer, are what to keep.
One page distilled from the register, refreshed whenever the register changes, is enough to answer most question lists. The specimen above is that page in use.
For a typical services firm using general-purpose tools, the law tends to ask less than the headlines suggest, and what it asks changes; one conversation with your counsel, written into the policy with a review date, is what keeps the firm's answer both honest and current.
Readiness is checkable, and all three checks below read from documents that already exist.
With the sentence in the letter and the summary on the shelf, the firm has an honest answer ready for whoever asks, in writing, before the question arrives. The last article builds the companion to the register: the collection of what works.
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.
Book a 45-minute diagnostic call. We’ll map your highest-ROI automation opportunities, recommend the one to build first, and tell you what it would take to build. No deck, no obligation.