An agent is not a chatbot with ambition. It is software that acts on your behalf

The interesting part of agent engineering is not the model. It is deciding what the agent may touch, what it must ask about, what happens when it is unsure, and how anybody reconstructs a decision three weeks later. Those four questions separate an agent you can put in front of a process from a demonstration.

  • An agent doing a real task end to end. One process, carried out against your real systems, not a scripted demonstration.
  • Explicit bounds. What it may read, what it may change, up to what value, and what it must escalate — written down and enforced in code rather than in a prompt.
  • A decision log. What it saw, what it concluded, what it did and who approved it. Kept permanently, readable by a person, and the reason the whole thing is defensible.
  • A reduction path. A defined way to narrow what the agent may do unattended, which is the first response to anything going wrong.
Talk to us about this

What is delivered

  • Task and boundary definition

    The task in operational terms, and the boundary around it: permitted actions, value limits, data it may see, and the cases that always go to a person.

  • Tool layer

    The agent talks to your systems through explicit, typed, permissioned tools rather than through general access. This is where most of the safety comes from and most of the work goes.

  • Evaluation set

    Real cases with known good answers, including the awkward ones, so a change can be judged rather than felt. Built before the agent, not after.

  • Approval and escalation

    Where a person confirms, how the agent asks, and what a good escalation contains. Designed so that reviewing is fast, because slow review turns into rubber-stamping.

  • Observability

    Decision logs, cost and latency per task, and monitoring built for a system that fails quietly rather than one that crashes.

  • Runbook

    What to do when it is wrong: how to narrow its scope, how to roll back, and who is called. Written before it is needed.

How it runs

  1. 01

    Scope one task

    Narrow, high-volume, and with a checkable outcome. Broad agents fail in ways nobody can debug; narrow ones earn the right to grow.

  2. 02

    Build the tools

    The integrations and permissions first, agent behaviour second. An agent is only as good as what it can safely reach.

  3. 03

    Evaluate honestly

    Against the evaluation set including the exceptions, with the failure rate published rather than smoothed.

  4. 04

    Ship behind approval

    In production with a person confirming outbound actions, then widen the bounds as the evidence supports it.

A good fit when

  • A high-volume task with a checkable outcome and clear rules of thumb.
  • Work that currently requires reading unstructured input and preparing a structured action.
  • You already tried a chatbot and found it could answer but not do.
  • You need the audit trail as much as the automation.

Not the right service when

  • The process is not defined and different people do it differently. Fix that first — automating an undefined process encodes one version of it at speed.
  • The task is low-volume and high-consequence. A checklist is better and cheaper.
  • You want autonomy without approval gates on irreversible actions. We will not build that.

Frequently asked questions

Which models do you use?
Whichever fits the task, the data rules and the budget, and the choice is deliberately replaceable. Model providers change quickly, so the architecture keeps the model behind an interface rather than building your process around one vendor.
Can the agent act without a person?
For reversible, bounded actions, yes, once the evidence supports it. For anything irreversible — money leaving, a customer contacted, a commitment made — a person approves. That boundary is the design rather than a first-release limitation.
What happens when it is confidently wrong?
It will be, occasionally, because that is what a probabilistic system does at the edges. What is designed is that it is noticed quickly, characterised honestly, and bounded so the cost of being wrong stays small. The first response is always to reduce autonomy, then investigate.
How do you stop prompt injection and data leakage?
Mostly by architecture rather than by instructions: typed tools with narrow permissions, untrusted content never treated as instructions, output validation, and data the agent has no need for simply not reachable. Prompt-level defences alone are not a security model.
How long until something is running?
A narrow first agent in production behind approval is typically weeks. Widening the bounds takes longer and should, because each widening needs evidence from the previous one.

Keep reading

Other services