Service
AI agent development
Agents built for one documented process, with tools that do the work and a person who approves it.
An AI agent is a system that can use tools, take multiple steps, and act on the result, rather than answer a question and stop. We build them for a specific department and a specific process: support triage, sales research, finance reconciliation, internal knowledge retrieval, or operations. The build is mostly ordinary engineering. The judgement is in deciding which steps are rules, which need a model, and where a person has to approve before anything commits.
The problem
Why most agent projects stall
The first reason is scope. A project framed as an agent that runs the department will not ship, because the department is not one process, it is forty, and most of them are not written down anywhere.
The second is that people reach for a model where a rule would do. A model asked to do arithmetic or apply a threshold is right most of the time, which is the worst possible reliability profile: the failures look exactly like the successes and nobody notices for a quarter.
The third is missing evaluation. Without a set of cases the agent must handle correctly, there is no way to tell whether a prompt change improved it or broke it, so every change becomes a matter of opinion.
Scope
What the work covers
Agents are built per department, per process, on top of the systems you already run.
Discovery and process mapping
Writing the current process down as steps and rules, including the parts people do without thinking. This step alone frequently removes the need for the project, and we say so when it does.
Agent design
Deciding what the agent can see, what it can do, when it stops, and what it hands to a person. The scope boundary is the design, and a vague one is what produces an agent nobody trusts.
Tools and integrations
The functions the agent calls: your CRM, your ticketing system, your warehouse, your internal APIs. Most of the engineering effort lives here rather than in the prompt, and most of the reliability does too.
Skills and plugins
Packaged capabilities the agent loads for a given task, so one system serves several processes without a single prompt trying to cover all of them.
Evaluation and guardrails
A test set of real cases with known correct outcomes, run on every change. Plus explicit limits: what the agent may never do unsupervised, and what always requires a human approval step.
Deployment and monitoring
Running in your environment with logging of what it did and why, and alerting when it fails or when its refusal rate moves. An agent that fails silently is worse than none, because people stop checking the thing it replaced.
Process
How the work runs
The order matters more than any individual step.
Write the process down
If it cannot be expressed as steps and rules, it is not ready to automate. This is where we find out whether the project should exist.
Separate rules from judgement
Every step is labelled. Rules become code, because code is cheaper and correct every time. Judgement steps get a model, behind an approval gate where the outcome matters.
Build the smallest useful agent
One process, in production, doing one thing well. Department-wide agent programmes that launch all at once tend never to launch.
Build the evaluation set with it
Real cases with known outcomes, written before the tuning starts, so improvement is measurable rather than argued.
Hand it over
Documentation an engineer who was not there can maintain, and a review cadence that decides whether to keep, extend, or switch each agent off.
Deliverables
What you receive
Artefacts you keep, whether or not we keep working together.
- A written map of the current process, step by step
- A rules versus judgement classification for every step
- The agent, its tools, and its integrations, running in your environment
- An evaluation set of real cases with known correct outcomes
- Explicit guardrails naming what always needs human approval
- Monitoring, logging, and documentation another engineer can pick up
Related reading
AI agent use cases, department by department
The long-form version of the thinking behind this service.
Related services
- AI marketing automation
Automate the repeatable, keep judgement where judgement is needed, and be specific about which is which.
- Marketing analytics services
Measurement you can act on, and an honest account of what it cannot tell you.
Questions
AI agent development, answered
The questions we are actually asked, answered without hedging.
How is this different from your AI marketing automation service?
Department and depth. AI marketing automation covers marketing workflows: reporting pipelines, anomaly alerts, content drafting. This is custom agent development for any department, built against your systems, and it is a software engagement rather than a marketing one. Companies often start with the marketing one because the process is already documented.
Which departments does this actually work for?
Anywhere a documented, repetitive process involves reading unstructured language and then doing something. Support triage and drafting, sales research and CRM hygiene, finance reconciliation and exception flagging, operations scheduling, and internal knowledge retrieval are the ones we see work. Anywhere the process is undocumented, the honest first deliverable is the document.
Will an agent replace the people doing this?
No, and a proposal that leads with headcount reduction is worth distrusting. What it removes is assembly: gathering, formatting, checking, and chasing. The decisions stay with people, and people with more time make better ones.
How do you stop it doing something damaging?
By constraining what it can do rather than by asking it nicely. The agent only has the tools you granted it, anything consequential goes behind a human approval step, and the evaluation set includes the cases where it should refuse. Unsupervised authority over money or customer communications is not something we build.
What does it cost to run?
Less than most people expect, because the majority of steps end up as ordinary code rather than model calls. Model cost only becomes significant at high volume, which is one more argument for keeping models out of work that rules can do.
Do we need our data in one place first?
Not necessarily. Agents call tools, and a tool can read from wherever the data lives. A consolidation project is sometimes worth doing for its own reasons, but making it a prerequisite is how agent projects get delayed by a year.
Start with an audit
Send us what you are running. We will tell you what we would look at first in AI agents, and whether it is the right place to start at all.