Most business process automation projects with SI agents fail at the first decision, not the last. The team picks the process that is most painful, or most visible, or most exciting to demo, and discovers months later that it was also the one with the most exceptions and the least tolerance for mistakes. The model was never the problem. The choice of process was.
This guide covers where we start: how to pick the first process, how to map it honestly, how to split it between agent judgment and deterministic steps, where approvals belong, and how to measure whether it is working. It is the same order we follow when we build SI applications for clients. None of it is exotic. Most of it is the discipline that separates a pilot from a production system.
Pick the first process with three filters
We score candidate processes on three things before anyone writes a prompt.
- Volume. The process should run often enough that improving it matters and that you collect real data quickly. A task that happens a few times a month will not teach you anything in a reasonable time.
- Variance. Look for inputs that vary in form but not wildly in meaning: emails asking for the same handful of things in different words, or documents with the same fields in different layouts. Too little variance and plain automation does the job. Too much and the agent spends its life on exceptions.
- Cost of error. Pick a process where a mistake is cheap to catch and cheap to undo. Internal triage, routing, drafting and data entry with review are good first candidates. Payments, contract terms and anything sent to customers unchecked are not.
The sweet spot is high volume, moderate variance and a low cost of error. It is rarely the process leadership is most excited about, and that is fine. The first project exists to build the trust, tooling and evaluation habits that the harder processes will need.
Map the process before you automate it
The documented process and the real process are almost never the same. Before designing anything, sit with the people who do the work and watch them handle real cases. The workarounds, the side spreadsheets and the "I just know to check this" steps are where the actual logic lives.
- List every step from trigger to finished outcome, including the ones nobody wrote down.
- For each step, note the inputs it reads, the systems it touches and the decision it makes, if any.
- Collect real examples, including the ugly ones, and keep them. They become your evaluation set.
- Write down the exceptions and what a person does with each one today.
- Record a baseline: how long a case takes, how often it is escalated and how often it is redone.
That baseline matters more than it looks. Without it, nobody can say later whether the agent helped, and the project gets judged on anecdotes from whoever shouts loudest.
Decide what the agent does and what code does
Go through the map step by step and ask one question of each: does this step need judgment over messy input, or does it follow a rule? Reading a free-text request, classifying it, pulling fields out of an unstructured document, choosing between a few routes and drafting a reply are judgment steps. Looking up a record, calculating a total, checking a threshold, writing to a database and sending a notification are rules.
Give the agent the judgment steps and make everything else deterministic code that the agent calls as a tool. A model should not be doing arithmetic on invoice totals or deciding which CRM field to overwrite. Narrow tools with validated inputs keep the agent’s freedom where it is useful and nowhere else. Our walkthrough on how to build an SI agent for your business goes deeper on tool design and scoping.
Give the agent the judgment steps and make everything else deterministic code that the agent calls as a tool.
Sometimes this exercise shows there is only one judgment step in the whole process. That is a good outcome, not a disappointment. A workflow with a model in one step is easier to test and cheaper to run than a full agent, and you can widen it later once you trust it.
Put approvals where the risk is
Not every action needs a human, and an agent that asks permission for everything is just a slower form. Tier the actions by what a mistake would cost instead.
- Read-only actions, such as lookups and searches, run freely.
- Reversible writes inside your own systems run automatically and are logged so a reviewer can spot-check them.
- Irreversible actions, anything that moves money and anything leaving the company go to a person for approval, with the agent’s reasoning and evidence attached.
Every action the agent takes, approved or not, should leave a record: what it saw, what it decided, which tool it called and what came back. That audit trail is what lets you debug a bad decision, and it is what lets you loosen approvals later with evidence instead of hope. We cover approval design in more detail in human-in-the-loop SI agents.
Design the approval screen as carefully as the agent. A reviewer should see the original input, the proposed action, the evidence the agent used and a one-line reason, then approve, edit or reject in a single step. If approving takes longer than doing the task by hand, reviewers will either rubber-stamp everything or route around the system, and both defeat the point.
Measure against the baseline
Before the agent acts on anything, run it in shadow mode. It processes real cases in parallel with the people doing the work today, proposes what it would do, and touches nothing. Comparing its proposals with the human decisions on the same cases is the cheapest evaluation you will ever get, and it surfaces the exceptions your map missed before they reach a customer.
Once it is live, compare it with the baseline you recorded during mapping, on the same kinds of cases.
- Time from trigger to finished outcome.
- How often cases are escalated to a person, and why.
- How often a reviewer edits or rejects what the agent proposed. This is the most useful signal you have.
- Errors found downstream, after the agent’s work was accepted.
- Running cost per completed case, including model calls and review time.
Feed every rejected or corrected case back into the evaluation set. Over time the set becomes a precise record of where the agent struggles, and every prompt, model or tool change gets checked against it before it ships.
Expand one process at a time
When the first process is stable, reviewers rarely change the agent’s output and the team trusts the audit trail, pick the next process with the same three filters. Reuse what you built. The tool layer, the logging, the approval queue and the eval harness are most of the work, and they carry over.
Orchestration deserves as much attention as the model. Our work on a telecom orchestration platform was about workflow automation across voice, data and messaging, and the same lesson applies to agents: dependable plumbing between systems is what lets a smart step deliver anything at all.
If you are choosing your first process now, the shortlist and the map are the parts worth getting right, and they are cheap to do well. Our SI applications team helps clients pick, map and build that first agent, and we are glad to look over your shortlist with you.