Home / Product development / AI agent workflow automation
Your team carries cases between an inbox, a document store and two or three business systems, and the scripts you have cover only the tidy ones. We build agents that take those steps: a trigger starts each run, the agent gathers the context and calls only the actions it is allowed, and a person approves any step that moves money or changes a customer record. Coding agents help write the connectors and tests; senior engineers decide what the agent may touch.
A ticket waits while someone looks up the order, checks the contract and updates billing by hand. A script handles the tidy cases and fails quietly on a scanned form. A chatbot can explain the steps but cannot take them. An agent workflow takes the steps itself, stops at the ones a person must approve, and records every call it made.
The people who handle a case today, the owner of each system and finance often describe different processes. These six conversations settle which one the agent follows and what it may change.
A sample of real cases traced end to end with the people who handled them, so the map shows the exceptions and workarounds as well as the usual path.
What starts a run, from an inbound email to a schedule, and the end state checked in every system, so a run cannot report success while one update is missing.
For every system, the exact calls the agent may make, under a service account of its own that can do nothing else and can be switched off in one place.
Which steps wait for a person, such as a refund above a set amount or a change to a customer’s bank details, who approves them, and who covers when they are away.
What the agent may read, what it stores between runs and for how long, and what is deleted once a case closes, agreed with whoever owns data protection in your company.
The most a single run may spend on model calls, the monthly figure finance will see, and what the agent does near the ceiling: finish on a smaller model, or stop and hand over.
Two kinds of agent meet here: the coding agents our engineers write with, and the agent you end up running. Coding agents take the volume: connectors, retries, test cases and the runbook. Senior engineers decide which actions the live agent may call and where it stops, because a wrong call refunds the wrong order.
AI-native product developmentCoding agents draft each connector and the tests around its error replies and rate limits, so the workflow is not confined to the two systems with the easiest APIs.
Agents help turn last month’s cases into a test set, odd ones included: a scanned form, a reply in German, two tickets about one order. Each runs before any action goes live.
Which steps get a model and which stay as plain code is a senior engineer’s call, made on real cases, because a model on a fixed step adds cost and a new way to fail.
How many steps, retries and tool calls one run may make is set and tested by a senior engineer, so a confused run stops and hands over instead of looping.
Senior engineers review each action that changes a record, so it can run twice without doubling and be reversed if a later step fails. A half-finished run is worse than none.
Six situations, from a process done by hand to a second workflow on shared connectors.
Someone copies details from emails into two systems and chases the replies. We automate the usual path first, and unusual cases keep going to the person who handles them today, with everything the agent gathered attached.
They fail where the input varies: free text, scanned documents, replies in other languages. Those steps move to an agent and the fixed steps stay as code, because code is cheaper to run and easier to check.
A bot that clicks through screens stops when a button moves. Where a system has an API, the agent calls it instead, and clicking through screens stays only for the systems that offer nothing else.
A case sits in one team’s queue until someone notices it belongs to another. The agent gathers the order, the contract and the history, routes the case with all of it attached, and chases it when nobody picks it up.
The demo drafts sensible actions, but nobody will let it act. We keep the prompts and tool calls that hold up, add the stop rules, approvals and run log a pilot leaves out, and run it in shadow first.
The connectors, service accounts and run log from the first workflow are reused, so a second process is mostly its own steps and rules. Which process comes next is picked from what the first one’s runs show.
Five stages, ordered so the agent drafts every action on live cases, and people check each draft, before it takes any.
The process owner and the people who do the work walk last month’s cases through a map of every step, the system it touches and the action the agent may take.
Process maps, case samplesConnectors come first, each tested against a sandbox copy of its system. Agent steps are added once every connector passes, and the test set grows with each sprint.
Python or Node.js, LLM APIsThe agent drafts each action on live cases but executes none. The people who handle those cases compare every draft with what they did, and each mismatch goes on the fix list.
Draft-versus-actual reportsActions go live one step at a time, the least risky first, with monitoring, alerts and a security review in place before the first one runs on a live case.
Monitoring, security reviewStopped runs, approval decisions and cost per run decide what changes next. New steps and systems are added one at a time, in the order the process owner ranks them.
Run reports, cost per runSix parts, built around the run record, because every trigger, action, approval and stop attaches to it.
A new ticket, an email, a file or a schedule
Order, contract and history pulled from each system
Only from the actions this workflow may call
Limits and required fields checked before any call
By a named person, shown what the agent found
Each system checked, then the run record closed
Stopped runs show which lookups the context step still lacks
Triggers from webhooks, inboxes, file storage, schedules and queues, with duplicate events ignored, so one case never starts two runs or issues two refunds.
Each run’s state is saved after every step, so a timeout, a restart or a reply that takes two days picks up at that step instead of repeating the ones already done.
One connector per system, a service account per workflow, and an allowlist of the actions each step may call, with every argument checked before the call is made.
The request reaches the approver in email or chat, with the agent’s evidence and the exact change it will make, and the decision and who made it stay on the run.
When a step cannot finish, the run stops there and goes to a named person with what the agent gathered, what it tried and where it stopped.
Each step’s input, tool call, output, approver and timing are stored per run, searchable by case, and kept for as long as your audits require.
Neither project runs an agent that acts in other systems. Both put AI steps inside a multi-step process: analysing recorded sales calls, and turning lease documents into structured data.
AI sales automationAI Sales Intelligence Platform
Each call is converted from speech to text in 30+ languages, split by speaker, checked against the sales script and searched for key points, with results in dashboards. The system works alongside the CRM and sales tools already in use.
Read the AI Sales Intelligence Platform case studyIt depends on how many systems the agent acts in and how varied the cases are, since each system needs a connector and each kind of case its own tests. Start from what the process costs now: the hours your team spends carrying cases between systems. After discovery you get a written figure for the build and an estimate of the cost per run, so you can set both against those hours.
Often rule-based automation will do. If every case follows the same path, a script or a no-code flow is cheaper to run and easier to check, and we would rather say so than build an agent. An agent pays off where the input varies, such as free-text emails, scanned forms and replies in several languages, and the next step depends on what the case contains.
Against what your team actually did. In the shadow run the agent drafts an action for each live case without executing it, and every draft is compared with the action the person took. An action goes live only once its drafts match, and the same cases are rerun after every change to a prompt, a connector or the model.
The ones that are expensive to reverse. Refunds above a set amount, changes to bank details or contract terms, and the first message to a customer are typical, and the process owner sets the final list in discovery. The approver sees the evidence and the exact change, and the run waits until they answer, or passes to a colleague if nobody does.
By using a model only where a step needs one. Claude, GPT and Gemini are tried on last month’s cases step by step, the cheapest one that handles them stays, and plain code replaces a model wherever a step is fixed. Each run has a spending ceiling agreed in discovery, and cost per run is reported every month against it.
One process, from its trigger to its end state, and every system it touches. It handles the usual path and the most common exceptions; rarer cases go to a person with the context attached. A second process, more languages and customer-facing steps wait until the first has worked live cases, because its stopped runs show what to build next.
Anything with an API or a database we can reach: CRM, ERP, helpdesk, document storage, email and your internal services. Older systems without an API get a small service beside them that exposes only the few actions the agent needs. Driving a user interface is the last resort, because a moved button breaks it.
Yours. Runs happen under your cloud and model-provider accounts, the connectors, prompts and test cases live in your repositories, and the run history is stored where you decide. IP assignment is part of the contract, so the workflow stays with you if we part ways, and your team can switch off the agent’s service accounts in one place.
Your team handles stopped runs as they arrive, from the queue the agent hands them to. The named engineer who signed off the launch stays on the workflow: fixing runs that point to a bug, updating a connector when the system behind it changes, and checking cost per run against its ceiling. New steps are scoped and quoted before work starts.
Tools for agents your team already runs, an admin screen for the cases people keep, and an engineer to run the workflows in production.
Send the steps of one process and the systems each step touches, or an anonymised case that took too long to close.
In the first call we look at where cases wait and which steps vary. If a simpler automation or a search tool would do the job, we will say so.
We sign an NDA before discussing your data in detail. We reply within 24 hours.
