# Brian Parisien

> The hardest call in AI automation is what not to automate.

AI where a step needs judgment. Fixed rules everywhere else. A human signing off where a mistake would be costly and irreversible.

That's how I plan, build and govern automation, backed by eleven years managing projects and leading Agile teams.

## About

- My foundation: Eleven years of managing projects and leading cross-functional Agile teams of up to 17 in a global enterprise.
- My edge: Fifteen years as a web designer, with an eye for intuitive interfaces and user-centered design (UI and UX).
- My focus: Owning the full AI automation lifecycle, from finding what's worth automating to governing it after launch.
- Location:
  - Canadian citizen based in Panama City, Panama
  - Remote: Contractor (W-8BEN) or employer of record (EOR)
  - Flexible hours: UK to US West Coast

## How I build automation

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.

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.
2. Plan: Write the charter, lock the scope and set the guardrails. Confirm where AI is used. Set the human and security gates, a hard cost budget and a rollback plan before building.
3. Manage the build: Direct the AI agents doing the build, and approve every change. Record every decision, and score the result in a separate session from the one that built it.
4. Test and soft-launch: Freeze the test sets and pass rules before the first scored run. Run the evals, then soft-launch with a person approving every output until the results hold.
5. Learn, launch and monitor: Feed real-world results back into the build, then launch officially. Hand over the documentation and monitor quality, drift and cost after launch.

[Read the full method](https://portfolio-brianparisien.vercel.app/how-i-build/index.md)

## Roles where my experience and knowledge excel

Each entry below gives the role's key question, why I fit, and the case study steps to read first.

- AI Agent Manager / AI Ops: Will the agent's answers slip when nobody is watching? Why I fit: eleven years running project delivery, now applied to testing and supervising AI steps. Read: Tests first; Break it; Cost page.
- AI Project / Program Manager: Will the rollout stall, with blockers found too late? Why I fit: eleven years as a project manager and Scrum Master: planning, tracking and unblocking work as it goes. Read: Record; How I build; Cost page.
- AI Product Manager: Will features ship with no proof they work? Why I fit: fifteen years designing web products and eleven delivering them, deciding what to build and what to leave out. Read: Decisions; Tests first; Build.
- AI Automation Specialist: Will an automation break with nobody noticing? Why I fit: built Apex's 27 Make.com workflows, with an as-built record a maintainer can follow. Read: Break it; Build; As-built.

## Case study

- [Apex Climate Solutions: automating intake and operations for a heating and cooling company](https://portfolio-brianparisien.vercel.app/case-studies/apex-climate-solutions/index.md): Apex is a system of 27 Make.com workflows for a small heating and cooling (HVAC) shop: it triages the requests the shop receives, answers technicians' questions from the company's own manuals, and flags jobs, stock and permits before they slip. It shows where AI belongs in that work and where a person decides. I built it on Make.com, Neon databases and Slack, with eight AI steps: three of them, the urgency rater, the junk filter and the technician answer step, went through formal evals (scored against fixed test sets), and the other five sit behind a fixed check or a person's review.

Designed and built August to early November 2026 · Published November 2026
A portfolio demonstration, not a product I maintain. Apex is a simulated company, every test message was written for the test, and no live customer traffic has run through it. Figures are as of the publish date.

- Time freed: 30 hrs/month, staff hours freed for a five-technician shop (modeled)
- Saved: $12,420/year, saved after paying its own running cost (modeled)
- Cost to run: $59 to $121/month, for a five-technician shop (estimate)

- Problem: Requests arrive by phone, web form and WhatsApp. A person reads each one, filters out the spam and creates the job by hand, so a no-heat emergency can sit behind a routine maintenance request. Answer: Intake and triage gathers requests from WhatsApp, a web form and an AI voice agent, filters out spam, rates urgency and creates the job. It posts to Slack, where a person does the final triage.
- Problem: Refrigerant procedures, city permit rules and warranty terms live in people’s heads. Technicians phone the office or guess. Answer: The knowledge base answers technicians’ questions in Slack from the company’s own manuals and documents, citing the source, so they stop guessing or phoning the office.
- Problem: Overdue jobs, empty truck stock and permits stuck in pending come to light only after they cost a job, when it is too late to fix. Answer: The watchdog and review monitor flags overdue jobs, low truck stock and stalled permits, and drafts replies to customer reviews for a person to approve.

## Results

- Time freed: 30 hrs /month staff hours freed for a five-technician shop (modeled)
- Saved: $12,420 /year saved after paying its own running cost (modeled)
- Cost to run: $59 to $121 /month for a five-technician shop (estimate)

## The seven steps

1. Brief and constraint: A small HVAC shop loses time in three places: sorting incoming requests by hand, technicians hunting for answers, and problems noticed only after they cost a job.
2. Map: Three components share three Neon databases and one Slack workspace: intake and triage, technician answers, and an operations watchdog.
3. Decisions: I made each choice against a named alternative, for a stated reason.
4. Tests first: I designed the tests before building: 30 test cases, ten for each component, written with their expected results before any component existed. Writing them exposed three gaps in the design, which I fixed before the build. Three AI steps, the urgency rater, the junk filter and the technician answer step, then went through formal evals, with each pass rule set before the first scored run. Each eval refined the step's prompt, settled its model, or both.
5. Build: Each AI step has a stated job and a set path when the call fails; all but part lookup have a check after it.
6. Break it: Most failures take a safe default or reach a person in Slack; the few that don't are named as accepted limits in the technical as-built.
7. Record: I kept two records. Design decisions went into the charter's dated decision log with the reasoning at the time; where a setting's date or reason was never recorded, the record says so rather than filling it in afterwards. From mid-September, every open item went into a Jira backlog with a definition of done: what had to be true to close it.

## Project documents

- [Project charter](https://portfolio-brianparisien.vercel.app/docs/charter/index.md)
- [Cost page](https://portfolio-brianparisien.vercel.app/docs/cost/index.md)
- [How the AI steps were tested](https://portfolio-brianparisien.vercel.app/docs/evals/index.md)
- [Technical as-built](https://portfolio-brianparisien.vercel.app/docs/as-built/index.md)

## Guidance

- [Design guidance](https://portfolio-brianparisien.vercel.app/design.md)

## Contact

- Resume: https://portfolio-brianparisien.vercel.app/Brian-Parisien-Resume.pdf
- LinkedIn: https://www.linkedin.com/in/brian-parisien-b1552991
- Email: brianparisien@gmail.com
- Privacy policy: https://portfolio-brianparisien.vercel.app/privacy