AI Automation
AI automationthat runs unattended
AI automation is only worth building if it works while nobody is watching. I build agents, workflows and integrations that handle the manual process eating your week, retry when things fail, escalate when they need a person, and keep a log you can read six months later.
- First version in days
- Runs in your accounts
- You own the code
Sound familiar
The things people tell me on the first call
We automated it, but someone still has to check it every morning.
The person who built it left. Nobody knows how it works now.
It works until the API is slow, and then it just silently stops.
We paid for a six-week discovery and got a diagram.
How I build
Failure first, features second
Most automation projects are designed around the happy path and then patched every time reality intervenes. I do it the other way round. Before I write the thing that does the work, I decide what happens when the API times out, when a record is malformed, when a rate limit hits, and when a human needs to intervene.
That sounds slower. It is not, because the alternative is six weeks of unplanned firefighting after launch.
The second principle is that it runs in your accounts. Your cloud, your API keys, your repository. I have seen too many businesses discover that their critical process lives inside a consultant’s automation platform account. If we stop working together, nothing of yours stops working.
# a real run, including the bad casesync --source=crm --window=1hfetched 218 recordsrate limited -> backoff 2s, retry 1rate limited -> backoff 4s, retry 2ok. 214 written, 4 -> dead-letteralert sent: 4 records need reviewexit 0 next run 14:00What you get
Every automation engagement includes
Not a menu. This is the standard, and it is the same whether the project is one workflow or fifteen.
-
Process mapping from the real thing
I watch the process being done rather than reading a description of it. The gap between the two is where every automation project goes wrong.
-
A working first version in days
Something running end to end on real data inside the first week, even if it only handles the common case. Everything after that is refinement against something you can see.
-
Error handling designed up front
Retries with backoff, a dead-letter queue you can inspect and replay, and alerting routed to the person who can act rather than a shared inbox.
-
Logs written for humans
Plain-language records of what was attempted, on what, and what happened. Searchable by someone who has never met me.
-
Everything in your accounts
Your cloud, your keys, your repository, from day one. No consultant-owned infrastructure and nothing to migrate later.
-
Handover that actually transfers
Documentation aimed at whoever maintains it next, a recorded walkthrough, and thirty days of me fixing anything that surfaces.
The process
Three steps to something running
-
Watch the process
A screen-share of the job being done, start to finish, including the parts people apologise for. That session usually changes the scope, always for the better.
-
Ship the common case
The version that handles the eighty percent, running on real data, in your accounts. You use it while I build the edge cases around it.
-
Harden and hand over
Error paths, alerting, logs, documentation and a walkthrough. Then thirty days of support while it settles.
Measured before, measured after
I instrument the manual process before replacing it. Without a baseline, any improvement afterwards is a story rather than a result, and stories are what got you the automation that needs babysitting.
Receipts
Automation work with the numbers attached
Who you work with
Me. That is the whole team.
I came to automation from infrastructure, which is why my work is built around failure rather than around a demo. I spent years keeping systems up, and that leaves you with a permanent suspicion of anything that has only ever been tested on good input.
You will not be handed to a junior after the first call. You will not get an account manager summarising what I said. When something breaks at eleven at night, you have my number, and I would rather you used it than waited until the morning.
The trade-off is capacity. I take a small number of projects at a time, so occasionally the honest answer is that I cannot start for a few weeks. I will tell you that immediately rather than stretching the timeline to fit.
Questions
AI automation, answered plainly
What kinds of process are worth automating?
Anything repetitive, rule-based and high volume, and anything where the delay caused by a human doing it costs you money. Data entry between systems, enquiry triage, report generation, reconciliation and monitoring are the usual candidates. Processes that need genuine judgement on every instance are usually not worth automating end to end, though the preparation around them often is.
Do you use AI for everything?
No, and be suspicious of anyone who does. A language model is the right tool for reading unstructured text, classifying messy input and drafting language. It is the wrong tool for arithmetic, for deterministic routing and for anything that must produce the same answer every time. Most of what I build is ordinary code with a model doing the two or three steps that genuinely need one.
What does it cost to run afterwards?
Usually very little. Most automations run on a small server or a serverless function costing a few dollars a month, plus API usage. I will give you the expected running cost in the proposal, and I design to keep it predictable rather than letting it scale with volume in a way that surprises you later.
What happens if it breaks after handover?
Thirty days of fixes are included, and after that I am available for ad-hoc work at an agreed rate. Because everything runs in your accounts with readable logs, most businesses find their own developer can handle routine issues. That is deliberate. I would rather you did not need me.
Can you work with our existing automation platform?
Yes, if it is genuinely serving you. I work with the common platforms as well as writing custom code, and for simple workflows a platform is often the better answer. Where I push back is when a business-critical process is locked into a platform account nobody owns, or when platform limits have turned a simple job into an elaborate workaround.
Next step
Tell me which process is eating the week
Describe it in a paragraph. I will tell you whether it is worth automating, roughly what it costs, and how long it takes. If the honest answer is that a spreadsheet formula would fix it, that is what you will hear.
- Reply within 24h
- Honest scoping
- No retainers required