Most companies have AI in the building already. Usually it is a chat window that people open a few times a day, ask something, and close again. Leadership then asks a reasonable question: what comes after that?
There is not one way to use AI in a company. There are three, and they are different enough to deserve separate names. Chatbot: a person asks a model something and decides what to do with the reply. Coworker: a person hands a model a whole job, and it works through the documents and systems that person already uses. Code: the model is built into the systems the business runs on, and the work happens without anyone asking for it.
The same models power all three. What changes is how much of the company the model can see, how much it is allowed to do, and who checks the result. Each stage is useful, each has a limit, and each asks the company for something before it will work.
Stage one: a chatbot in a window
This is the stage nearly everyone is in, and it is a good place to be. A person asks for a draft, a summary, a rewrite, an explanation or a second opinion. The model answers. The person decides what to do with the answer.
It needs no set-up. Nobody has to connect a system, design permissions or plan a project, which is why it spreads so quickly and why it should be taken seriously. Writing, learning and getting unstuck make up a surprising share of most jobs, and this stage helps with all three from the first day.
The limit is just as plain. The model knows nothing about the company beyond what is pasted in, and it forgets everything when the window closes. A person has to supply everything it knows and do something with everything it produces. For a one-off, that is fine. For a weekly task with the same inputs, the handling becomes most of the work. And nothing happens when nobody is typing.
What stage one needs from the company is small, but it is not nothing:
- An approved tool, so that company work is not happening on personal accounts.
- A clear line on what may be pasted in. Customer records, contracts and anything regulated need a decision, not a guess.
- A few worked examples of good use from inside the company, which do more than any policy document.
Stage one also does a job that is easy to miss: what people ask it is a shortlist of the recurring tasks worth moving up. The questions typed every Monday morning are the candidates for stage two.
Stage two: a coworker with a workspace
At the second stage the model stops being something you talk to and becomes something you hand work to. It gets a workspace: a folder of files, a few tools, perhaps a read-only line into the CRM or the accounting package. It works through the steps on its own and comes back with a finished piece of work for you to look at.
What crosses the table is different in kind. A question wants an answer; a brief wants a result. The brief says what the finished thing should look like, where the material is, and what the agent must leave alone. Some illustrative examples:
- A practice manager hands over the week’s intake forms and asks for a list of the incomplete ones, grouped by what is missing.
- An estimator at a construction firm puts six supplier quotes in a folder and asks for a comparison against the prices paid on the last three jobs.
- A support lead has the overnight queue drafted into replies, each one waiting for a person to read and send.
In every case a person still looks at the output before it leaves the building. The model does the hours of work; the person does the minutes of checking.
What stage two needs is where most companies find their first real gap. An agent can only work on what it can open. A shared folder with sensible file names qualifies; attachments scattered across inboxes, and the knowledge of whoever has been there longest, do not. Permissions need a deliberate choice, and reading and writing are separate choices: reading is cheap, writing is where mistakes get expensive. And the brief has to be written clearly enough that a careful stranger could follow it, which is harder than it sounds.
The readiness test is short. Can you point at the folder? Can you write the brief in a paragraph? Can a person check the result in a fraction of the time the work would take? If the checking takes as long as the doing, the task is not ready, and no model will change that.
Stage three: code inside the system
At the third stage, nobody asks. The work is triggered by an event: a form arrives, an invoice lands, an order changes, a ticket is opened. The system reads what it needs from the record, applies the company’s rules, writes the result back, and sets aside the cases it is unsure about for a person, with the reasons attached. The person’s job changes from doing each case to watching the whole: the exceptions, and a weekly sample of what went straight through.
This is where the returns are largest, because the work runs whether or not anyone is at a desk, and it is where the cost of getting there is real. Intake forms turned into records, invoices matched to purchase orders, enquiries routed to the right person: none of it is difficult because of the model. The difficulty is everything the model has to sit inside.
What stage three needs is a list, and every item on it belongs to the company, not to a vendor:
- A written process, exceptions included. Not a diagram. The actual rules, specific enough that two people would reach the same answer, with the “unless” clauses that experienced staff carry in their heads.
- One record it can read and write. If the order, the delivery and the invoice sit in three tools with three versions of the customer’s address, the first job is the data foundation, not the agent.
- A definition of done that a machine can check. What a matched invoice means; where each kind of enquiry goes.
- A trail. What each step saw, what it produced, which version of the rules produced it, and who overrode it.
- A test set built from real cases, run before any change to a prompt, a model or a rule, so that improvement is a number rather than a feeling.
- A boundary. What the system may change on its own, what needs a person at the gate, and a threshold for sending cases to the queue that starts cautious and widens as the record justifies it.
- An owner and a number. Hours per case, days to close, exception rate. Someone reads it every week.
None of this requires everyone to be an engineer. It does require engineering, which is why we treat stage three as a build rather than a purchase, and why the data foundation comes first. The model is the smallest and most replaceable part.
Which stage does the work belong in?
The three stages are not a ranking, and the goal is not to push everything to the top. A working company uses all three at once. Decisions, judgement calls and questions that will only be asked once stay at stage one, because what is wanted there is a better conversation, not a finished output. Anything a person needs to read in full before it goes out belongs at stage two. Stage three is for work that is frequent, rule-bound and checkable.
Three questions about the work itself settle most cases:
- Who has to see the result before it counts? If a person must read every output anyway, stage two is the ceiling for now. If a rule or a sample can check it, stage three is open.
- Could a new hire run the process from the written version alone, on their first morning, with nobody to ask? If the written version would not get them through the week, the process is not ready to run on its own.
- What would it cost to undo a mistake? A list that someone will check costs nothing to correct. A refund that has been paid, or a price that has gone live to customers, costs a great deal. Reversible work can run with a sample check; irreversible work keeps a person at the gate.
Two mistakes are common. The first is to roll the tool out to everyone, watch the usage climb, and mistake that for the job being done. The second is to go straight to stage three on a process nobody has written down, and discover the exceptions one incident at a time.
Moving one process up
Rather than trying to shift the whole company, pick a single process and take it through the stages in order.
Choose one that runs daily or weekly, has a clear start and finish, and already produces something you can measure. Move it to stage two first: give an agent the folder and the brief, and have a person review every output. This is cheap, and it does the discovery that stage three will need. The reviewer’s corrections are the exceptions nobody had written down. Keep them and they become the first test set. The rules the reviewer keeps applying become the first draft of the written process.
When the reviewer stops changing things, the process is ready to run on its own. Connect it to the record, set the threshold cautiously, put the exceptions in a queue, and give it an owner. Then take the next one. In a typical engagement the first process makes it through all three stages in weeks, and the second goes faster because the record, the trail and the habits already exist.
What the stages are for
The useful question about AI in a company is no longer whether it is being used. It is whether, for any given piece of work, someone can name the stage it sits in, explain why, and say what is missing before it could sit one higher. Companies that can answer that see the results in their operating numbers. Companies that cannot are left with a tool everyone uses a little and nothing that runs differently.
If you want help answering it for your own processes, that is where most of our engagements begin.