The best first AI automation is the boring one: a guide to agentic process automation

What is agentic process automation?

Agentic process automation uses AI agents to run a defined business process end to end. The process sets the steps, the rules, and the limits. The agent handles the judgment inside each step, such as reading a messy email, pulling out the details that matter, or deciding which rule applies. The process decides what gets done and the agent decides how.

The value is in where people's time goes. Most companies run hundreds of processes that skilled people handle by hand because nothing else could: copying details out of emails, updating records, chasing status. In our conversations with enterprise teams this year, almost every process on the table was worth six figures a year in staff time alone. But the bigger cost is the work those people never get to.

Sales is a good example. As a seller, I used to spend about 40% of my week inside Salesforce, logging calls and updating deals. Agentic workflows now run those updates for me. Now I get to spend that time face to face with customers, which is what helps me close deals and drive revenue for the company.

Why the best first process is the boring one

The best first agentic workflow is a high-volume, repetitive process that people already do by hand and would happily give away. It's rarely the process anyone pictures when they hear "AI agents."

A lot of teams assume agentic automation has to start big, with a multi-agent system that runs a whole department. Those projects take months to build and are hard to check once they're running. Many of them stall before they save anything.

To find a better starting point, ask each team where their time goes on work that sits outside their actual job. Write down every process that comes up and how often it happens. The best first candidate is usually near the top of that list.

For one team we spoke with, the answer was package tracking. They track about 600 packages a week. Each package gets five or six status updates by email, and someone reads every one and copies the details into a spreadsheet. That's over 3,000 updates a week. Even at two minutes each, it adds up to 100 hours of copying and pasting. That's two and a half full-time people.

Processes like this make a good first project because they're defined and contained. The steps are the same every time: read the email, find the package, update the record, flag anything unusual. The agent only needs access to one inbox and one spreadsheet. What it does need is reasoning. Every carrier writes its emails differently and every vendor formats them their own way, so a script can't keep up. That mix of a fixed process and messy inputs is exactly what an agent is good at. The savings show up in weeks.

Why RPA never automated this work, and why agents can

Robotic process automation (RPA) could only automate processes where every input looked the same, so the large set of processes built on emails, PDFs, and vendor portals stayed manual.

RPA bots work by repeating the clicks and keystrokes a person makes. That holds up when every screen and every file follows the same format. When a sender changes an email template or a portal moves a button, the bot breaks. In a 2020 Forrester Consulting study, 45% of firms said they dealt with bot breakage weekly or more often. Teams ended up spending their automation budget keeping old bots alive. The messier processes never made the list.

Language models changed that. An agent can read an email or a document the way a person does and pull out what matters, whatever the format. The processes RPA had to leave behind are now within reach.

The risk now runs the other way. Teams try to hand everything to a single agent.

Why a do-everything agent is the wrong starting point

A single general-purpose agent with broad access and open-ended instructions is hard to scope, hard to check, and hard to fix, so it rarely makes it into production.

It's a tempting idea. Give one agent access to email, the CRM, the ERP, and the shared drive, and tell it to take care of operations. The trouble shows up in the design. With access to every system, one wrong call can land anywhere. With open-ended instructions, the agent takes a different path on every run, so nobody can say in advance what a correct run looks like. When something goes wrong, there's no single step to fix.

Personal agents are where this idea comes from. Meta's Muse, OpenAI's dots agent, and the open-source OpenClaw can book travel, answer email, and fill out forms for one person, and they're useful for that. They get broad access and a loose instruction, and the person using them catches the mistakes. That setup doesn't carry over to a business process that moves money or touches customer data. Within weeks of OpenClaw going viral, security researchers were already treating it as a shadow AI risk for enterprises, pointing to malicious add-ons and agents running with access security teams can't see.

A failed first project costs more than the project itself. Once an agent gets something visibly wrong, the people around it start doubting automation in general. The next proposal gets a harder hearing, and the one after that may never get approved. The first agentic workflow sets the organization's appetite for the second, so it has to work.

The teams building these systems say the same. Anthropic's engineering guide to building effective agents recommends "finding the simplest solution possible, and only increasing complexity when needed," and notes that "workflows offer predictability and consistency for well-defined tasks."

Most business processes are well-defined tasks. The better approach is to give the agent a process to work inside.

The agent decides how, the process decides what

Agentic workflows work best when you design the process first and let the agent handle the judgment inside it. The process decides what gets done. The agent decides how.

The process sets four things:

• The steps and their order. What happens first, what happens next, and where the work ends.
• What each step can touch. The agent in each step can read and change only what that step needs.
• What a valid result looks like. Every output is checked against that definition before anything gets written.
• When a person steps in. The cases the agent hands off, such as a missing package or an unknown sender.

Inside those lines, the agent does the part a script never could. It reads messy input, decides which of the allowed actions fits, and fills in the result.

In the package example, the process is fixed: read the email, identify the package, pull the status, update the sheet, flag any delay. The agent's job is working out which package each email is about and what the carrier is actually saying, in whatever format that carrier uses.

This design also gives you a record of every run. Each decision is tied to the step it belongs to, along with what the agent decided, why, and what it read. That record is called agentic provenance. It lets you check any run and fix the exact step that caused a problem. That's how the workflow keeps the organization's trust as it takes on more.

How to choose your first process and get started

Start by listing where each team's time goes, pick the process that passes six checks and has the biggest payoff, write that process down, and run it on real work while you measure the hours it gives back. You need two people to begin: the person who owns the process and one person to build it.

1. List the processes. Ask each team where their time goes on work outside their core job, and how often each task comes up.

2. Check each candidate. A process is ready for agentic automation when it passes these six checks:

• Volume. It happens dozens or hundreds of times a week.
• Defined steps. You could draw it on a whiteboard, and it looks the same every time.
• Messy input. It depends on emails, PDFs, or documents in different formats. If a plain script could handle it, use a script.
• A clear correct result. You can say exactly what "done right" looks like.
• Contained reach. It touches a handful of systems.
• Outside the core job. The team doing it today would happily hand it off.

3. Put a number on it. Multiply how often the process runs by the minutes each run takes and the hourly cost of the people doing it. For the package-tracking team, that's about 100 hours a week. At an assumed $50 an hour across 48 working weeks, it comes to roughly $240,000 a year in staff time. That's one process, before counting the opportunity cost of what the team could have worked on instead.

4. Write the process down. Map the steps, the systems each step touches, what a valid result looks like, and the cases that go to a person.

5. Run it and measure it. Put the workflow on real work and track the hours saved and the results against the team's own numbers. That gives you the business case in your own figures.

6. Move to the next one. The second process reuses the same design, so it goes faster.

FAQ

Which steps should be code and which should be the agent?

If a step's logic fits in an if-statement, write it as code. Give the agent only the steps that need reading or judgment, like interpreting an email or matching a document to a record. Code is faster, cheaper, and does the same thing every time, so the agent's part of the workflow should stay as small as the process allows.

How do you define the output of an agent step?

Give each agent step a strict output schema: named fields, a type for each, and fixed values wherever the answer comes from a known list, such as a status. The agent fills in the schema. Code validates it before anything downstream uses it.

What happens when an agent's output fails validation?

Send the output back to the agent with the validation error and let it retry, up to a set number of attempts. If it still fails, route the case to a person with the original input and the failed output attached. The person picks it up with full context.

How do you stop a workflow from acting twice on the same input?

Give every input a stable ID, such as an email's message ID, an invoice number, or a ticket ID. Record the ID when the workflow first processes it and check it before any write. Retries and reruns then can't create duplicate updates or payments.

How do you test an agentic workflow before it goes live?

Replay a recent month of real inputs through the workflow and compare its results with what the team actually recorded. Every mismatch points to a gap in the process design or a step that needs a tighter schema. Fix those before the workflow touches live systems.

How do you scope access for each step?

Give each step only the permissions its job needs. A step that reads documents gets read-only access to where they live. A step that writes results gets write access to that one destination. No step holds credentials it doesn't use, so a mistake in one step can't reach systems outside it.