About
I automated my own job first.
I was hired into the operations side of a freight brokerage, the tedious end: posting loads, watching deadlines, chasing carriers for updates. On my first day I watched the posting workflow run through an Excel macro that would occasionally turn a weight of 2500 into the date November 4, 1906, on a live load board. I have an IT background, and it did not take long to see that most of the work was rules, and rules can be built.
So I started automating the job instead of just doing it. Day one, the macro was replaced with deterministic code. Thirty-three days and 150 commits later, it had grown into a platform three operators use concurrently: two email bots, four API integrations, three unattended crons, all of it running on live commercial data.
I am not a broker, and I am not a software vendor. I work in operations, I have an IT background, and I built all of this with AI coding agents, with every risky decision kept deterministic and human-gated. Knowing exactly where that line belongs is the craft.
Freight is where I proved the approach. The approach itself, a deterministic core with AI boxed into read-only jobs and shadow mode before trust, applies to any operations-heavy back office. That is the business I am building: the automation, not the freight.
How I work
Seven rules, learned on live data
These recur through every build. They are the difference between automation you demo and automation you trust with real operations.
01One-way doors get double guards
If a write cannot be undone, the state that justifies it is re-read immediately before executing. Date changes read back after writing. The one race that genuinely cannot be closed is documented, not hidden.
02The AI is boxed in
Claude reads; it never writes. Every dollar figure originates in a pure deterministic module; every routing decision is code. If the model hallucinates, the blast radius is a mislabeled reading, never a wrong price on the wire.
03Automation only narrows
Sweeps close records down, never re-open them. Automated writes fire only into empty fields. A human's decision is never overwritten by a robot's. Widening is a human act.
04Shadow first, with independent kill switches
Every bot launched writing drafts, not sending. Three bots, three separate mode switches, all defaulting to off. One v1 refuses "live" in code even though the database schema would allow it.
05Design around serverless physics
Function ceilings, API rate limits, and cold starts are load-bearing constraints. Small batches, internal time budgets, pacing delays, idempotent writes, so an interrupted run resumes instead of duplicating.
06Cost scales to zero
Business-hours gates and mode gates live inside the cron handlers. An off-hours tick returns before touching anything. A dormant bot costs nothing.
07Hard-won facts get written down where the code is
Timezone re-labeling, clipboard formats, a compiler quirk tests cannot catch, a matching trap. Each one documented at the point of use, so no future session pays for it twice.
The first conversation is free and useful.
Bring the workflow that eats the most time. I will tell you which parts are buildable and which parts I would keep human, and you keep that answer either way.