The problem
AI Automation for Repetitive Business Work
If your team answers the same twenty questions every day, and your operations run on spreadsheets, email threads and WhatsApp, most of that work is a process rather than a judgement call.
AI automation hands the repeat work to a system and keeps the judgement with people. Ghost Protocol builds those systems one process at a time, on infrastructure you own, with a person in the loop wherever being wrong is expensive.
One process first, never the whole business · a person in the loop where it counts · code, data and infrastructure yours at handover
Three shapes this usually takes
Almost every automation conversation we have starts as one of these three. If one of them is recognisable, the rest of this page is written for you.
What actually gets automated
Not the interesting parts. The parts that repeat, where the answer already exists somewhere and a person is the transport layer:
What we will not automate
Three cases where the answer is no, or not yet. Saying them early is cheaper for both of us than discovering them in month two.
A process nobody has written down. If the rule lives in one person’s judgement and shifts case by case, automating it makes the inconsistency faster rather than smaller. Write it down first. Sometimes writing it down turns out to be the whole fix, and that costs you nothing.
Anything expensive to get wrong with nobody checking. Money moving, contracts, medical or legal advice, or anything a customer acts on before a person has read it. Those get a human in the loop by design, or they do not get built. An automation that is right nine times out of ten is a liability when the tenth one is a payment.
The whole business at once. A system that touches everything is a system nobody can test, and nobody can roll back either. We take one process, get it right in front of real work, and only then look at the next one.
How a build runs
Five steps. The measurement comes second, before anything is built, because a system with no baseline can only be defended with opinions.
Pick one process
The one that costs the most hours and needs the least judgement. We watch it happen once, end to end, and write down what actually occurs rather than what the process document says.
Measure it first
How often it runs, how long it takes, and how often it goes wrong today. Without that, nobody can honestly say afterwards whether the system helped.
Build the narrow version
The smallest thing that does the real job on real data. You use it on live work before we build anything else on top of it.
Put the person where it matters
Approve, edit, or escalate. The system drafts and routes; a person still owns the decisions that cost money or reputation.
Hand it over
Code, prompts, deployment and a runbook. It runs on your infrastructure, and you can turn it off without calling us first.
What it runs on
The default is Cloudflare’s edge, which is the same infrastructure our own products run on, so nothing here is a stack we recommend to clients and avoid ourselves. Models are chosen per step rather than per project: cheap and fast where the task is classification, stronger where the reasoning has to hold, local and self-hosted where the data is not allowed to leave.
An automation is also an authenticated user holding tools, so the permissions it runs under are decided in writing before it is built, and read the way we read any other authenticated user. That is the same team and the same discipline as our penetration testing. The wider AI picture is on the AI pillar page, and the memory layer we built for our own agents is Wyrm.
Frequently asked questions
Software that does a repeating piece of work end to end, using a language model for the parts that involve reading, writing or judging text, and ordinary code for everything else. The useful version is boring: it reads what arrived, works out what kind of thing it is, does the standard next step, and asks a person when it is not sure.
Usually yes, if the answers exist somewhere you control. The system answers from your documents, prices and records rather than from what a model happens to believe, and it shows what it used so a person can check it. Anything it is unsure about goes to a human instead of being guessed at.
With the single process that costs the most hours and needs the least judgement. We watch it happen once, write down what actually occurs, count how often it runs, and automate that one thing. Not the whole business, and not a platform migration you did not ask for.
It will, so the real question is what the system does about it. Steps that are expensive to get wrong get a person in the loop by design. Everything the system does is logged, so a wrong answer can be traced back to the input that caused it, and that case is added to the evaluation set the next change has to pass.
No, and we would push back if you asked. Automation is wired into what your team already uses. A tool migration is a separate decision with its own cost and its own risk, and bundling it into an automation project is a reliable way to make both fail.
The first version is deliberately small: one process, on live work, in your hands early. We do not quote a date until the process is scoped, because a date set against a wishlist is a guess, and the only useful date is the one you can hold us to.
In the work we have done it removes the repeat task, not the person. What is left is the part that needed a person anyway: the exceptions, the judgement, and the customer who is upset. If a role is genuinely nothing but repetition, that is a decision for you to make with your eyes open, and we will not pretend otherwise in a sales meeting.
That depends on the provider, the plan and the endpoint, and it is a scoping question we answer in writing rather than a slogan. Where the answer has to be that nothing leaves your environment, we build against open models you host yourself.
Quoted against a written scope. The fixed prices published on this site are for security testing; automation work varies too much for a printed number to be honest. The first call is free and takes fifteen minutes.
Name the one thing you do fifty times a week.
Describe that process and you get an engineer’s read on whether it can be absorbed, what it would take, and where a person still has to stay in the loop.