Automations that run unattended, and
somebody responsible when they don’t
Getting your team onto the assistants is the easy part. The work that pays for
itself is the automation nobody has to remember to run — and the reason to have
engineers build it is that something running unattended needs watching.
The first conversation costs nothing, and nothing that calls a paid model goes
live without a cost ceiling you agreed to.
invoice-intake
42 documents received this morning
Running
Read and classified
42
Posted to accounting
39
Held for a person
3
Failed silently
None
Model spend, this month$18.40 of $75.00
ceiling agreed before go-live
3 held for a person
What we do
Five ways automation earns its place
From the repetitive work between the tools you already pay for, through to staying responsible for it once it runs without anybody watching.
Workflow automation
Removing the repetitive work between the systems you already run.
Most of the manual work in a small business is not hard, it is just nobody’s job to stop doing it: copying an order into the accounting system, chasing a form that never arrived, re-keying the same address into three tools, assembling the same report every Monday. It survives because it is invisible until somebody measures it.
We find that work, agree which parts are worth automating, and build the automation that does it — then stay responsible for it once it is running unattended.
Connecting the tools you already pay for, so data stops being re-keyed
Scheduled work that used to be somebody’s Monday morning
Approval and hand-off steps that currently live in someone’s inbox
Alerts and notifications that fire on the event rather than on a person remembering
Reports assembled and delivered without anybody building them
Replacing the spreadsheet that holds a process together
Reading what arrives, and routing it where it belongs.
Work arrives as documents and messages: invoices, purchase orders, application forms, inbound email, support tickets, scanned paperwork. Somebody opens each one, decides what it is, pulls out the few fields that matter and puts them somewhere else.
This is the work current models are genuinely good at, and it is the easiest kind to measure honestly — you already know how many arrive and roughly what each one costs you in attention. We build the intake, the extraction and the routing, with a review step wherever being wrong would be expensive.
Intake from email, upload, a form or a shared folder
Extracting the fields that matter into your own systems
Classifying and routing by type, urgency or owner
Flagging the exceptions for a person instead of guessing
Reconciling what arrived against what was expected
A record of what was read, what was extracted and what a person changed
Answers from your documents and systems, not from the open web.
A general assistant knows nothing about your pricing, your contracts, your procedures or last quarter’s numbers, which is why the useful version is pointed at your own material. The questions a team actually asks are specific: what did we agree with this client, what is the current process for this, which of these is covered.
That means deciding what the assistant may see, keeping it current as the underlying documents change, and being clear with the people using it about what it is allowed to answer on its own. We also set the accounts and access up properly, which is usually the first thing a team needs and rarely the last.
An assistant grounded in your documents, policies and records
Access rules, so it only answers from what that person may already read
Keeping it current as the underlying material changes
Answers that cite the source, so they can be checked
Accounts, access and licensing set up properly for the team
Practical training for the people who will use it daily
Model-backed features in your own application, built to be operated.
Where you already have an application, a portal or a storefront, the automation often belongs inside it rather than beside it — a search that understands what was meant, a draft reply prepared for an agent, a classification applied the moment a record is created.
Adding a paid model to a route inside your own software is a different engineering problem from using an assistant: it runs on your infrastructure, on your budget, at whatever volume your users generate. That is the work we already do on the development and infrastructure side, which is why it sits here rather than being somebody else’s integration.
Model-backed features added to an application you already run
Search and classification that work on your own data
Drafting and summarising inside the tool your team already has open
Cost ceilings and rate limits on every route that calls a paid model
Choosing a model sized to the task rather than the largest available
Fallback behaviour for when the provider is slow, down or wrong
Staying responsible for the automations once they run unattended.
An automation that works on the day it ships is not the same as one you can rely on a year later. The tools it connects change their APIs, a model is retired or repriced, a provider has an outage, the volume doubles, and an edge case nobody modelled starts failing quietly at three in the morning.
This is the part most AI work skips, and it is the reason a business ends up trusting a process that has silently stopped running. Operations covers that as a standing responsibility rather than a series of surprises: the automations are watched, kept working as the services underneath them move, and fixed by the people who built them.
It runs as a monthly arrangement scoped to your automations, quoted alongside the build or after a review of something you already have. It is not metered by ticket.
Monitoring, so a failure is noticed by us rather than reported by you
Keeping up with provider API, model and pricing changes
Cost monitoring against the ceilings agreed up front
Fixing the exceptions that only appear at real volume
Incident response when an automation or a provider fails
Changes as the process changes, because a process always changes
A great deal of useful automation does not need anything written. Where an off-the-shelf platform will do the job reliably, that is what we recommend, set up and document — and we will tell you so even though it is the smaller piece of work.
What those platforms do not do well is the awkward part: an exception that needs judgement, a system with no usable integration, a volume that makes per-task pricing absurd, or a failure that has to be handled rather than retried forever. When a workflow reaches that line, we write the code, and we are not incentivised to pretend the line falls earlier than it does.
How we keep it safe
Four things you get in writing
An automation that runs without supervision can fail in ways a person never would. These are the four commitments that come with every one we build.
A cost ceiling, agreed up front
Anything that calls a paid model is metered and capped at a figure agreed before it goes live. Usage-priced services are the one place where a bug is also an invoice, and an endpoint that can call a model without limit is a bill waiting to happen rather than a theoretical risk. You are told what the ceiling is, and told when it is approached.
Your accounts, your keys, your data
Before anything is built you get it in writing: which accounts are in your name, who holds the keys, whose payment method is on each service, which of your data leaves your systems, and what the provider does and does not retain. Where a provider’s terms are not good enough for the data in question, that rules the provider out rather than becoming a footnote.
Automations fail loudly
The dangerous failure is not the one that stops, it is the one that keeps appearing to work. Every automation we build is built to surface its own failures — nothing retries into silence, nothing swallows an error, and nothing quietly drops the work it was given. If it stopped, you will know it stopped.
A person stays in the loop where it matters
Nothing that spends money, commits you to something or carries a legal consequence runs unreviewed by default. Where a step is automated end to end, that is a decision taken deliberately, with you, once the behaviour has been observed on real work — not the starting assumption.
The stack
What we build with, and run in production
Models are chosen per workload rather than once per company. Each name with a guide behind it links to it.
Models
Chosen per task, and sized to it rather than to the headlines.
Claude
OpenAI
Google Gemini
Automation platforms
Where an off-the-shelf platform is the right answer, these are the ones we set up and document.
Zapier
Make
Systems we wire in
The services an automation has to speak to on the way through.
One automation in real use before a programme of them is agreed, and a person watching it until it has earned the trust.
01
Conversation
We talk through where the manual work actually is, what you have already tried, and whether any of it is worth automating yet. Sometimes the answer is that it is not, or not before something else is fixed. This conversation costs nothing.
02
Assessment
A written, prioritised view of the candidates: what each one would take off your team, what it would cost to build and to run, what could go wrong, and which one to do first. It is scoped and quoted as its own piece of work, and it is yours to act on with or without us.
03
Build the first one
One automation, built and in use, before a programme of them is agreed. You learn more from a fortnight of a real automation running on real work than from any amount of planning, and it is a far cheaper place to discover that the process was not what everyone believed.
04
Go live with a person watching
A new automation starts with its review step on and its cost ceiling set, running alongside the manual process rather than replacing it on day one. We take the training wheels off once the behaviour has been observed on your own work, and we decide that together.
05
Operate it
Once it is unattended it needs an owner: monitoring, cost tracking, keeping up with the providers underneath it, and fixing the exceptions that only appear at volume. That runs as a monthly arrangement scoped to your automations, and it is optional — the automations are yours either way.
Where the line is
What this isn’t
Four things we will not sell you, because each one is either someone else’s work or a promise nobody can keep honestly.
Training or building a model from scratch
We build on models from established providers rather than training our own. A business at this scale is almost never better served by a bespoke model than by a good one used well, and we would rather say so than sell the more impressive-sounding version.
Strategy without implementation
We do not sell a presentation about what you could do. The assessment exists to decide what to build and in what order, and it is written to be acted on — by us or by anyone else you choose.
An accuracy figure we have not measured
We will not quote a percentage for how accurate an automation will be on work we have not seen. Where accuracy matters we measure it on your own data during the build, agree what is good enough, and design the review step around what is left.
Automating a process nobody has questioned
Some of the work we find should be removed rather than automated, and some should be fixed in the system that creates it. Automating a bad process makes it faster and harder to see. Expect to be told when that is what we are looking at.
Before you ask
Questions worth asking first
We are already using ChatGPT and Claude. What is different about this?
Those are assistants: a person opens them, asks for something and uses the answer. That is genuinely useful, and getting a team properly set up on it is work we do. An automation is the next step — it runs without anybody opening anything, on a schedule or when an event happens, and it writes its results back into the systems you run. The difference that matters commercially is that nobody has to remember to do it, and the difference that matters operationally is that something unattended needs watching.
How do we know what to automate first?
That is what the assessment is for. It looks at where the repetitive work actually is, what each candidate would take off your team, what it would cost to build and to run, and what could go wrong — then puts them in an order. The first build is usually the one that is well understood and boring rather than the one that is most impressive, because the first automation is also how everyone learns to trust the rest.
What stops this running up a large bill?
A ceiling, agreed before it goes live, on every route that calls a paid model, plus metering so the figure is visible rather than discovered on an invoice. We also size the model to the task: a smaller, cheaper model is frequently sufficient for classification and extraction, and using the largest available model everywhere is a common and expensive default. Usage-priced services are the one place where a bug is also an invoice, and we treat them that way.
Where does our data go, and is it used to train anything?
You get that in writing before anything is built: which of your data leaves your systems, which provider receives it, what that provider retains, and what their terms say about training on it. Where a provider’s terms are not acceptable for the data in question, that rules the provider out rather than becoming a footnote. Accounts and keys are in your name wherever the service allows it.
What happens when the automation gets something wrong?
It is designed on the assumption that it will. Anything consequential keeps a review step, exceptions are flagged for a person rather than guessed at, and failures surface rather than retrying into silence. Where accuracy matters we measure it on your own data during the build and agree what is good enough before it is relied on — which is also why we will not quote you an accuracy figure for work we have not seen.
Which model do you use?
Whichever fits the task and your data policy — we build with Claude, OpenAI and Google Gemini. That decision is made per workload rather than once per company, because the models differ in cost, speed and what they are good at, and the right answer for classifying a form is rarely the right answer for drafting a reply. We keep that choice changeable, so a repricing or a retirement at one provider is a change rather than a rebuild.
Can you take over automations somebody else built?
Yes, and it is a normal engagement. We start by reading what is there — what it does, what it connects to, whose accounts and keys it runs on, where it fails and what it costs to run — and give you that in writing. Undocumented automations built by someone who has since left are a common reason businesses come to us, and the first job is usually to find out what is still running.
Who owns what gets built?
You do. Work built specifically for you becomes yours on full payment, the same as on any development engagement, and the accounts it runs on are in your name wherever the service allows it. The exception is the general-purpose tooling and know-how we bring with us, which stays ours. If the arrangement ends, you are left with working automations and the documentation for them rather than a dependency.
How do you scope and price this?
The first conversation costs nothing. The assessment is scoped and quoted as its own piece of work, with a written deliverable you own. Builds are quoted per automation or per engagement once there is a plan, and ongoing operations is a monthly arrangement scoped to the automations you end up running — not metered by ticket.
Do you also run the systems these automations depend on?
Usually, and it tends to be the same conversation. Servers, cloud environments and applications are sold as their own services, so an automation we build can sit on infrastructure and software the same team operates — which matters most during an incident, when there is no handover boundary in the middle of it.
You do not need to know what to automate, or whether any of it is worth automating
yet — that is what the first conversation is for, and sometimes the answer is that
something else should be fixed first. It costs nothing either way.
