Map the Manual Work Before You Build the Agent

The Agent Is Not the Starting Point

Every failed agent project I have seen started the same way. Someone watched a demo, got excited, and asked the engineering team to build an agent before anyone had written down what the current process actually does. Six weeks later there is a prototype that handles the easy cases and breaks on everything real.

The spreadsheet is not the enemy. The spreadsheet is the documentation. When a finance team has been running month-end variance analysis in a shared workbook for three years, that workbook contains institutional logic that nobody has ever articulated out loud. Formulas that handle edge cases. Color codes that mean something. A tab labeled DO NOT TOUCH that absolutely does something critical. Before you automate any of it, you have to read it like an archaeologist.

The right order is map, then identify the boring middle, then automate that middle, then put the human back at the decision. Skip any step and you will rebuild the system twice.

What Mapping the Manual Process Actually Looks Like

I do not mean a process diagram drawn in a whiteboard session. I mean sitting with the person who runs the spreadsheet and watching them do it, step by step, while you take notes in plain language.

In a distribution operation I worked with, the team was manually pulling three reports every morning, cross-referencing order exceptions against carrier status feeds, and then writing a summary email to the operations manager. The whole thing took about ninety minutes. When I asked the analyst to describe the process, she said it took thirty minutes. The other hour was invisible to her because it was habit. Watching her do it revealed four decision points she had never mentioned, two of which required judgment calls that varied by customer tier.

Those judgment calls are the most important thing you will find in this exercise. They are where the human is genuinely needed. Everything else is a candidate for automation. The map lets you separate those two categories before you write a single line of agent logic.

A useful mapping session produces a list that looks like this.

1. Where does the input data come from and how does it arrive
2. What transformations happen to that data, in what order
3. Where does a human look something up, compare, or calculate
4. Where does a human make a judgment call that could go either way
5. What is the output and who receives it
6. What happens when something is wrong or missing

Step six is the one teams always skip. It is also the one that breaks agents in production.

The Boring Middle Is Where Agents Earn Their Keep

Once you have the map, the boring middle becomes obvious. It is the work that is repetitive, rule-based, and low-stakes if done slightly wrong. Pulling data, formatting it, checking it against a threshold, routing it to the right place. This is where an agent delivers real value because it does this work faster, at any hour, without getting tired.

In a manufacturing context I have worked in, the boring middle was the daily quality exception report. Sensor data came in from the line, someone checked it against spec tolerances, flagged anything outside range, and forwarded it to the shift supervisor. The agent now does that entire loop. The shift supervisor sees a structured summary with the flagged items already ranked by severity. What used to take forty minutes of a technician's morning is now ready before the shift starts.

Notice what the agent does not do. It does not decide whether to halt the line. It does not contact the supplier. It does not update the maintenance schedule. Those are judgment calls with downstream consequences that require a human who understands context the agent does not have access to.

The mistake I see most often is scope creep in the agent design. Someone adds one more step, then another, and suddenly the agent is making decisions it was never qualified to make. The map is your protection against this. If a step appeared on your list as a judgment call, it stays with the human. Full stop.

Keeping the Human at the Decision Without Making the Tool Useless

There is a failure mode on the other side of scope creep, which is building an agent that asks for human approval so often it creates more friction than the spreadsheet did. I have seen this in field operations where the agent was flagging every third record for review because the team was nervous about errors. The field coordinators stopped trusting it within two weeks and went back to the manual process.

The design principle I use is that the human should be at the decision, not in the loop for everything. That means the agent handles all the retrieval, formatting, comparison, and routing without asking permission. When it reaches a genuine decision point, it presents a clear recommendation with the supporting evidence, and the human confirms or overrides. One interaction, not ten.

In a financial services workflow I helped build, the agent processes incoming client data requests, pulls the relevant account history, checks it against compliance rules, and drafts a response. If the request is routine and the compliance check passes, the agent queues the draft for a thirty-second human review before sending. If anything is flagged, the agent escalates with a specific explanation of what it found and why it stopped. The reviewer is never asked to re-examine the data. They are asked to make a call on a specific question the agent has already framed.

That framing is the agent's most important job. A well-designed agent does not just surface information. It reduces the cognitive load of the decision so the human can act faster and with more confidence.

Handling the Edge Cases Before They Hit Production

The step six I mentioned earlier, what happens when something is wrong or missing, deserves its own section because it is where production agents live or die.

In a spreadsheet, a missing value produces a blank cell or an error that a human notices and handles. In an agent, a missing value can propagate silently through several steps before producing an output that looks correct but is not. I have seen this cause real problems in distribution operations where a missing carrier code caused the agent to default to a fallback routing rule that nobody had reviewed in months.

Before you go live, you need to enumerate the failure modes from your map and decide explicitly what the agent does in each case. Does it stop and escalate? Does it proceed with a flag? Does it use a default? Each of those is a design decision that should be made deliberately, not discovered in production.

I also want to be honest about model behavior here. The language models and reasoning systems that power these agents will sometimes produce outputs that are wrong in ways that are hard to predict. That is not a reason to avoid them. It is a reason to build verification steps into the workflow, especially before any output reaches a customer or a financial system. Treat the model as a capable but fallible team member and design accordingly.

The Order That Ships

I have shipped agents across finance, manufacturing, distribution, and field operations. The ones that are still running a year later all followed the same sequence. The ones that failed skipped steps.

Here is the order.

1. Sit with the person who owns the spreadsheet and watch them do the work
2. Write down every step in plain language, including the ones they do not mention
3. Identify the judgment calls and mark them as human-owned
4. Identify the boring middle and scope the agent to that work only
5. Define what the agent does when data is missing, wrong, or ambiguous
6. Build the human decision point as a single clear interaction, not a review queue
7. Run the agent in parallel with the manual process until you trust it

Step seven is not optional. Running in parallel feels slow. It is actually the fastest path to production confidence because it surfaces the edge cases in your real data before they matter.

The teams that skip to step six and go live immediately are the ones calling me six weeks later to rebuild the thing.

The Practical Takeaway

If you are an operations or technology leader looking at a spreadsheet-heavy process and wondering whether an agent could help, the answer is almost certainly yes. But the value is not in replacing the spreadsheet. It is in removing the manual work between the data and the decision.

Start by printing the spreadsheet and sitting with the person who runs it. Ask them to walk you through a bad day, not a normal day. Bad days reveal the edge cases and the judgment calls that the normal workflow hides. That conversation is worth more than any prototype you could build in the same amount of time.

The agent is the last thing you design. The process map is the first. Get that order right and the rest follows.