Document the Process First, or the Agent Scales the Chaos

The first time we tried to put AI into a delivery operation I was running, we built an agent that impressed everybody, and then nobody knew what to do with it.

The model could do the work we showed in the demonstration. What we hadn't managed to give it was a clear description of how the operation actually ran, so we had a powerful tool and no meaningful change in the business.

That is why I tell owners to document the process before giving an agent responsibility for it. If the job still lives in people's heads, the software doesn't know the job just because it can give you a good answer.

And I don't mean writing a large manual about how everything ought to work. I mean getting the checks, decisions and exceptions your managers already use into a document the system can read.

When I first asked our managers to explain their workflows, the questions sounded straightforward. What do you do to monitor the consultants, what do you check, how do you keep track of tasks and projects, what tells you something is going right or wrong?

Getting the answers down was one of the biggest challenges. These were people doing the job every day, but they weren't used to taking what they knew and putting it on paper for somebody else to follow.

That distinction matters, because it would have been easy to call the problem resistance. The managers weren't bad at their jobs, the firm had simply relied on them carrying the process in their heads, and now we were asking a machine to work without access to it.

We built the agent anyway, and the prototype was impressive. But an impressive prototype that doesn't change the delivery operation is still on the wrong side of the Production Gap, the gap between a working demonstration and a system the business can depend on.

If you've had a pilot like that, I would look at what job you gave it before assuming you need a better model.

Your project tool can show the tasks and your CRM can show the account, but neither necessarily tells the whole story. There may be a side spreadsheet, an approval in a message, or a rule the manager follows because something went wrong with a client once.

That is part of the process too. If the agent can only see the official version, it can miss the part that keeps the real work moving.

In Reworked's April 2026 article on process documentation, platform engineer Pavan Madduri described an agent trained only on the official workflow in the ticketing system as "learning a fantasy." He was talking about infrastructure, but the gap between the recorded process and the working one is familiar in service delivery too.

You don't fix it by listing every possible case you can imagine and pretending the list is complete. Write down what the manager is looking for, which information they use, what a signal means and when somebody has to make a decision.

For example, "check the project" doesn't give the system much to do. The useful part is what you check, whether a task is overdue, whether the client has gone quiet, whether something in the last meeting suggests the engagement needs attention.

And it needs to know what happens next. Does it produce a report for the manager, ask for missing information, or stop and wait for a person because the next decision is outside its role?

Once we managed to get that knowledge into a document, the same effort started producing useful work. Triggers started reports, and those reports warned managers to step into a project or give a consultant feedback.

That was the change I had been looking for. The agent was no longer waiting for somebody to think of something to ask it, it had a piece of the operation to watch and a reason to act.

There are twelve conditions in the network example, drawn from how management runs the work. They include overdue tasks, churn signals from customer meetings, the quality of WhatsApp responses, opportunities to sell useful additional work, and overdelivery signals.

By overdelivery I mean noticing an artifact worth producing that would improve what the client already bought. The system can bring the opportunity to somebody's attention, and a person still decides what the engagement needs.

None of those conditions came from a vendor's generic list. They came from management knowledge that had to be made available to the system.

Compare that with a manager opening a chatbot and asking it to draft a check-in email for a client. The email can be perfectly good, but the manager still had to notice the client needed attention and start the task.

When the system watches the condition and warns the manager, it takes over part of that noticing work. That's a meaningful difference between a chat tool and an AI employee with a defined job, even when both produce an email at the end.

Across the 150+ franchise units in the delivery data I review, the recorded split was roughly 80% using chatbots, 15% using rigid workflows that run on triggers and 5% running autonomous agents defined by conditions. That is a picture of those units, not the whole service industry, and it will change as the tooling rolls out.

I wouldn't tell you that documentation alone explains the split. It was a necessary part of getting our own system to do useful work, but access, checking, training and the way the firm uses the output matter too.

The wider research helps explain why process work deserves attention in the first place. In Asana's 2023 Anatomy of Work index, knowledge workers reported spending 58% of their day on coordination and other work about work.

They also estimated they could save 4.9 hours a week with better processes. Those are survey responses from knowledge workers across several countries, not measured savings from AI or a promise about what documenting your firm will return.

But you can see the kind of work to investigate, the time spent finding out what's happening before anyone can do something about it.

Now, the first document won't be complete. People leave things out because the step is so familiar they no longer notice they're doing it, and real work will find gaps you didn't find in the interview.

This is where an AI agent is different from the expectation many of us bring to buying software. We expect to configure a product and use it, but getting an agent to do your firm's work takes a period of trying, reviewing and correcting the system around it.

You put a first version into controlled use, get people involved in testing it on real work, and read what happened. Look at the conversations, the errors, and the things the agent couldn't do.

Then update the software, the documentation and the rubric, the written rules you use to judge whether the output is good enough. Repeat that process as the next set of problems appears.

The documentation is easy to forget in that loop. Someone fixes a prompt or adds a check, but the description of the job still says the old thing, and now the system has two versions of how the work should run.

Keep them together. The output-validator workflow explains the checking side, but the person responsible for the process also needs to keep its written description current.

And please don't hear "try it while it's still unreliable" as permission to send unchecked work to a client. The team can test real work with review and clear limits while you learn what the system can handle.

In my experience, keeping everybody committed through that period is harder than building the first version. You need people to keep trying, report what failed and help you get to the output the business needs, rather than judge the whole project by the first awkward attempt.

The work has more than paid off in the cases I'm describing, but I can't give you one timeline that every firm can use. The pace depends on what the job requires, the gaps you find and how quickly the team can make and test changes.

So if you want to start, don't send your operations lead away with "document your workflow" as homework and wait for a perfect file. Sit with the person doing the work and ask them to walk you through it while somebody writes.

Start with what they check each day and each week. Ask how they monitor the people doing the work, where they look, and what they notice that wouldn't be obvious to a new person.

Then follow how tasks and projects get tracked. If the answer involves a message thread or a spreadsheet outside the main system, write that down too, because the agent won't know it exists from the process chart.

Ask what warns them that something is going right or wrong. Stay with one example long enough to understand which information made them act and what they did next.

For one important deliverable, ask how they know it's good enough before a client sees it. That starts the rubric, and "the manager checks it" is not the answer yet, you need to know what the manager checks.

Then ask where the hours would go if the system did one of those checks for them. The time needs a job too, or it can disappear into the rest of the week without improving the business.

That's a useful first document. It doesn't have to describe the whole company, it has to describe one piece of work well enough that you can test what you've written against what actually happens.

On the Delivery Model Ladder, that makes it possible to move beyond individual tool use and rebuild a workflow. The AI readiness assessment asks whether that foundation exists, and it comes before the changes to managers' jobs in Fewer Managers, More Managing.

There is one limit you need to settle first. If nobody owns the delivery process from start to finish, and nobody can explain what should happen when it crosses between teams, writing is not your first problem, ownership is.

And at the size of firm I'm writing for, I would start with that manager conversation before looking at enterprise process-mining software. You may need tools later, but you can learn a great deal by asking the person who already keeps the work moving.

Writing the process down does not put an autonomous agent on your delivery team. It gives you a job you can finally hand over and test.