The approach

Map it. Build one. Hand it over. Leave.

Same four phases every time. The only thing that changes is which workflow survives week one.

  1. 1MapWeek 1
  2. 2BuildWeeks 2–5
  3. 3Hand overWeek 6
  4. 4Check inDay 30
01

Map

Week 1

I sit with the people doing the work and write down every hand-off. What gets retyped, what gets chased, what gets forgotten. You get a scored list of candidates, and the ones I’d leave alone.

  • Workflow map
  • Scored candidate list
  • A written no-go list
02

Build

Weeks 2–5

One workflow. Into your stack, not a sandbox. Evals before features: I need to prove it behaves before anyone trusts it with a customer.

  • Working workflow in production
  • Eval suite
  • Failure-mode notes
03

Hand over

Week 6

A runbook a non-engineer can follow, a walkthrough with whoever owns it, and the keys. No dependency on me, by design.

  • Runbook
  • Ownership walkthrough
  • Access transfer
04

Check in

Day 30

One hour, thirty days later. What drifted, what the team worked around, what earned the next build.

  • Drift review
  • Next-workflow recommendation
What I hold to

Four rules I won’t trade away.

Evals before features

If I can’t measure it behaving, it doesn’t go near a customer.

One workflow at a time

A portfolio of half-built agents is worse than one that runs.

Handover is the deliverable

The build isn’t done until someone on your team can run it without me.

Boring beats clever

Most of the value is in plumbing nobody wants to demo.

One client at a time.That’s why the slot list is short. If the timing is wrong, I’ll tell you when it isn’t.

Bring me the workflow that keeps breaking.

Forty-five minutes, no deck. If there’s nothing worth automating, I’ll say so.

Book a working session