Skip to main content
Fugen Services logo

AI & Automation

Agents that do a job, inside limits you set

An agent is a model that can call your tools — look something up, create a record, send a message — and decide which to call next. That is genuinely useful for multi-step work that is too variable to script. It is also the point at which a language model stops producing text and starts taking actions in your business, which changes what "careful" has to mean.

Indicative

From £15,000

Fixed price agreed in writing before any build starts.

Get a quote+44 7488 265083

The problem this solves

The demos are impressive and the production failures are boring: an agent that loops, one that confidently uses the wrong tool, one that has database write access because that was easiest during development. Every one of those is a permissions and design problem, not a model problem.

What you get

Tools with narrow, explicit scope

Each tool does one thing, validates its inputs, and has the minimum access needed. No general "run SQL" tool — that is how an agent ends up deleting something.

Approval gates on irreversible actions

Anything that spends money, contacts a customer or deletes data stops for a human. The agent proposes; a person confirms. This is the single most important design decision.

Loop and cost limits

Hard caps on steps, wall-clock time and token spend per task, enforced outside the model. An agent cannot be trusted to decide it has done enough.

A full audit trail

Every step recorded: what it was asked, what it decided, which tool it called with which arguments, what came back. Without this an agent is unauditable, which for most regulated work makes it unusable.

Evaluation before deployment

A test set of real tasks with known good outcomes, run on every prompt or model change. Without it you cannot tell whether a change improved things or quietly broke them.

Graceful failure

When the agent cannot complete a task it says so and hands over with its working, rather than inventing a plausible completion. Escalation is a feature, not a defect.

How we work

  1. Define the job precisely

    One task, with a clear definition of done. Agents scoped as "help with operations" fail; agents scoped as "reconcile these two reports and flag differences" work.

  2. Design the tool surface

    The minimum set of tools, each with the minimum permission. Reviewed before building.

  3. Build the evaluation set

    Real tasks with known outcomes, written before the agent exists.

  4. Build with the audit log first

    Observability is not retrofitted onto an agent — you cannot debug one without it.

  5. Shadow mode

    The agent proposes every action and a human approves each one, for as long as it takes to build confidence in the numbers.

  6. Widen autonomy carefully

    Low-risk actions released from approval first, based on the measured success rate. Irreversible ones may stay gated permanently, and often should.

What you should expect

  • A multi-step task completed end to end without a person driving it
  • Nothing irreversible happening without an approval
  • Every decision reconstructable from the audit log
  • Prompt and model changes measured against a fixed evaluation set

Built with

  • Mistral
  • Anthropic Claude
  • OpenAI
  • TypeScript
  • Python
  • PostgreSQL
  • pgvector
  • Redis
  • Temporal
  • RabbitMQ
  • Model Context Protocol
  • LangGraph

Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.

AI Agent Development — your questions

Including the ones about cost, which most agencies leave off the page.

A single-purpose agent with three or four tools, approval gates and an audit log typically runs £15,000 to £35,000. Running costs depend on volume but are usually modest — the engineering around the model is the expense, not the model.

A chatbot answers; an agent acts. A chatbot tells your customer the returns policy. An agent looks up their order, checks eligibility, creates the return and books the collection. The second one needs permissions, limits and an audit trail, which is most of the work.

Four things, and none of them is trust in the model: tools that can only perform narrow validated operations, approval gates on anything irreversible, hard limits on steps and spend enforced in code, and an audit log so a mistake is diagnosable. We design assuming the model will occasionally be wrong, because it will.

For narrow, well-defined tasks with a human on irreversible steps, yes — we build and run these. For open-ended autonomy over important systems, not yet, and we will say so rather than sell you a pilot that quietly gets shelved.

You constrain it rather than eliminate it. Facts come from your systems through tools instead of from the model’s memory, outputs are validated against a schema before use, and anything unverifiable becomes an escalation rather than an action. Any supplier promising zero hallucination does not understand the technology.

Whichever benchmarks best on your evaluation set, behind an adapter so it can be changed. In practice we most often use Mistral or Claude for tool use. The important thing is that the choice is measured on your tasks and reversible, because the leaderboard changes every few months.

Talk to someone who has built this before

A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.