AI agent development

  • One task, defined narrowly enough to test
  • Permission to act, with an audit trail
  • A human in the loop where it matters

An agent finishes a task; a chatbot answers a question

An AI agent is software that is given a goal, the means to act and permission to use it - triage the ticket, chase the unpaid invoice, qualify the lead, reconcile the two records. The agents that work in production are narrow, observable and reversible. The ones that fail were given a vague goal and broad permissions.

Tell us the task to automate

What an agent is good for

The pattern is the same every time: a task somebody does repeatedly, with a clear definition of done.

Jobs that suit an agent

Triage and routing

Read the incoming ticket or enquiry, work out what it is about, attach what is already known about the sender, route it to the right queue and draft the reply. A person approves rather than starts from nothing.

Chasing and following up

The unpaid invoice, the abandoned signup, the quote that went quiet. Dull, time-boxed, rule-bounded work that gets dropped when a team is busy - which is exactly when it matters.

Qualifying before a human

Ask the three questions that decide whether an enquiry is worth a call, and hand over a lead with the answers filled in. The agent does not close anything; it stops your people spending their day on enquiries that were never going to buy.

Moving data between systems

Read from one, transform, write to the other, flag what does not match. Traditionally a scripting job, and still partly is - the AI earns its place on the unstructured parts a script cannot parse.

How we keep an agent from going wrong

Four constraints, applied from the start rather than after an incident.

The guardrails that matter

Narrow permissions

An agent gets the minimum access the task needs, scoped to the records it must touch. An agent with your full admin credentials is a liability regardless of how well it is prompted.

Reversible actions

Where it can, it drafts rather than sends, proposes rather than commits, and writes to a queue a human releases. Irreversible actions get an approval step, and we will argue for that even when it is slower.

A full audit trail

Every action logged with what it saw, what it decided and why. Without this you cannot debug it, cannot explain it to a customer who complains, and cannot prove what happened.

A defined stop

A loop limit, a cost ceiling and a condition that means "give this to a person". Agents that retry forever are how a small bug becomes a large invoice from your model provider.

AI agents: common questions

A chatbot answers; an agent acts. A chatbot tells a customer your refund policy. An agent reads the order, checks it against the policy, issues the refund in your billing system and logs what it did. The second needs permissions, an audit trail and a stop condition, which is why it is a larger piece of work.

That is usually the point. If your system has an API, an agent can read and write through it. If it does not, the options are a database-level integration or browser automation, both of which are more fragile and we will say which you are getting.

Four things, designed in from the start: the narrowest permissions the task allows, reversible actions wherever possible with approval steps where not, a complete audit log, and hard limits on loops and spend. An agent without a stop condition is the most common way these projects produce a surprise bill.

In practice they remove the part of a job nobody wanted - the chasing, the copying between systems, the first-pass triage - and leave the part that needs judgement. The honest framing is fewer hours on routine work, not fewer people, and any vendor promising headcount savings is selling you a number they cannot support.

It runs against a copy with real-shaped data and no ability to write anywhere that matters, and every decision it makes is reviewed against what a person would have done. It gets write access to production only after it has been boring for a while.

A server with root access and a persistent process, because an agent is long-running rather than request-and-response. Shared hosting cannot do it. We run that infrastructure, so the thing and the place it lives can come from one supplier.

Related work

Agents rarely arrive alone - they usually need retrieval behind them and somewhere to run.