Notes from the AI Gatherings, Vol. 1
A format note, since this is the first one. Most Friday mornings I meet a few friends at Switchyards in Nashville to compare notes on building with AI. No agenda, no demos-or-else, no recording - just a couple of hours of “here’s what I tried, here’s what surprised me.” It’s become the most useful standing appointment on my calendar, because the things you learn tool-to-tool never make it into anyone’s launch post. One of those mornings already sent me home to rebuild my entire engineering workflow . This series is my notebook from those mornings - short, occasional, and anonymized. The rule is simple: I write about my own work by name, everyone else’s not at all. What you get is the patterns.
Three things from this week’s table.
Seven hundred calls to the machine in the other room
I brought a story about a dataset I’ve carried around for twenty years - a running list of movies I’d seen, with names and places and half-sentences scribbled into it, no structure at all. I asked a frontier model to dig through it and surface something worth charting. It tried, honorably, with regular expressions and heuristics, and produced a CSV that was mush. The material was too irregular for any one clever pass.
The fix was to stop asking for cleverness and start asking for patience. We looped over the list one row at a time and sent each row to the local model running on my Mac Studio with one tight instruction: extract the entities in this row, return them structured. About seven hundred calls later - maybe forty-five minutes of a fan spinning - the whole mess was clean, structured data. No meter running, nothing leaving the house.
The pattern, which I keep re-learning: frontier models for judgment, local models for volume. A tightly bound task, repeated hundreds or thousands of times, on private material, with nobody waiting on the answer - that’s the local machine’s home turf. The row-by-row loop felt embarrassingly dumb while I was writing it. It was also the thing that worked.
The two economies of tokens
The table’s longest-running argument is about what any of this actually costs, and this week it sharpened into a frame I like: there are two token economies, and most of us only ever live in one.
The subscription economy is where individual builders live - a flat monthly fee, usage limits, and the quiet fact that the light users subsidize the heavy ones. Then there’s the API economy, where enterprises pay by the token and the meter is always visible. People building serious agentic workflows at work watch a single job cost real money and design accordingly: which model, which effort level, which search provider, per call. Subscription people like me mostly discover those dials later, when the weekly limit arrives early.
Two lessons crossed the table that I’ve now verified in my own work. First: the more capable model can be the cheaper one. If the smaller model takes you down three confident wrong paths at two days each, the premium model that gets it right the first time was the budget option all along. Token efficiency is measured at the level of the outcome, not the call. Second: effort settings are a real dial, not a placebo - higher effort can finish in fewer total tokens because the model stops thrashing. Both are invisible until someone across the table says them out loud, which is the whole reason the gathering exists.
I checked my own meter afterward: the usage tracker I run estimates that my flat subscription did the API-equivalent of several thousand dollars of work this month. The two economies aren’t close.
Build the tool before the feature
Third pattern, from my own bench. I build a small desktop app for myself that keeps a private record of my working day. I wanted to add an “ask” feature - type a question, have a model answer from the app’s own database.
The path that worked was backwards from how I’d have planned it. First I built the app an MCP server - a handful of tools, each mapping roughly onto a table in its database - so my everyday AI assistant could query the app from the outside. I lived with that for a while. The tools got exercised, the rough edges got obvious, the useful queries revealed themselves. Only then did we embed a small open-weight model directly into the app and wire it to the same tools. By that point the integration was almost boring - the hard thinking had already happened in the rehearsal space.
MCP-first, embed-later. The protocol layer turns out to be a cheap way to prototype an in-app AI feature before you commit to shipping one - you find out what the model actually needs from your data while the stakes are still zero.
That’s Vol. 1. If the format earns its keep, there will be more - same rules: short, warm, my own work by name, everyone else’s as patterns. If you’re in Nashville on a Friday morning and this sounds like your kind of table, find me and ask.