# Process automation: where to start, where to stop.

Most automation projects fail at scoping. A team gets excited, picks a flashy workflow, builds for two months, and ships something that breaks the first time the input shape changes. Then the team goes back to doing it by hand and the project gets quietly buried. Six months later, the conference talk about how AI is transforming the company is still on the calendar. The actual work is still being done by people, late at night, at the end of the quarter.

The error is almost always the same. Teams pick automation projects by visibility, not by fit. The CEO mentions the executive summary they read on their flight. The board asks what we are doing about AI. The team picks the workflow that sounds most impressive in a slide. Two months later, the workflow is broken because the input was never really repeatable, and no one wants to admit the project did not survive contact with reality.

Good automation scoping starts with three filters: repetitive, well-defined, low-stakes. If the task is not repetitive, if it shows up only twice a quarter, automating it costs more than doing it. If the task is not well-defined, if the rules change from instance to instance, the automation will need so much hand-holding that it stops being automation. If the task is high-stakes, if a wrong output goes to a regulator, a customer, or a financial filing, humans have to stay on the loop, which changes the entire architecture.

The intersection of those three filters is smaller than most teams expect. Filing standard reports? Yes. Drafting customer support replies? Yes, with human review. Producing earnings releases? No, too high-stakes. Synthesizing meeting notes? Yes. Onboarding new vendors? Sometimes, depending on how standardized the vendor packet is. The right answer is almost always more boring than the team wants it to be.

Once you have a candidate, build it small. The mistake we see most often is building the automation as a finished product before it has been tested against reality. The right model is the opposite: build a thirty-percent version that runs on real inputs, ship it to a single user, run it for two weeks, then decide whether to invest more. Most candidates wash out at this stage, and the team learns more about the workflow in two weeks of real use than two months of planning would have produced. The two-week test is the cheapest insurance you can buy.

Human-on-the-loop is a design choice, not a fallback. Every automation we ship has a UI where a human can see what the system did, change it, and override it. The UI is not separate from the automation, it is part of the automation. We use the same interface for development, QA, and production. This sounds like overhead. It is the difference between a system that survives a year and a system that fails the first time the team is on vacation. The team that owns the automation has to be able to look at it and trust it, and trust comes from visibility.

Documentation is the deliverable, not the system. The Python file is the easy part. What matters is the runbook: what prompts are in use, what tools the agent can call, what fallback behavior triggers when the model is unavailable, what to do when the output looks wrong, who to escalate to. Six months from now, the engineer who built it will have moved on, and the runbook is what lets someone else operate it. If the runbook does not exist, the project does not exist; it is a temporary win waiting to be unwound.

A specific anti-pattern to watch for: agentic systems with too many tools. We have inherited automation projects where the agent has access to fifteen APIs, twelve internal tools, and the entire web. They never work for long. The more tools an agent can call, the more ways it can fail in ways the team did not anticipate. Limit tools to the smallest set that gets the job done. If you need a sixteenth tool, the workflow is too broad. Split it.

Measure hours saved, not "AI adoption." The metric that matters is how many hours per week the automated workflow gives back to your team. That is the number you take to the board. "Forty percent of our reporting is now AI-assisted" is a vanity metric. "We saved twelve hours a week of analyst time, and the analyst now spends those hours on accounts that need attention" is the real story. The first sentence is forgettable. The second one buys you the next budget cycle.

So what does a quarter of doing this right actually leave you with? One workflow is automated, with a human-on-loop UI, a runbook, and measurable hours saved per week. The team uses it daily. The next two candidates are scoped and queued. The CEO has a real number to share with the board, not a vendor demo.

**What we ship.** A workflow audit, a scoped automation built in your stack with humans on the loop, runbook documentation, and a quarterly review. Fixed-scope engagement. Your team operates it.