I build AI into the workflows customers already run, and I publish how often it breaks.
Eight years running a $14M+ enterprise book at GLG, where I was the AI person on a non-AI team, and four builds with dated evals on every one, so the log on the right is the last run.
In plain terms:
Sixty seconds in the car becomes a record onboarding can open.
A rep talks into their phone in a parking lot, and onboarding gets a record with the unanswered questions named on it.
In plain terms: a salesperson rambles into their phone after a visit, and the tool pulls out what matters, flags what nobody asked about, and waits for a person to okay it before anything touches the sales system.
The sentence that decides the go-live date is the last one, after the tacos.
Ten planted instructions, five runs each, forty of fifty unchanged.
In plain terms: I hid sneaky instructions in the notes to see if I could trick it, and it held steady most of the time but slipped often enough that a person still approves every change.
Ask it a question in plain language, and every day it cites is checked before you see the answer.
In plain terms: it works like a search engine for my own daily log that has to show which days the answer came from, and it double-checks those days are real before it answers.
In plain terms: this lets Claude on my laptop ask the same questions directly, and my data never gets uploaded anywhere.
Card matching, tuned against prompted, on the same golden set.
Every model call on this page is a prompted Haiku or Sonnet under a schema, and the next build is a small tuned model on the one task that is a closed classification, which may end with keep prompting, and that goes here either way.
In plain terms: I am testing whether training a small model on one narrow job beats just asking a big model well, and if it does not, I will say so here.
Messy documents go in and a read you can act on comes out.
Haiku summarizes each document and Sonnet synthesizes, which cut the main call from roughly 23k to about 1k input tokens, and every section of the brief names its sources.
In plain terms: you drop in a pile of messy account notes and get back a short read on whether the customer is at risk, who actually matters, and the one thing to do today.
A mood with no event behind it is read right in seven of twenty.
ablation, 20 runs per arm · which runs is laid out for the mockIn plain terms: it is good at spotting trouble tied to something that happened and still weak at reading a vague mood with nothing behind it, which is why that number is on the page.
Five minutes in, four piles out.
The system prompt is assembled from the energy state you pick, and the model sorts every item into one of four buckets under a strict JSON contract, so change the state and watch the same dump re-sort.
In plain terms: you dump everything on your mind, say how you are feeling, and it sorts the pile into what to do today, what can wait, what to keep, and what to let go.
highlighted as the model reads it, one bucket per item, strict JSON
The analysis work
In plain terms: raw grocery orders go in on the left, get cleaned and joined in steps, and come out on the right as tidy tables, with 35 automatic checks making sure nothing broke along the way.
I rebuilt one cited number until it split in half.
New shoppers reorder at 0.221 and veterans at 0.670, so the 0.60 everyone cites describes neither, and a random forest at 0.9886 AUC for veterans against 0.8566 for new users confirmed the split was real.
In plain terms: people who are new to the app rarely buy the same thing twice and regulars almost always do, so the one average everyone quotes is really two very different groups mashed together and it fits neither of them.
See the models ↗Venues score about two points higher by their fifteenth inspection than at their first.
In plain terms: restaurants tend to score a little better the more times they get inspected, though the places still open for a fifteenth visit may just be the ones that were already doing fine.
See the findings ↗Experience
In plain terms: I spent eight years running big customer accounts and then the teams that run them, which is where I learned what customers actually need before I started building for them.