How we build an AI agent, from bottleneck to go-live

Building a demo agent takes an afternoon. Building one that a business can rely on every day, with real customers, real data and real consequences, takes a process. This is ours. It is not the only way to do it, but each stage exists because skipping it caused problems somewhere.

#Stage 1: Map the job before the agent

We sit with the people who do the work today and write down what actually happens: the requests that come in, what they look up to answer them, the decisions they make, the actions they take, and the exceptions that need a manager. The output is a simple job sheet.

This table becomes the scope. Anything not on it, the agent hands over to a person. It also shows, before any code is written, whether an agent is even the right tool. If every row is a fixed rule, plain workflow automation will do the job more cheaply.

#Stage 2: Design the tools

Each action on the job sheet becomes a tool, a function the agent can ask to run. We spend more time here than anywhere else, because tools decide what the agent can do and how safely it can do it. Our rules:

• One tool, one job. get_order_status and cancel_order are separate, even if they hit the same API.
• Names a new employee would understand. The model picks tools by reading their names and descriptions.
• Validate everything in code. Types, ranges and ownership are checked before the action runs, never left to the prompt.
• Return small, clear results. A tool that dumps a whole database row confuses the model. Return what the next decision needs.
• Separate reading from writing. Look-up tools and tools that change data get different permissions.

#Stage 3: Write the instructions

Only now do we write the system prompt. We keep it structured, so it can be reviewed and changed without side effects:

ROLE        Who you are and who you serve.
GOAL        What a finished conversation looks like.
TOOLS       When to use each tool, and when not to.
NEVER       Things you must never do or promise.
HAND OVER   Situations that always go to a person.
STYLE       Tone, length, language (reply in the customer's language).
FORMAT      How to present prices, dates and order numbers.

Language matters more than people expect. Customers in Bangladesh often mix Bangla, English and Banglish in a single message. We write instructions and test cases for all three, so the agent replies naturally in whatever the customer used.

#Stage 4: Add the guardrails

An agent that acts in your systems needs the controls you would give a new employee, enforced in code. That means its own credentials scoped to its job, validation on every action, a human approval queue for sensitive actions such as refunds or price changes, limits on steps and spending, and a full audit log. We wrote a whole article on this: guardrails for AI agents.

#Stage 5: Test with real scenarios

Before anyone outside the team talks to the agent, we build a scenario set: real past requests (anonymised), variations with typos and mixed languages, and deliberately hard cases such as angry customers, missing information and attempts to trick the agent. Every change to prompts, tools or models is run against the full set. The details are in how we test an AI agent.

#Stage 6: Launch narrow, then widen

We never switch an agent on for everyone at once. A typical launch looks like this:

1. 01

   Shadow mode

   The agent drafts every reply; a person reviews and sends. We compare drafts with what the person would have written.

2. 02

   Narrow live

   One channel, or certain hours, or one type of request, answered by the agent directly, with staff watching the log.

3. 03

   Widen

   More channels, request types and write actions, added one at a time as each proves itself.

4. 04

   Steady state

   Regular review of flagged conversations. Every real failure becomes a new test scenario.

#What you get at the end

• The agent, connected to your channels (website, WhatsApp, email or phone) and your systems through integrations.
• An admin view of conversations, actions, approvals and logs.
• The scenario test set, so changes can be checked safely later.
• Documentation and a handover session for your team.
• A support plan agreed up front, covering monitoring and improvements.

#How long does it take?

It depends mostly on integrations: an agent that reads from one well-documented system is very different from one that writes to three older ones. We give a clear estimate after discovery rather than a number up front, and we often start with a working prototype of the core workflow so you can judge the value before committing to the full build. If you have a process in mind, our AI agent development page explains how to get started.