An agent that doesn't wait to be asked
An AI agent isn't another chat window waiting for a question. It takes a goal, breaks it into tasks, reaches for the tools and sources it has, executes — and reports what came out. I build those for organisations, on their real processes and their real data.
What an agent actually is
The difference between a chat and an agent is the difference between an adviser and a doer. A chat answers a question and waits for the next one; an agent takes a target — "go through this week's enquiries, classify them, draft a reply to each and flag the ones that need a human" — and runs to the end without someone holding its hand at every step.
What makes that possible isn't the model but what you connect to it: permissions, sources, tools it's allowed to fire, and clear limits on what it may decide alone and what goes for approval. That's the part I build, and it's almost always bigger than the prompt.
Which is why a good agent isn't an off-the-shelf product. It's built around a specific process, with the organisation's own knowledge, and with an understanding of what happens when it gets something wrong — because it will, and the only question that matters is who notices and when.
What goes into an agent I build
Not every agent needs all of these. Scoping decides what's in, and the rest waits for the next version instead of bloating the first.
A goal and a plan
Exactly what the agent is meant to achieve, how it breaks that into tasks, and when it counts as finished.
Your organisation's knowledge
Connected to your documents, procedures, price lists and history, so answers come from your sources and not from the open web.
Tools and actions
The ability to open a ticket, send an email, update a table or pull a figure — each under a defined permission and fully logged.
Limits and approvals
What it does alone, what needs a human sign-off, and when it stops and hands over. This is what makes it safe to use.
Traceability
A log you can actually read, so it's always clear what the agent did, on what basis, and what it cost.
Multi-agent systems
When a job is too big for one agent — several with distinct roles that plan, execute and check each other.
How it gets built
From your process to an agent running in production, in four stages you can stop at any one of.
- 01
Pick one task
Not "an agent for the company" but a defined, repeating task where it's clear how long it takes today and what happens when it fails.
- 02
Scope permissions and sources
What it reaches, what it may change, where the line is above which a person is required. Sensitive data is settled here too.
- 03
Build and run on real cases
The agent runs alongside the team on real work, and we compare what it did against what would have happened without it.
- 04
Roll out and extend
The team is trained, the agent moves into routine use, and further tasks are added on the same foundation.
Why it works
My background is systems analysis, not just driving tools — and that dictates the order of the work.
- Every agent is built on a real process that gets mapped first, so it removes a step instead of adding one.
- Permissions and limits are defined up front, because an agent with too much access is a risk, not an advantage.
- Staged delivery: a working version early, extended on the strength of what actually happened rather than what was planned on paper.
- The team gets training and documentation, so the system keeps running when I'm not around.
Questions that come up
How is an agent different from ordinary automation?
Automation runs a fixed sequence. An agent decides the steps from the situation — it can read an enquiry, recognise it isn't standard and take another route. When the process is identical every time, plain automation is better, and I'll say so up front.
Does the agent reach our sensitive data?
Only what you decide to give it, in a scope written down before anything starts. In some cases sensitive material is kept entirely separate from what's sent to a model, and scoping settles what stays inside the organisation.
What happens when the agent gets it wrong?
We assume it will. Hence the action log, the points where a human sign-off is required, and a definition of what the agent never touches. The expensive mistake isn't an agent's — it's the one nobody saw.
How long does an agent take to build?
A focused single-task agent goes live within a few weeks. A multi-agent system is a longer, staged project. I give a precise range after the discovery call, once it's clear what's actually in scope.
Do we need a technical team?
No. I build, roll out and train. If you do have IT or developers, we work with them on the connections and permissions, which shortens the path.
Can we start small?
That's usually my recommendation. One task, one agent, a measurement of what it saved — and only then a decision about extending. It also makes it obvious quickly whether it pays.
