Tag

series

Automation series #10: The Automation Architecture Worksheet

The point of automation architecture is not to produce diagrams. The point is to make better decisions before the workflow is in production, touching customers, writing to systems, and creating trust problems. Use this worksheet before building or expanding an AI automation workflow. It is deliberately practical. If a team

Automation series #9: Failure Modes, Security, and Blast Radius

Failures will happen. The useful question is not whether you can prevent every failure. You cannot. The useful question is how much damage a failure can do, how quickly you can detect it, and how cleanly you can recover. That is blast radius. AI automation makes blast radius more important

Automation series #7: Observability, Auditability, and Replay

If you cannot explain what your automation did, you do not have automation. You have a liability. This becomes painfully obvious after the first failure. A customer received the wrong email. A ticket was routed to the wrong team. A contract field was extracted incorrectly. A workflow retried an action

Automation series #6: State, Idempotency, Retries, and Queues

The least glamorous parts of automation are usually the parts that decide whether it works. State. Idempotency. Dedupe. Retries. Queues. Exception paths. These are not backend trivia. They are the difference between a system that can be trusted and a system that occasionally does something weird and nobody knows why.

Automation series #5: Human-in-the-Loop Is a Design Pattern, Not a Failure

Teams often treat human review as an admission that automation did not work. That is backwards. Human review is how you make automation safe enough for consequential work. It lets the system move fast on routine cases, slow down on risky cases, and learn from the edge cases that would

Automation series #4: The Automation Boundary: Code vs Model vs Human

Every automation has a boundary problem. What should code decide? What should a model decide? What should a human decide? If you do not answer that explicitly, the boundary gets decided accidentally. Usually by whoever wrote the first prompt, connected the first API, or approved the first demo. That is

Automation series #2: Deterministic Workflows: When Reliability Matters More Than Intelligence

Some automation should not be intelligent. It should be boring. It should do the same thing every time, for the same reason, with logs you can understand and tests you can run. This is not less advanced. It is the foundation that lets judgment-heavy steps stay controlled. A deterministic workflow

Automation series #1: Automation Is Not One Thing

The fastest way to build bad automation is to treat automation as one category. It is not. A script that syncs invoices is not the same thing as an AI agent that reviews contracts. A rule that routes support tickets is not the same thing as a model that summarizes
You've successfully subscribed to Antoine Buteau
Great! Next, complete checkout to get full access to all premium content.
Welcome back! You've successfully signed in.
Unable to sign you in. Please try again.
Success! Your account is fully activated, you now have access to all content.
Error! Stripe checkout failed.
Success! Your billing info is updated.
Error! Billing info update failed.