Ep 07
Automation you can actually inspect
Automation doesn't fail loudly. It stops doing one step, and nobody notices for a week — which is why the first thing worth building is not more steps, but the ability to see what the steps did.
The voices in this episode are AI-generated. The research, writing and opinions are Ramanjit Singh's.
Two hosts talk through why a run log that's 100% green should make you suspicious, the four properties that make automation inspectable, and honest guidance on build versus buy.
Chapters
- 00:00 — The problem: the characteristic failure is silent
- 02:10 — Why show the bad run
- 04:40 — Four properties, in the order to add them
- 07:50 — Build versus buy
- 10:10 — One thing to check this week
What this episode claims
- The characteristic automation failure isn't dramatic — a token expires, an API returns errors, and the flow just stops doing one step, silently.
- A run log that's 100% successful reads as fake, or as a system nobody has actually used.
- Past about five steps, a run log and visible retries pay for themselves the first time something breaks.
Read the full written version: /insights/automation-you-can-actually-inspect
Full transcript
A: Automation sells a feeling — the moment work happens without you. And that feeling's also the risk, because the same property that makes it valuable is exactly what makes a failure invisible.
B: The characteristic failure isn't dramatic, either. A token expires. A field name changes upstream. An API starts returning errors. The flow doesn't crash loudly — it just stops doing one step.
A: And nobody notices for a week, until someone asks why forty customers never got a follow-up.
B: So the first thing worth building isn't more steps. It's the ability to see what the steps did.
A: There's a counterintuitive move here, too — deliberately showing a bad run. In the demonstrator this is drawn from, there's a failed run in the history on purpose, with a retry note, an integration flagged in an honest "needs attention" state.
B: Because a run log that's a hundred percent green reads as fake. Or as a system nobody's actually used.
A: Real systems have bad days. Showing one, with the recovery visible, tells you something a wall of green checkmarks can't — that failure is handled, not hidden.
B: So what does inspectable actually mean, concretely? Four things, in the order you'd add them.
A: A run log with per-step outcomes — which node ran, what it got, what it returned, how long it took. That's the difference between a five-minute fix and an afternoon of guessing.
B: Visible retries — a silent retry teaches you nothing. Three attempts every day this week is a signal about an upstream system, and it needs to be legible.
A: Failure that actually surfaces, through something a human reads. An automation that fails quietly is worse than one that never existed — you've stopped doing the manual version and gained nothing.
B: And a state you can reason about. If a flow half-completes, what happened? Did the email send but the record not update? That's a design decision to make deliberately, not something you discover during an incident.
A: On build versus buy, briefly — because it comes up constantly. Use an existing tool when the flow's a standard shape and volumes are modest. Don't pay anyone to reproduce Zapier.
B: Build custom when the logic branches on your own rules, or you need telemetry the tool won't give you. Most real projects end up a mix — purity's not a virtue here.
A: One honest limit — observability costs build time. On a two-step flow, all of this is over-engineering. Past about five steps, it pays for itself the first time something breaks.
B: One thing to check this week.
A: Pick one automation you already run. Can you say what it did, specifically, the last time it ran? If the honest answer is "no idea," that's where to start — before adding the next step.
B: Written version's at atinnovators.in, under insights.