Automation That Survives Contact With Reality

Most AI projects I see fail for a boring reason: they need someone to keep them alive. Someone has to remember to run the script, check the dashboard, notice the silent failure. The moment the enthusiastic person gets busy, the system dies quietly — usually down the failure path nobody designed.

I've automated large parts of how I run my businesses from Dubai — operations, communications, publishing — and the difference between systems that stuck and systems that died came down to a few unglamorous design decisions. Here they are, from someone still running them.

1. Scheduling should be so easy it's embarrassing

My reminder and task system works like this: I write a small markdown file into a folder and commit it. That's it. A dispatcher picks it up and fires it at the right time — a Telegram message, a push notification, a batch of scheduled work.

No app, no forms, no third-party SaaS with a monthly fee and an API that changes. Files in a git repository. Because scheduling is trivial, I actually schedule things — dozens per week. The lesson for businesses: the friction of using a system determines whether it survives, not its feature list.

2. No-AI is a feature

Here's my favorite architectural decision: the dispatcher that fires all my scheduled automation contains zero AI. It's a dumb loop that checks a folder every 60 seconds. AI — with its costs, its latency, its failure modes — is spent only where comprehension is genuinely needed.

Companies keep adding language models to things that need if statements. Every AI component you add is a component that can hallucinate, rate-limit, or get expensive. Default to dumb; upgrade the specific spots where understanding actually pays.

3. Health checks must read the data, not the process

One of my data pipelines reported healthy for days while completely dead — three mirror outages hid behind a green process status, because every proxy signal lies. docker ps said running; the database inside hadn't accepted a write since Tuesday.

The fix: health checks that read the actual data ("was the newest row written in the last 15 minutes?") instead of checking whether a process exists. And a watchdog that pings me when silence looks wrong — because, as I learned, a watchdog that runs late is not watching.

If your business runs automated pipelines — invoices, syncing, scraping, reporting — check right now whether your monitoring would catch a silent failure. Most don't. The system looks fine in the dashboard and has been losing data since last Thursday.

4. Everything a system does should leave a paper trail

Every automated action in my stack writes a record: what ran, when, what it decided, what it cost. When something behaves oddly, I diff reality against the log and find the exact moment it diverged.

For a business, this is the difference between "the AI did something weird" (uninvestigable) and "the AI did something weird at 14:03, here's the input, here's the output" (fixable in an hour). If you can't replay what your automation did last week, you don't own your automation — it owns you.

The bottom line

Durable automation is mostly unglamorous: trivial-to-use interfaces, dumb-by-default components, honest health checks, complete logs. The AI is the easy part.

If your company has automation or AI that was shipped once and never verified since (shipped is not running) — or that keeps silently failing — or you suspect it will the moment the person who built it goes on holiday — that's a great fit for a consulting day. I'll map what survives and what doesn't, and leave you with a system that runs without anyone babysitting it. Or send an inquiry if you want to discuss first.