Map each process step by step, give the steps to agents and keep the decisions with people. The agents work with scoped tools and permissions, and a person approves every decision that matters and anything that cannot be undone. Before a prompt or model change goes live, it runs against an evaluation set built from your own past cases. Cost per run is tracked from the first day, so the saving is measured rather than estimated. That is the method behind one of our cases: a client's business processes, rebuilt around AI agents, now run three times faster and cost 40% less.
Here is each part of it, in the order we do it.
1. Map the process as it runs today
Write the process down step by step, the way it actually runs rather than the way the procedure document describes it. For every step, note what comes in, what goes out, who does it and how long it takes. That map is the baseline. Without it, "faster" and "cheaper" are opinions.
2. Separate the steps from the decisions
Most of a process is steps: collecting documents, extracting fields, checking them against a rule, drafting a reply, routing a case to the right queue. A few points are decisions: approving, rejecting, paying, committing the company to something. An agent can do the steps. A person makes the decisions, and approves anything that cannot be undone.
Where that line sits is the most important design choice in the project. The people who run the process today should draw it, because they know which mistakes are expensive.
3. Give each agent only the tools its step needs
An agent that extracts fields from invoices needs to read invoices. It doesn't need to send email or write to the ledger. Scope the tools per step and enforce the permissions in the credential behind each tool, not in the prompt. An instruction hidden in a document can change what the agent tries to do; it can't change what its token allows. The checks we run on every tool an agent can call are in how to review an MCP server.
4. Put the approvals where the consequences are
An approval only helps if the person can judge it quickly. Show the decision the agent proposes, the evidence it used and the exact action that will follow, and make approving, changing and rejecting one step each. An approval screen that hides the arguments trains people to click yes.
5. Test every change against your own past cases
Build an evaluation set from cases the process has already handled, each with the outcome a person signed off at the time. Every prompt change, model change or new tool runs against that set before it goes live, and its score is compared with the version in production.
Put the awkward cases in on purpose: incomplete documents, sources that contradict each other, text that tries to give the agent instructions. A model that scores better on a public benchmark can still do worse on your cases. The evaluation set is how you find out before your customers do.
6. Track cost per run from the first day
Count what each run costs: model usage, other paid API calls and the minutes a person spends approving or correcting the result. Compare it with the baseline from step 1, case by case. Cost per run tells you whether a cheaper model is worth switching to, whether a step should go back to a person and whether the saving is real.
What it produced
For the client in our case, the processes run three times faster and cost 40% less than they did before. The people who ran them now spend their time on the decisions instead of the steps. The client's name and the figures behind the result are available under NDA after a first call. Read the case.
An agent that reads outside documents can be steered by them, so the tools it calls deserve a security review before it goes live. What an AI agent security review covers.
This is the kind of work we do in AI engineering. If you have a process like this, start a project.
