Automation that holds up4 posts

What makes an AI automation safe to leave running?

An AI automation is safe to leave running when a failure makes noise and an irreversible action has a gate in front of it. It also needs one habit most skip: whatever a model returns gets checked against the source before anything uses it. Without them, it fails quietly, and a customer notices first.

  1. 2 min

    No. 27: How to prevent accidental data deletion in automated systems: make it refuse

    To prevent accidental data deletion in automated systems, make the database refuse any delete that would take other records with it, and have the refusal say what it is blocking. The damaging deletes tend to come from a cleanup step that reports success, so the loss stays hidden until somebody needs the record.

  2. 3 min

    No. 20: Rollback plan for an AI workflow: what can still be put back after it acts

    A rollback plan for an AI workflow has to say what can be put back after the system acts. Restoring the last working version covers the code. Actions waiting to happen should stay editable until they run, and data already written needs its own answer, because reverting the code does not unwrite anything.

  3. 3 min

    No. 15: Monitoring an AI workflow without an engineering team starts with a morning read

    Monitoring an AI workflow without an engineering team comes down to two things a person actually reads. One is a short summary each morning of what the system did and what it held back. The other is a failure alert on the phone they already check, plus a regular test alert, since a broken alert path is silent too.

  4. 4 min

    No. 02: Should an AI agent send your emails? Ours did, once

    No, an AI agent should not be the part that actually sends your emails. Let the model draft and sort, then pass each message to a small, boring service that sends on a schedule and confirms every delivery. OCTYN learned this after a model driven sender built for a client reported a send that never happened.

Where this leads

The systems and arguments this topic points at.

Other topics

The rest of the writing.

  • Build or buyBuild or buy, what it costs, and what to ask before anyone builds you anything.
  • Client contextThe work of reassembling who a client is before every next touchpoint, and how to stop doing it.
  • Founder operationsCounting the hours that never needed a human, and deciding what to hand to a system first.
  • Growth systemsContent and outbound that keep running when the founder is busy, and still sound like the company.
  • Operations systemsIntake, handoffs and status carried by one system, so the team keeps the judgement calls.
  • Product systemsA model inside a product: speed, fallbacks, keys, and what running it costs after launch.

Bring the version of this that is about your company.

The first conversation is with the people who would build it. If there is a fit, the Consult comes next.

Book a mapping call