# How I build automation

Brian Parisien · Nov 7, 2026
**As AI makes building easier, the harder question is who can manage the build, the delivery and the promise of an automation.** I give the planning and safeguards as much attention as the build, so the automation does what it promised. This page is how I plan to build and manage automation for any team. It follows five steps, and each step names the risk it exists to limit.

## The five steps at a glance

| Step | What I do | What it protects against |
| --- | --- | --- |
| 1. Decide what to automate | Find the work worth automating, and where AI belongs | Automating the wrong thing |
| 2. Plan | Write the charter, lock the scope, set the guardrails | Runaway scope and cost, and no way back |
| 3. Manage the build | Direct the AI agents doing the build, and approve every change | AI work nobody reviewed |
| 4. Test and soft-launch | Freeze the tests first, then launch with a person approving | A poor result reaching customers |
| 5. Learn, launch and monitor | Feed real results back, launch, hand over, keep watching | Quiet decay after launch |

## Step 1: Decide what to automate

**Find what's worth automating. Observe how the business actually runs: interviews and shadowing first, then process and task mining to verify it. Score each step by volume, handling time, error cost and security risk to find the highest-leverage automations. Decide where AI belongs and where a fixed rule is enough.**

In practice that is six moves.

1. **Frame it.** Ask the owner what hurts most and what success means: hours saved, cost cut, fewer errors, less risk. Agree which area to study and what data I may see.
2. **List the candidates.** Name the repeatable jobs. Favor high-volume, rule-based work, and ask the people doing it what they dread.
3. **Observe the real work.** Interview the people who do it, not only their managers, and shadow them. Watch for workarounds such as spreadsheets, copy-paste and phone calls. Ask what happens when something goes wrong.
4. **Baseline each step.** Measure volume, time per item and error rate, and what an error costs. Use system reports where they exist and sampling where they don't. Process mining (system logs) and task mining (screen activity) confirm what people tell me.
5. **Score and sort.** Rate each step on return, error cost, security and data sensitivity, how clear the rules are, and how much judgment it needs. Sort into four piles: automate with fixed rules, use AI, keep a person, or don't automate.
6. **Agree the shortlist.** Present the few best targets and the "don't automate" list. Sign-off feeds the charter.

**Check whether anyone would miss it.** For each component, I name what the business would lose if it were switched off, and how fast the loss would show. Only a fast, measurable loss earns the word essential.

**Protects against: automating the wrong thing.**

## Step 2: Plan

**Write the charter, lock the scope and set the guardrails.**

- **The charter is the source of truth.** It holds the objective, the scope, each design decision with its reasoning and date, and success criteria set as numbers before anything is tested. A replaced decision stays in the log and names its replacement.
- **A table of built, designed only and declined.** Every capability is labeled with its reason. Designed only means planned and written down, but not built.
- **Settle the unknowns first.** Before a build I write down where it must end up, the decisions so far, the open questions and what is out of scope. Eight standing questions each get a recorded answer: error handling, security, privacy, access-key expiry, rate limits, choice of AI model, data ownership and platform rules.
- **Map, then backlog, one direction only.** I edit the charter first, then redraw the process map, then write the tickets. Each ticket has finish conditions that its own work can check, and dependencies are explicit blockers. Only I mark work done.
- **Guardrails.** Human and security gates, a hard cost budget and a rollback plan are set before building.
- **Change control.** A design change goes back to the charter first, never straight to the map or the backlog.

**Protects against: runaway scope and cost, and no way back.**

## Step 3: Manage the build

**Direct the AI agents doing the build, and approve every change.**

AI agents can do much of the drafting, building and checking, so I set one up the way I would onboard a contractor: a written role, a shared record it reads before acting, a rulebook, packaged procedures, and access to the real tools with limits on what it may change.

| The agent does this without asking | The agent proposes, I approve | Only I do this |
| --- | --- | --- |
| Read the record, the charter and the backlog | A new working rule | Mark any ticket done |
| Draft documents, prompts and test cases | A new ticket | Make a design decision in the charter |
| Build in a test copy | Changes to its standing instructions | Accept a test result as a pass |
| Move a ticket to in progress or testing, and comment | Any cleanup of the backlog | Decide what is published |

- **New work starts in a test copy.** The live version changes only after testing.
- **AI where judgment is needed, fixed rules everywhere else.** AI calls return structured data in a fixed format.
- **Limits are set by what each step can touch.** An approval click proves someone was present, not that they read the item, so the real limits are access rights: no delete rights on business data, and lookups that return only the fields a step needs.
- **Review depth follows the cost of a miss.** After three review rounds on the same thing, the agent proposes a rethink instead of a fourth round.
- **Claims are checked first.** The agent compares each capability claim with the charter's built, designed only and declined list, and I review that check before anything is published.
- **I record every decision,** so the project's reasoning can be read later.

**Protects against: AI work nobody reviewed.**

## Step 4: Test and soft-launch

**Freeze the test sets and pass rules before the first scored run.**

- **Expected answers are locked first.** Scoring happens outside the build session. Nothing built in a session is scored, passed or marked verified in that same session.
- **A pass covers only the version scored.** A prompt or model change means a rerun, and a claimed improvement must hold on cases that were not used to tune it and be larger than the normal variation between runs.
- **Regression checks after every model change.** A cheaper model can match a stronger one on the test set and still miss the cases that matter most, so I rerun the hard cases before accepting a swap.
- **Try to break it.** I send bad, missing and forged inputs on purpose and log each failure with its symptom and fix.
- **Keep the evidence.** Every raw AI test result is saved in two places before scoring, none is deleted, and saved records are locked against edits.
- **Soft-launch with a person approving every output** until the results hold. Then the tested version replaces the live one, scrubbed of web addresses and IDs.

**Protects against: a poor result reaching customers.**

## Step 5: Learn, launch and monitor

**Feed real-world results back into the build, then launch officially.**

- **Real feedback goes back through the tests.** Updates are scored the same way as the first build.
- **Launch when the results hold,** not on a date.
- **Hand over a record a maintainer can use.** A technical as-built record shows how the system is wired today, read from the live build rather than the plan. It walks one request from first message to a person, lists where people decide, sets out what happens when a step fails, and lists where the build differs from the charter. I test it by having someone who did not write it read it cold and explain the system back.
- **Monitor quality, drift and cost after launch.** Measure real usage against the budget, and fix the cause when it overruns.
- **Plan the closeout like any other work:** an as-built record, a retrospective and a decommission, each its own ticket with finish conditions.
- **Drop a claim rather than defend it** when checking shows it does not hold.

**Protects against: quiet decay after launch.**

## See it applied

The [case study](/case-studies/apex-climate-solutions) applies these steps end to end.