Your accounts. Your keys. Your data. A system you keep if we stop working together.
Automation earns its place by touching real things — your inbox, your customer records, your paperwork. That is the whole value, and it is also the whole risk. So the honest version of this page is not a list of reassurances. It is a list of what we can reach, what we cannot do, and what happens to all of it if you leave.
Most of what follows is architecture rather than policy. A policy is a promise that someone will behave correctly. Architecture is a capability that does not exist to be misused. Where we could choose either, we chose the second one.
Everything is built inside accounts that already belong to you.
There is no “our platform” that your business runs on top of. That is the arrangement that makes leaving expensive, so we do not use it.
The accounts are yours
Your workflow platform, your cloud project, your AI key, your mailbox. They are opened in your name and billed to you. We are a user inside them, not the owner of them.
The automation is yours
The workflows, the prompts, the logic and the documentation are yours to keep, edit, or hand to someone else. There is no licence that expires and no runtime you have to keep renting from us.
The data never leaves your systems
The work happens where your data already lives. We are not a middle layer that your customer records pass through on the way to somewhere else.
The bill for the machine is yours too
AI usage and workflow hosting are billed directly in your accounts, at whatever the provider charges. We never mark it up and never take a margin on it. Typically $10–50 a month. The whole fee schedule is published.
We ask for the narrowest access that lets the work happen, and nothing beyond it.
Least privilege is not a posture. It means that when we ask for something, we can tell you which step of your workflow needs it — and if we cannot, we should not have it.
Scoped to the workflow, not to the account
Access is requested per system and per job. A build that reads your inbox does not get your billing. A build that files invoices does not get your customer list.
A named owner on both sides
Every workflow has one person accountable for it here and one at your company. No tool soup where three systems fight over one inbox and nobody can say what did what.
Granted by you, in your own console
We never ask for a password. Access is added the way your platform adds a collaborator, from your side, visible in your own admin log — which also means you can see exactly what we hold at any time, without asking us.
Shadow mode before anything real
Five to seven days running against your live data with zero writes. Watching, not touching. Our last shadow run caught two defects before they reached real mail.
The dangerous capabilities are not switched off. They were never built.
This is the part of the page we would most like you to test us on, because it is the one claim here that cannot be quietly walked back.
A system that is allowed to email your customers and merely configured not to is one bad afternoon away from doing it. So our builds do not contain the ability to send. The node is absent from the workflow. There is nothing to misconfigure, nothing to bypass, and nothing an instruction can talk it into.
The same is true of money. Refunds, payments, and anything financial are prepared, evidenced, and left for a person to action in their own tools, with an audit trail of what was proposed and by what.
A filter can be bypassed. A missing tool cannot. When we say a human approves it, we mean the machine has no alternative.
Every action the system takes is one you can undo.
Archive and label, never delete
Nothing the automation touches is permanently removed. It is moved, marked, and left recoverable, so a mistake costs minutes rather than data.
Thirty-day recovery on what it touches
Because actions are reversible by construction, anything the system did in the last thirty days can be put back. This describes how the automation behaves inside your platform — it is not a separate backup product.
Every disposition is logged
What it read, what it decided, and why. A month-end question about one message has an answer, not a shrug.
Uncertain means escalate, not guess
A message the system cannot classify with confidence is flagged and left for a person. It escalates rather than guessing, which is the behaviour you want on the one message that matters.
We alert on the run that never happens, not only the run that errors.
On our own systems, roughly one scheduled run in seven once died with nothing to tell anyone. Not an error — an absence. Every monitor we had watched for failures, and a run that never starts does not fail. We found it by going looking, reconciled three logs, and two of them disagreed.
That is why monitoring is a line item on our invoices rather than a courtesy, and why every build we ship now alerts on absence. The whole record is published, including the number that does not flatter us.
When something does break, the escalation path is a published commitment rather than a favour: severity levels, acknowledgement times, and when an engineer is actually on it. The response targets are on the pricing page with everything else you would be agreeing to.
Cancel with thirty days, keep everything, and it keeps running.
The test of whether you really own a system is what happens on the day you stop paying for it. Here is that day.
Thirty days, any reason
No annual lock-in and no exit interview. If the system no longer needs us, that is the automation working the way it was supposed to.
Nothing switches off
The build lives in your accounts and keeps running without us. There is no licence key to expire and no service of ours to disconnect.
A handover pack, already written
Runbooks, architecture notes, and documented credentials, refreshed quarterly throughout the engagement. Not written on the way out the door, when the person who knew how it worked is already gone.
Pause instead, if it is a slow season
Up to sixty days a year at a quarter of the retainer, with monitoring still on, so a quiet quarter does not force you to cancel and rebuild later.
Bring us the system you are most nervous about.
The audit is ninety minutes on how your week actually runs, then a written report: every automation candidate we found, what it gives back, what it costs to build, and the ones that are not worth doing. You own the report either way.