I build AI into the workflows we already use, and test them myself.
Eight years at GLG, most recently running a $14M+ enterprise book as the AI person on a non-AI team, and five builds with dated evals on every one.
In plain terms:
A rep's sixty-second voice note becomes a CRM record, with the open questions flagged.
The transcript is checked against the 19 requirement cards for that kind of business, each card comes back confirmed, inferred or not discussed, and nothing is written to the CRM until a person approves it, at $0.0313 for the extraction and $0.0561 for the step that proposes the update.
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.
I hid sneaky instructions in the notes to see if I could trick it, and it held steady most of the time and 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: RAG is how the answers get found, by looking up the right days before writing a reply, and MCP is a standard plug that lets an AI assistant like Claude use that lookup as one of its own tools, so I can ask my daily data questions from inside Claude instead of a separate app.
It tells a support agent the next step while the chat is still going, and every step it names has to be in the written guideline or it gets rejected.
In plain terms: it works like a colleague reading over a support agent's shoulder who has memorized the rulebook and whispers the next step, and then checks the finished conversation for steps that were skipped or done wrong.
In plain terms: both numbers count how often it suggested the step the agent actually took next, the first over 100 recorded chats and the second running silently next to the agent on 50 of them, which means an agent would set aside about one suggestion in five, and I'd pull it back if agreement stayed below 75% for two weeks on a customer's own traffic, or if a suggestion took longer than 4 s to arrive at p95.
Sonnet 5 with the whole guideline library in a cached prompt, 349 agent actions in 100 frozen test chats and 176 in a 50-chat subset for shadow, 24 September 2026, level with a no-model guideline-order baseline at 73.4%. ABCD is chats for a fictional retailer role-played by trained crowdworkers, real conversations between people with no real customers, MIT licence, Copyright (c) 2021 ASAPP Research. Replay six chats and the QA →Card matching, tuned against prompted, on the same golden set.
Every build on this page runs on a prompted Haiku or Sonnet, under a schema or a tolerant parser, and the next build tunes a small model on card matching, the one task here that is a closed classification, and the result goes on this page even if it says to keep prompting.
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 account documents go in and a read you can act on comes out.
Haiku 4.5 summarizes each document and Sonnet 4.6 synthesizes, which cut the main call from 22,976 to at most 1,012 input tokens on two long transcripts, and each section of the brief is asked to name its sources, which it did for 92% of the required ones across 260 eval runs.
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.
When a customer sounds unhappy but nothing specific went wrong, it reads the risk right in only seven of twenty runs.
arm A, with the weighting block, 20 runs · which runs is laid out for the mockIt is good at spotting trouble tied to something that happened and still weak at reading a vague mood with nothing behind it, and the source-weighting block that fixes the buyer makes this case worse, 7 of 20 with it against 14 of 20 without, which is why that number is on the page.
One long voice note comes back as a short list to do first, one task at a time, and a list that can wait.
You say how much you have, plenty, a little or none, and whether you are feeling anxious, and the sorter puts every item into now, later or let go under a strict JSON contract, with now capped by that level and each step saying why it was picked, in the dump's own words when it can.
In plain terms: you dump everything on your mind, say how much energy you have, and it hands back up to three things to do first, one at a time, a safe list for later, and the worries you can set down.
In plain terms: I changed the instructions and how hard the model thinks, without retraining the model itself.
The analysis work
In plain terms: dbt is a tool for turning raw data into clean, tested tables with plain SQL, and this map shows Instacart's raw order data moving through five cleanup steps and one join into the three tables the analysis reads from, with 34 automatic checks on the way, which matters because the 0.60 reorder rate everyone cites got checked against the data before anything was modeled on it.
The 0.60 reorder rate everyone cites hides two groups, new customers at 0.221 and regulars at 0.670.
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 drift 2.1 points worse between their first inspection and their fifteenth.
the ends, 90.5 and 92.6, are printed in the notebook · the points between are read off its chartIn plain terms: the more times a restaurant gets inspected the slightly worse it tends to do, so getting flagged does not seem to make places clean up, though only the places still open for a fifteenth visit are counted at the end. The data came from the City of Austin's open data portal, which runs on Socrata, and the Socrata API is the way to pull those public records straight into code without downloading spreadsheets by hand.
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.