Automation youdon't have to babysit.
Updated: August 2026
The biggest worry with AI and automation is that it goes rogue and does damage. I take that seriously, so I don't treat reliability as an afterthought, I build it into the loop from the start. This is how I keep mistakes from happening, and this is how honestly I tell you what I do when something breaks anyway.
Safety is wired in, not written into a prompt
I build a loop so a bad run can't do damage even if something goes wrong. Critical rules aren't a plea in the text to the model, they're a fixed part of the architecture. If you're unsure whether to trust automation, this is the foundation reliability stands on.
A human on the last check
Where something is sensitive, the loop doesn't decide alone. It prepares a proposal and leaves the final say and the send to you.
Dry run first
Before anything runs for real, it runs as a dry run on real data. Mistakes get caught before they do damage, not after.
Idempotence
A repeated run won't create a thing twice or send the same thing again. If something fails halfway, it can be safely re-run.
Fails safe
In doubt the loop would rather do nothing and set the item aside for review. Nothing destructive happens on its own by default.
When the loop isn't sure, it waits
Every input is validated before the loop acts on it. If one item doesn't pass, the run doesn't collapse because of it, that item goes to a review queue and the rest continues. By default the loop deletes or overwrites nothing irreversibly, because the safe option is always to leave a decision to a human rather than break something.
I learn about an outage before you do
Every run is logged, so you can see afterwards what happened. When something fails I get an alert, and you don't discover an outage from something quietly stopping. The loop's health is checked continuously and, on request, I can send you a regular report of what the loop did.
Execution logging so it's traceable what happened.
Failure alerts to the operator, no silent dying.
Continuous health checks on whether the loop is alive.
An optional regular report to you on the work done.
This is the most important part. Automation occasionally trips over something, what matters is what happens next. The loop doesn't fail blindly, it runs through this decision chain.
Run
The loop starts on a schedule or event and begins processing.
Error?
Each step is validated. If it passes, it continues without intervention.
Transient error
A temporary outage, e.g. an API briefly unavailable. It retries with a growing backoff.
Permanent error
Something is persistently off. The item goes to a review queue and I get an alert.
Resolved
I fix it and, thanks to idempotence, safely re-run it, with no duplicates.
Changes are versioned and reversible
Each loop's code is under version control in Git, so it's clear what changed when and why. Before a change goes live, it runs as a dry run in a preview or staging environment. If something misbehaves, it can be rolled back to the last working version. Changes that touch your operations, I tell you about in advance.
Git version control, every change leaves a trace.
A dry run in a preview or staging environment before going live.
Rollback to the last working version when something breaks.
Changes that affect you are communicated in advance.
I don't publish a contractual SLA, and here's why
I won't promise you a contractual SLA with guaranteed uptime. I'm one person, not a night shift on call, and I couldn't fairly cover that commitment 24 hours a day. What I will tell you honestly is this. The loop itself runs on managed cloud infrastructure (Vercel, Railway) that has its own redundancy and its own uptime at the level of large providers, and you can check their status any time on their status pages. I respond to incidents quickly during business hours and on a best-effort basis outside them. The advantage of a small operation is that you get the truth and know exactly who to turn to.
- No contractual SLA that one person couldn't honestly staff around the clock.
- Underlying infrastructure (Vercel, Railway) runs in a redundant cloud with its own uptime and public status pages.
- Incident response is fast in business hours, best-effort outside them.
Your systems stay the source of truth
The loop sits alongside your tools, it doesn't replace them. Data keeps living in your CRM, inbox and invoicing, so if a loop disappeared overnight your data wouldn't go with it. You still have it, and you can fall back to it manually. The loop's operational state and configuration are held by the platforms it runs on, with their own backups.
No data held hostage
When we finish, you remove the invited access and rotate keys and tokens on your side. I hand over documentation on how the loop worked, and I keep none of your data or access. The exit is clean and quick, because the source of truth was with you the whole time.
You remove access and rotate keys, on your side.
I hand over documentation on how the loop worked.
I keep none of your data or access.
01Do you offer a guaranteed uptime SLA?
No, and it's a deliberate choice. A contractual SLA with a guaranteed 24-hour response time isn't something I could honestly cover as one person, so I don't promise it. The underlying infrastructure does run on a redundant cloud with its own uptime, and I respond to incidents fast in business hours and best-effort outside them.
02What happens if the loop crashes mid-run?
I build loops to be idempotent, so a repeated run won't create a thing twice or send the same thing again. If something fails halfway, I fix it and safely re-run it, with no duplicates.
03How will I find out something went wrong?
I handle it primarily, because a failure sends me an alert. On request I can also send you a regular report of what the loop did and whether anything went to the review queue.
04What if the automation makes a mistake and sends something wrong?
That's why I leave the final say and the send to a human on sensitive steps, and why everything is tested with a dry run first. Nothing destructive happens on its own by default, and doubtful cases go to a review queue instead of being sent blindly.