AI Agent Development
Agents that run on their own, survive a bad day, and can be audited afterwards.
In plain English
An AI agent is software that does a whole job for you, start to finish, without anyone clicking through it. You describe the job and the rules it has to follow, it does the work, and it tells you what it did.
The technical version: An AI agent is a language model given tools and a goal, so it can take steps rather than only answer. It is worth building when a task is repetitive, needs judgement, and touches more than one system. When the work is a fixed sequence with no judgement in it, ordinary automation is cheaper, faster and far easier to debug, and I will tell you when that is the case before you spend anything.
What you could actually do with this
Every enquiry that arrives overnight is read, sorted, and either answered or sent to the right person before you open your laptop.
Nobody loses a lead because it came in at 11pm on a Saturday.
The report someone rebuilds by hand every Monday morning gets built at 6am, from the same systems, with the same numbers.
You get the half day back every week, and two people stop disagreeing about which version is right.
Every invoice, application or form that comes in is checked against your rules, and only the ones that fail reach a person.
Your team stops reading the ninety percent that were fine and spends the time on the ten percent that were not.
Onboarding a new client runs itself: accounts created, documents sent, checklist filled in, and a person steps in only when something is unusual.
What took three days takes an afternoon, and it happens the same way every time rather than the way whoever is on shift remembers.
What it is worth
Take the task you would point this at. Count the hours a week your team spends on it, multiply by what an hour of their time costs you, then multiply by fifty. That is the number this is competing against, and it is almost always bigger than people expect, because the work is spread over several people and nobody has ever added up the total.
What I actually deliver
The technical detail, for whoever on your side has to check it.
- A written design before any code: what the agent decides, what it is never allowed to decide, and what happens when it is wrong
- The agent itself, with real tool use rather than a prompt pretending to be a system
- Evaluation you can run on every change, so "it seems better" becomes a number
- Guardrails, retries, timeouts and a kill switch, because an agent with no brake is a liability
- Cost controls and token budgets, so the bill cannot quietly triple in a month
- Observability: what it did, why, and what it cost, per run
How it works
- 01
Find the judgement
We locate the step a human currently makes a decision on. If there is no such step, there is no agent to build, and I say so.
- 02
Design the boundary
What the agent may do on its own, what needs a human, and what it must never touch. This is written down before anything is built, because it is the part that decides whether the thing is safe.
- 03
Build the smallest useful version
One task, end to end, in production, behind a flag. A working narrow agent teaches you more in a week than a broad prototype does in a quarter.
- 04
Add evaluation before adding scope
A test set with expected outcomes, run on every change. Without this you are guessing, and you will not notice the day a model update makes it worse.
- 05
Widen, then hand it over
More tasks, more autonomy, and documentation your team can maintain without me.
When this is the wrong call
Do not build an agent to replace a form, a cron job, or a five-step workflow with no decisions in it. You will pay model costs and accept non-determinism to do something a script did perfectly. Do not build one to sit in front of data you have not cleaned, because an agent reasoning over bad data produces confident bad answers faster. And if the work touches patient data, payments or anything a regulator reads, the compliance design comes first: retrofitting it costs more than building it in.
Where I have done this
PracticeRank.ai
An agentic pipeline that audits a client site, decides what to change, writes the content and publishes through the client CMS API. It runs monthly, per customer, with nobody starting it.
Further reading
- Should You Let AI Agents Touch Production? A CTO's Framework A CTO's decision framework for giving AI agents write access to production: blast radius, reversibility, permission scoping, sandboxing, audit logs, and kill switches.
- Securing LLM Apps: Prompt Injection, Data Leakage & Guardrails A practical deep dive on the top three LLM security risks - prompt injection, data leakage, and weak guardrails - with concrete mitigations you can ship this week.
- AI Security for Startups: A Practical Threat Model A founder-friendly AI security threat model: what changes when you ship LLM features, the real attack surface, and where to start protecting your product.
Questions
How long does a first agent take to get into production? +
A narrow agent doing one real task, behind a flag, is typically weeks rather than months. Breadth is what takes time, not the first version, which is exactly why the first version should be narrow.
Which models and frameworks do you use? +
Usually Claude or OpenAI models, chosen per task rather than per preference, and as little framework as the job allows. Heavy agent frameworks add abstraction over the part you most need to see clearly, which is what the model was actually sent and what it did with the reply.
How do you stop an agent doing something expensive or destructive? +
Scoped tools rather than broad access, hard token and spend budgets, timeouts on every external call, human approval on anything irreversible, and a kill switch that does not require a deploy. An agent should not be able to do something you would not let a new hire do unsupervised on day one.
Can you build an agent that handles PHI or passes a security review? +
Yes, and it is why teams shipping AI into regulated work call me. Plenty of people will build you an agent. Far fewer can build one that handles patient data correctly and survives an audit.