The demo always works. The email gets classified, the invoice gets extracted, the record gets updated, the room nods. Then production arrives with its malformed PDFs, its API outages at 2 a.m., its edge cases nobody mentioned because nobody remembered them. The automations that survive share structural patterns — and they're decided at design time, not patched in later.
1. Idempotency, or the retry that doesn't double-pay
Every step must be safe to run twice, because in production it eventually will be. Networks fail mid-operation; queues redeliver. If your automation creates an invoice, a retry must recognize the invoice already exists rather than filing it again. This is a one-line design decision early and an archaeology project later.
2. The dead-letter queue with a human face
Some fraction of items will always defeat the automation. The pattern that works: a dead-letter queue that routes failures to a person with full context — what was attempted, what failed, one click to resolve or retry. The anti-pattern: silent failure, discovered weeks later as an accounting discrepancy with a story nobody can reconstruct.
3. Confidence thresholds instead of binary automation
AI-driven steps produce confidence signals — use them. High-confidence items flow straight through; borderline ones route to review; the threshold moves as evidence accumulates. Teams that treat automation as all-or-nothing either drown reviewers or ship errors. The threshold is a dial, and owning that dial is owning the risk.
4. Shadow mode before authority
New automation runs alongside the human process first — acting on nothing, logging what it would have done. The comparison report, on your real traffic, is what earns it write access. This costs a few weeks of patience and prevents the far more expensive discovery that your training assumptions and your production reality disagree.
5. The audit log you'll want during the incident
Every action recorded: what triggered it, what data it saw, what it decided, what it changed, and how to reverse it. Not because regulators demand it (though they may) but because the first serious incident review will either take twenty minutes with a good log or two days without one.
None of these patterns require exotic tooling. They require deciding, before the first line of code, that production — not the demo — is the design target.