AI agent development
An agent is not a smarter chatbot. It is a piece of software that is handed a goal, given a set of tools, and trusted — within limits you set — to get to the end of a task. The difficulty is never the writing. It is the tools, the limits, and knowing when to stop.
What an agent looks like in practice
A typical first build is unglamorous and valuable. An enquiry arrives at 02:40 in Portuguese. The agent reads it, works out which product line it concerns, checks your stock system, answers in Portuguese with a price band you have approved, asks the two qualifying questions your sales team always asks, writes the result into your CRM, and flags the thread for a human if the buyer asks anything about contracts or discounts.
By 09:00 your team opens a queue of qualified conversations instead of a queue of unread email. Nothing about that requires a breakthrough model. It requires someone to connect five systems carefully and to decide, in advance, exactly where the machine must stop and ask.
The parts that decide whether it works
Tools, not prompts
A model with no access to your systems can only produce plausible text. The value comes from the integrations: CRM, inbox, calendar, stock, billing, internal documentation. Most of a build is this plumbing, and it is where projects quietly fail when they are handed to someone who only writes prompts.
Guardrails
Every agent we ship has an explicit list of things it may never do without a person: quote outside an approved range, promise a delivery date, give clinical or legal advice, contact anyone who has opted out. These are enforced in code, not requested politely in a prompt.
Evaluation
Before an agent talks to a customer, it is run against a test set built from your own historical cases, including the awkward ones. When we change a prompt or swap a model, the same set runs again. Without this you are not improving a system, you are redecorating it and hoping.
Logs you can read
Every decision, tool call and message is recorded in plain language. When someone asks why the agent said that, the answer takes a minute to find. In a regulated industry this is not a nice-to-have; it is the condition of being allowed to run at all.
Which model runs it
We are deliberately model-agnostic, for a commercial reason rather than a philosophical one. High-volume, repetitive work — classifying, extracting, translating, summarising — runs perfectly well on open models that we host ourselves, which takes per-token cost to zero and keeps your data on hardware you can point at. Work that needs genuine reasoning over a messy situation runs on a frontier API, where you pay per call and it is worth it.
Most real systems use both, with the cheap model doing ninety per cent of the volume and escalating the rest. We will show you the split and what it costs per month before you commit.
Timeline and what you get
- Week 1 — workflow mapped, success criteria agreed in writing, evaluation set built from your own history.
- Weeks 2–4 — the agent, the integrations, the guardrails, an internal review interface.
- Weeks 4–6 — shadow mode: the agent drafts, a human approves everything, we measure the gap.
- After that — autonomy is widened one step at a time, against the numbers rather than the enthusiasm.
You receive the code, the prompts, the evaluation set and the documentation. If you later want to run it in-house or hand it to another team, nothing about that is difficult, and that is intentional.
When we will tell you not to buy this. If the task has fewer than a handful of cases a day, if the rules are already deterministic, or if nobody internally will own it, an agent is the expensive way to solve it. We would rather say so early.
Have a workflow in mind?
Describe it in two paragraphs. We will tell you within a day whether it is a good candidate, and roughly what it would take.