There is a moment in every conversation about AI agents when someone says: “it is just a simple prompt and an API call, let’s do it in a week”. And indeed - a demo of an agent that reads an email and drafts a reply can be built in one afternoon. The problem is that between a demo and a solution the company trusts with real decisions - accepting a complaint, correcting an invoice, replying to a customer - lies a chasm. That chasm is filled by an engineering process. And that process is what this article is about.
We will describe, step by step, how an agentic solution built on the UiPath platform actually comes to life - from the first question “is this process even a candidate for an agent”, through design, BPMN process visualisation, AI-assisted development, grounding in company data, testing and guardrails, all the way to production oversight. We deliberately stay at the conceptual level: we show what happens at each stage and why, not which buttons to click. This is not a tutorial - it is a map of the terrain for people who will commission, oversee or account for such a project.
To keep things concrete, one running example will guide us through the entire text. It is fictional, but assembled from elements we see regularly in projects: a mid-sized manufacturing company handles B2B customer complaints. Claims arrive by email, attachments include photos and discrepancy reports, order and delivery data sits in the ERP system, the complaints policy lives in documents, and the decision to accept a complaint requires interpreting the contract. Today two specialists do this work, the queue is growing and so is the response time. The idea: let an AI agent prepare complaint decisions. Let’s see what it really takes to deliver that idea safely to production.
Before the first line of code: a process, not a prompt
First, one distinction that puts everything else in order. Classic automation (RPA) executes steps deterministically: same input, same result, every time. An AI agent works differently - it receives a goal, context and a set of tools, and chooses its own path to the result. That is its strength (it copes with variability that cannot be captured in rules) and, at the same time, its risk (it may reach a conclusion no one anticipated).
From this distinction follows the most important principle of this article: an agentic solution is designed like a business process with control points, not like a script. The question is not “what should the agent be able to do”, but “which decisions in the process do we hand over to the agent, which stay with a human, and how do we document that”. The eight steps we are about to walk through are, in essence, eight gates at which those questions get answered. We have written on this blog before that the automation code itself is written quickly these days - it is the road to production that takes time. This article shows what that road is filled with.
Step 1. Qualification: is this process even a candidate for an agent
The most expensive mistake in agentic projects is made before they start - by choosing the wrong process. That is why the first step is not designing the agent, but an honest qualification of the candidate. In practice, we assess four things.
The nature of the decision. If the decision can be described by a complete set of rules (“invoice matches the order and the limit - post it”), an agent is overkill - a classic robot will do it cheaper, faster and in a fully predictable way. An agent makes sense where the decision requires interpretation: ambiguous input data, natural language, the need to combine several sources, judging “similar, but not identical”. Complaint handling is a textbook example - every claim is slightly different, and the decision depends on the contract wording, the customer’s history and the delivery circumstances.
The cost of an error. There are no error-free agents, only processes with different tolerance for mistakes. If a single error means damage that is hard to reverse - paying out a large amount, a message to a regulator, an HR decision - the process can only enter the agentic programme with a hard human approval point, or not enter it at all. That is not a limitation of the technology; it is common sense written into the architecture.
Availability of data and knowledge. An agent makes decisions based on what it has access to. If the complaints policy exists mainly in the heads of two specialists, then before building an agent we face work that is worth doing anyway: writing the rules down. In our example the company has a documented complaints policy and framework agreements with customers - a sufficient starting point.
Volume and repeatability. An agent that handles five cases a month will rarely pay for itself. A complaints queue growing faster than the team - that is a business justification.
The qualification result in our example: the process is a candidate for an agentic solution, but a hybrid one. Collecting data from the ERP - a robot (deterministic). Interpreting the claim and preparing a proposed decision - an agent. Approving decisions above an agreed value threshold - a human. Already at this stage the first governance artefact is produced: a qualification document with a risk assessment, which in a few months will be the answer to the auditor’s question “why did you decide this process could be entrusted to AI”.
It is also worth naming the most common anti-pattern we see at this stage: a process chosen because it is fashionable, not because it passed qualification. An agent answering all of the company’s email, an agent for “general document analysis”, a board assistant agent with no defined scope - these are projects that end with an impressive demo and a quiet funeral, because they have no measurable outcome, no process owner and no success criterion. The reverse anti-pattern is just as costly: forcing an agent into a place where a well-written robot or a form with validation would have sufficed for years. The test we propose to clients is prosaic: if an experienced employee can describe the decision in the process with a complete “if-then” instruction, the process does not need an agent. If, instead of an instruction, they tell case stories and say “it depends” - there is something to talk about.
Step 2. Agent design: role, tools, context, boundaries
Only now do we design the agent itself. A good agent design resembles a well-written job description for a new employee and consists of four elements.
Role. An unambiguous description of who the agent is and what it is responsible for: “you are a complaints assistant; you analyse B2B customer claims and prepare a proposed decision consistent with the company’s complaints policy; you do not communicate with the customer directly; you do not make final decisions above the threshold”. The more precisely the role is described, the less room there is for “creativity” in the bad sense of the word.
Tools. An agent acts through tools we explicitly make available to it - and only through them. In the UiPath ecosystem an agent’s tool can be a robot workflow (for example “fetch the order history from the ERP”), an API call through Integration Service, or a query to a knowledge index. This is a fundamental difference from a “chatbot with access to everything”: the tool list is closed, and every item on it is a conscious design decision. The complaints agent gets four tools: reading order and delivery data, reading the customer’s framework agreement, searching the complaints policy, and saving the proposed decision. It does not get a “send an email to the customer” tool - that happens later in the process, after approval.
Context. What the agent knows about the company and the process: the complaints policy, definitions of defect categories, value thresholds, the expected justification format. We will expand on this element in step 5, because the way context is provided determines answer quality more than the choice of model.
Boundaries of autonomy. Written down explicitly: what the agent does on its own, what it escalates, when it must stop. In our example: proposed decisions below the value threshold proceed after a light review, above the threshold - mandatory approval, and claims where the agent cannot establish the facts go to a human with a description of what was missing. An agent that can say “I don’t know” is more valuable than an agent that always has an answer.
At this stage an architectural decision is also made: a low-code or a coded agent. UiPath Agent Builder lets you assemble an agent from a role, tools and context without programming - and for most process agents, such as our complaints agent, that is the right choice: faster, clearer, easier to maintain. Coded Agents (agents written in code, on frameworks such as LangGraph or LlamaIndex, deployed onto the same platform) come into play when the logic requires a non-standard reasoning flow, complex data structures or integrations that are not in the catalogue. A practical rule: start with low-code, drop down to code when the requirements genuinely demand it - not the other way round.
One more decision belongs to the design, and it is too often made in passing: the choice of the language model. Our recommendation is contrarian - treat the model as a replaceable component, not as the foundation. The model market changes every quarter, and a solution that has fused with a single provider will have a problem within a year: with costs, with quality, or with company policy towards that provider. A platform layer mediating access to models (in UiPath this role is played by the trust layer, which we will return to in step 7) allows you to swap the model under the agent without rebuilding the whole solution - provided the design treated the model as a configurable dependency from the start, and the agent definition, its tools and its tests live independently of it. The selection criteria today are classic: quality on your own test cases (not on internet benchmarks), cost per case, and requirements regarding where data is processed. The order is not accidental.
Step 3. Visualisation and orchestration: you can see the process before it exists
This is the heart of the whole approach and the reason the word “visualisation” appears in this article. The agent designed in step 2 does not hang in a vacuum - it is one participant in a business process. And that process needs to be drawn before anything gets built.
In UiPath this layer is handled by Maestro - a process orchestration tool based on BPMN, the business process diagram standard analysts have known for years. On a single diagram we model the entire complaints flow: claim intake, classification, data collection, the agent’s analysis, the decision gate, human approval, decision execution, the reply to the customer. Each step is assigned to one of three types of performer: a robot (deterministic steps), an agent (steps requiring interpretation), a human (decisions and exceptions).
Why is this so important? For three reasons we see in projects again and again.
First: a common language. A BPMN diagram is readable by the chief operating officer and the developer alike. When we draw the complaints process at a design workshop, the discussion “can the agent accept complaints up to threshold X on its own” takes place over a concrete gate on the diagram - not over an abstraction. Governance decisions stop being an appendix to the project and become elements of the drawing. The human approval gate (human-in-the-loop, HITL) is a concrete, visible element on the diagram - not a footnote in the documentation that can be forgotten.
Second: boundaries of responsibility. When the process is drawn, you can see exactly how far the agent’s autonomy reaches. An auditor, an information security officer or a new team member does not have to read code to understand who makes which decision. In a world where regulations increasingly ask about human oversight of AI systems, such a diagram is a compliance document in its own right.
Third: a long-running process under control. A complaint does not finish in a minute - it waits for data, waits for a human, sometimes waits for the customer’s reply. Maestro carries each process instance through days or weeks, remembers its state and shows live where every case is stuck. This is also the answer to the question that always comes up with agents: “what if the agent hangs or replies with nonsense?”. The answer is: the process will notice, because the agent is one step in an orchestra, not a lone soloist - the step has time limits, error handling and an escalation path like any other.
On the diagram we also model what constitutes most of the design work in real processes: exceptions. What happens when a customer sends an addendum to a case that is already awaiting approval? When a complaint turns out to be a duplicate? When the customer withdraws the claim during analysis? In the “agent as chatbot” approach these scenarios belong to no one and surface in production. In the process approach each of them is an explicit path on the diagram, designed and tested before the first customer sends anything. This is also where the decision is made on how difficult cases are carried to completion: a disputed complaint does not vanish from the system at the moment of escalation to a human - it remains a case in the same process, with the full history of what the agent established, so the human does not start from zero.
We wrote at greater length about how UiPath evolved from task automation into a platform orchestrating agents, robots and people in the article about UiPath no longer being RPA. Here one summary sentence suffices: the process diagram is a contract between business, IT and governance - and everything we build in the following steps must be accountable to that contract.
Step 4. AI-assisted development: an agent helps build an agent
A paradox of modern automation projects: AI tools also accelerate the building of AI solutions themselves. In practice, the development team works with coding assistants - such as Claude Code - extended with UiPath skills and integrations that teach the assistant the platform’s project structure, naming conventions and good practices. The assistant can prepare a project skeleton, propose an agent definition, generate a tool workflow, check naming consistency - while the developer designs, verifies and approves.
In our complaints example this looks concrete. The agent definition (role, tools, output format) from step 2 is translated by the team into a project in Agent Builder, while the “fetch order data from the ERP” workflow - the robot’s deterministic tool - is created with the support of a coding assistant that knows the structure of UiPath projects and suggests an implementation consistent with the standards adopted in the company. Things that used to take days (skeletons, integrations, routine code) take hours.
And here is an important caveat, without which this step would be a marketing fairy tale: the acceleration applies to writing, not to responsibility. Code generated by an assistant goes through human review exactly like code written by hand - and in agentic projects that review is even more important, because the errors tend to be subtler. A team that treats a coding assistant like a trusted senior who does not need checking repeats exactly the mistake it wants to protect the business from when deploying agents: it hands over decisions without oversight. The rule is simple and symmetrical: AI proposes, a human approves - at the code level just as at the level of the complaint decision.
It is also worth understanding where the quality of such an assistant’s work comes from, because it is not magic - it is context engineering. A coding assistant is exactly as good as the knowledge we feed it - sounds familiar? It is the same grounding principle we are about to apply to the business agent. Skills and project context files teach the assistant the team’s naming conventions, the repository structure, the review standards; without them it generates code that is correct but alien, which the team will rewrite anyway. That is why mature teams invest in this layer as consciously as in the code itself - and the assistant repays in the other direction too, as a tireless reviewer: architecture review, catching deviations from conventions, preliminary workflow verification before human review. We wrote about what working with coding agents in the UiPath ecosystem looks like on the occasion of the platform opening up to Claude Code and Codex.
There is one more benefit of this approach, rarely mentioned: documentation stops being a backlog item. A coding assistant generates descriptions, comments and design documents in parallel with the code - and in a project that will soon face an AI governance audit, complete documentation is not a luxury but a requirement.
Step 5. Grounding: the agent must know, not guess
A language model without access to company knowledge will do what it does best: give a fluent, convincing and potentially wrong answer. That is why no serious process agent works “from memory” - it works on knowledge we explicitly connect to it. This step is called grounding, and it determines the quality of the solution more than any other.
In the UiPath platform this is the job of Context Grounding: a mechanism that indexes company documents and serves the agent the fragments relevant to the specific case. In our example we index the complaints policy, the framework agreements with customers and the defect category catalogue. When the agent analyses a customer claim, it does not ask the model “what is usually done with a complaint about a scratched pallet” - it is handed the right paragraph of the policy and the right clause of this particular customer’s contract, and on that basis it builds a proposed decision with a justification citing the source.
The second leg of grounding is transactional data: facts about the order, the delivery, the invoice, the customer’s history. The agent fetches these through the tools from step 2 - a robot workflow reaching into the ERP, Integration Service connectors to the remaining systems. The architectural principle we enforce: the agent receives data through controlled tools, never by “pasting everything into the prompt”. This matters for three reasons: security (data access is subject to the same permissions as always), cost (we do not pay for processing thousands of unnecessary tokens) and quality (the model works on selected facts instead of looking for a needle in a haystack).
Grounding also has an organisational dimension worth saying out loud: if the complaints policy is outdated, contradictory or written in a way no human understands - the agent will not understand it either, except that, unlike a human, it will not come to its manager about it. Agentic projects mercilessly expose the quality of process documentation. The good news: putting that knowledge in order stays with the company forever, regardless of the fate of the agent itself.
There is also the question of maintenance: knowledge changes, and the agent will not notice on its own. A new version of the complaints policy, an annex to a framework agreement, a change of thresholds - each of these changes must have a path into the knowledge index, ideally as part of the existing document management process, not the goodwill of someone who will “swap the file when they get a chance”. In projects we settle this explicitly: who owns each knowledge source, how often it is reviewed and what the index update looks like after a change. It sounds bureaucratic, but the alternative is worse: an agent that applies a policy two versions old with full conviction, justifying decisions with paragraphs that are no longer in force.
Step 6. Testing: how to verify something that answers slightly differently every time
Testing classic automation is binary: for input X the process must return Y; the result either matches or it does not. With an agent that does not work - the same complaint claim can be justified by the agent in different words today than tomorrow, and both justifications may be correct. Testing agentic solutions therefore requires a different approach, and this is the step most underestimated in project schedules.
The basic tool is evaluations (evals): a set of test cases with expected outcomes prepared in advance, run through the agent repeatedly and assessed not by the exact wording of the answer but by its properties. Is the decision consistent with the policy? Does the justification cite the right contract clause? Do cases above the threshold always - really always - go to escalation? The test set must contain not only typical cases but above all edge cases: a claim without an order number, a complaint from a customer without a framework agreement, a value exactly at the threshold, an attachment from which nothing can be concluded, and even a claim whose content attempts to manipulate the agent. On our blog we wrote about agentic testing - an approach in which tests explore the system’s behaviour themselves instead of replaying a rigid script - in agentic projects that philosophy finds a natural application.
On top of that comes testing the whole process, not just the agent: does the orchestration in Maestro handle time limits correctly, do escalations reach the right people, does the robot recover after ERP downtime. The UiPath platform closes this loop with its testing tools (Test Cloud), which allow process scenarios to be treated as fully fledged test cases - versioned, run cyclically, reported.
Practical advice from projects: build the evaluation set together with the process experts, on real (anonymised) cases from the past, and treat it as an asset - you will need it with every change of model, prompt or complaints policy. It is your litmus test for the question “does the agent still work well after this change”.
Security tests are a separate category. An agent that reads content from external senders - and our complaints agent reads customer emails - is by definition exposed to manipulation attempts: a claim may contain content crafted to convince the model to ignore its instructions, inflate a decision or disclose information it should not disclose. This class of attack is known as prompt injection, and in agentic projects we treat it the way classic systems treat user input: as untrusted until proven otherwise. The test set must include deliberately malicious cases, and the expected result is always the same: the agent stays in its role, applies the policy and escalates, instead of executing instructions from the claim content. We devote a separate series on this blog to this class of threats - Safe Tuesday - because the topic grows together with the number of deployed agents.
Step 7. Guardrails and the AI Trust Layer: what the agent may and may not do
Everything we have done so far described what the agent should do. Guardrails describe what it must not do - and enforce it technically, not just in documentation. That distinction is the essence of this step: the project statement “the agent does not send replies to the customer” is a declaration; the absence of a sending tool in the agent’s configuration is a guarantee.
The guardrail layer in a mature agentic solution operates on several levels. At the agent level: a closed tool list, limits on the number of reasoning steps, a required structured answer format, validation of outputs before they are passed on. At the process level: HITL gates on decisions above the threshold, value limits, four-eyes rules where company policy requires them. And at the platform level - this is where the UiPath AI Trust Layer comes in: central control over which AI models agents across the organisation use, what data may reach those models (including masking of sensitive data), and full logging of every interaction with a model.
This third level tends to be underrated, yet it is what separates “we have an agent” from “we have an agentic programme under control”. When one agent runs in the company, policies can be enforced by hand. When there are twenty of them - built by different teams, at different times, on different models - without a central trust layer nobody can answer simple questions any more: which processes use which model, is personal data leaking to external APIs, who approved this configuration. We wrote about how to keep control over a growing number of agents in the article on governed autonomy - here we will underline one thing: guardrails are designed together with the agent, not after the incident.
In our complaints example the full set looks like this: the agent has no tool for communicating with the customer; proposals above the value threshold mandatorily pass through approval in Action Center; personal data of individual customers is masked before being sent to the model; every model call is logged with full context; and if the agent fails to complete an analysis three times, the case returns to a human. Boring? That is exactly the point. Good guardrails are boring - what is exciting are the incidents that, thanks to them, never happen.
Step 8. Production and oversight: go-live is the beginning, not the end
The solution moves to production through the same infrastructure UiPath provides for classic automations: Orchestrator manages deployment, permissions, schedules and queues, and the process in Maestro starts running on real cases. And here begins the stage that enthusiastic presentations about agents stay silent about: oversight.
An agent in production requires monitoring in three dimensions. Operational - is the process working: how many cases flow through, where bottlenecks form, how many go to escalation, how long a human waits for data and vice versa. This is shown by the Maestro and Orchestrator process dashboards. Qualitative - does the agent still decide well: what share of its proposals a human approves unchanged, what share gets corrected, what share rejected. A rising correction rate is the earliest signal of drift - the data changed, the nature of the claims changed, the model changed. This indicator is worth measuring from day one, because its trend says more than any single measurement. Cost - how much handling a case costs: model calls have their price, and a process that cost pennies in the pilot can surprise you at full volume. Cost limits and alerts are part of the configuration, not an option.
Then there is something we consider mandatory from the audit perspective: a complete audit trail. For every complaint case it must be possible to reconstruct: what the agent received as input, which knowledge sources it used, what it proposed and with what justification, who approved it and what they changed. Without this, every conversation with an auditor, a regulator or an unhappy customer starts from helplessness. With it - from facts.
And the final element, which few people think about at the start: a rollback plan. What happens when the agent has to be switched off - a model provider outage, a security incident, a regulatory change? The answer must exist before go-live: the process in Maestro switches the agentic steps to a manual path, the team knows it is taking over the queue, nobody improvises. An agentic solution that cannot be safely stopped is not ready for production - regardless of how well it works.
At the end of this step - change management. An agentic solution has more moving parts than classic automation: the model can change, the prompt defining the role, the tool set, the knowledge index, the BPMN process itself. Each of these changes can alter the agent’s behaviour, and each should follow the same path: change in the test environment, a full evaluation run, comparison of results with the previous version, a conscious deployment decision, an entry in the change register. Teams familiar with change management discipline from ERP systems will feel at home here - and rightly so, because an agent making financial decisions deserves at least the same rigour as a transport of changes to the accounting system.
Where else the same process works
The complaints example guided us through the whole text, but the eight steps are universal. Three typical applications where the same skeleton works unchanged - only the content of the individual steps changes.
Service desk ticket triage. IT tickets arrive in natural language, often incomplete and miscategorised. The agent reads the ticket, asks for missing information, classifies it, checks the knowledge base for known solutions and either proposes an answer or routes the case to the right support line with a complete set of findings. The robot in this process collects diagnostic data from systems; a human takes over high-priority cases and anything touching critical systems. Grounding: the knowledge base, the service catalogue, the ticket history.
Document verification in supplier onboarding. A new supplier sends a set of documents: registration, financial, certificates. The agent compares their content against the requirements of the procurement policy, catches gaps and discrepancies, prepares a recommendation. The decision to admit the supplier - always with a human, because it is a decision about risk, not about formal compliance. The robot pulls data from public registers, the agent interprets, the procurement committee decides.
Compliance reporting support. Organisations covered by NIS2 or DORA regularly collect compliance evidence scattered across systems: configurations, logs, incident registers, training statuses. The agent assembles the material, compares it against the list of requirements, points out gaps and prepares a draft report - and the security officer works on a ready, documented basis instead of manually gathered fragments. We wrote about such a pattern using the example of a compliance agent under human oversight.
The common denominator of all three: nowhere does the agent replace the decision-maker. It replaces the work the decision-maker had to do in order to be able to decide.
How long it takes and who is needed
Two questions that come up at the end of every conversation about this process. On time: the honest answer is “it depends on the process and on data maturity”, but the mechanics are predictable - qualification and design are weeks of workshops, not months; development with AI tools is the fastest stage today; the most time is consumed by grounding (if the knowledge needs putting in order) and testing with process experts. When planning a first project, assume that the “before code” and “after code” stages will together take longer than the building itself - and that this is a healthy proportion, not inefficiency.
On the team: the minimum is a process owner on the business side (without them, qualification and testing hang in a vacuum), a solution architect, an automation developer and - from the first workshop, not from the audit - a person responsible for risk and compliance. In smaller organisations some roles combine in one person or are supplemented by an external partner; what matters is that none of the four perspectives disappears from the project, because each of the eight steps needs a different one.
The closing bracket: AI governance is not a chapter at the end, it is the skeleton
Now look at the eight steps from a bird’s-eye view. Qualification with a risk assessment. Design with explicit boundaries of autonomy. Visualisation on which human oversight is an element of the diagram. Development with human review. Grounding with controlled data access. Testing with edge-case evaluations. Guardrails enforced technically. Production with an audit trail and a rollback plan. This is not an agent-building process with governance glued on. This is an AI governance process whose by-product is a working agent.
That distinction has a regulatory dimension today, not just a hygienic one. DORA - binding for financial institutions since January 2025 - requires control over ICT risk also when decisions are supported by AI. The NIS2 directive extends cybersecurity risk management requirements to further sectors. The AI Act introduces obligations for AI systems in stages over the coming years - among them requirements for human oversight, transparency and documentation, which are exactly the artefacts the eight steps produce along the way. An organisation that builds agents according to the process described here will not be “adapting to regulations” - it already has what the regulations ask about: a documented risk assessment, defined human oversight, an audit trail for every decision.
For boards and risk owners, this process yields a simple checklist of control questions. Does a qualification document with a risk assessment exist for every agent in the organisation? Are the boundaries of its autonomy described and technically enforced, not merely declared? Is there a process diagram showing where a human decides? Can you reconstruct the basis on which the agent made a specific decision three months ago? Do you know how much this agent costs per month and who can switch it off? If the answer to any of these questions is “we don’t know” - it does not mean the agent must be switched off. It means one of the eight steps is missing and worth filling in, before someone from outside asks about it.
At SNOK this is exactly how we run agentic projects - from process qualification, through design workshops over the BPMN diagram, development on the UiPath platform (we are a Platinum partner in the Agentic Fast Track programme), to testing, guardrails and handover to oversight. AI governance is not a separate service appended to our offering - it is the way we do these implementations, consistent with our ISO 27001 and ISO 9001 certifications. If your organisation is approaching its first agent - or already has a few and is starting to feel the lack of common rules - this is exactly the moment worth talking about.
Where to start in practice
If we were to leave you with three things to do in the coming month, they would be these. First: pick one candidate process and run it through the qualification from step 1 - the nature of the decision, the cost of an error, the availability of knowledge, the volume. Second: draw it in BPMN with an explicit split between robots, the agent and the human, and show that drawing to the people responsible for risk - their comments at this stage cost hours; in production they would cost weeks. Third: write down where the knowledge needed for decisions in this process lives today - because that will be your grounding and your bottleneck.
And if you want to walk this road with a team that has done it many times - we invite you to talk. We will gladly show you what this process looks like live, on an example tailored to your organisation.