A working timeline of talks, writings, and builds — the long arc into AI from inside the broker workflow. Successes, “failures,” and the lessons that came from both.
The current talk: an honest look at the three frames in circulation for what AI means for the working broker — and why holding all three at once is the only frame that holds up.
The essay version. Three frames brokers use to make sense of AI in their workflow, and why the only honest position is to hold all three at once.
This site. Vanilla HTML, no framework, deployed as a Replit static site — shipped in fourteen days from blank file to live deployment, vibe-coded with Claude. A receipt for the “build with AI every day” claim on the home page.
A microservice problem with no margin for error: scan any input for personally identifiable health information, flag it, remove it. Mistakes have HIPAA consequences. This is the project where I stopped using one AI and started using a chain of them — one to investigate the problem space, one for the research, another to build, another to test — with the explicit recognition that each model has different strengths and that prompting style matters as much as model choice. Layering is now my default approach for high-stakes builds. The open research question is whether the strengths are real (different training data, different architectures) or stylistic (different prompting habits work better on different models). I haven’t investigated. I’d like to.
A leadership meeting surfaced a constraint: a recurring regulatory reporting workload was about to take longer than usual because of resource allocation across priorities. Vendor tooling existed but procurement would not move at the speed the problem deserved. So we built. Two weeks from leadership-meeting-comment to working tool, layered AI across the work, the team validated outputs end-to-end. The piece that mattered most for the long arc was the security review: I produced architecture schematics for the AI components, ran a small penetration test, and walked it through the enterprise IT security team’s validation. It passed.
Two lessons sit underneath this one. First, the obvious one: most internal “we can’t do AI tooling here” conversations aren’t actually about AI. They’re about whether the security and governance work can move. It can. The path is documentable.
Second, the strategy lesson I’m still articulating: I spent two decades as a Product Manager building monoliths — consolidating capability into one large platform that did everything. AI changes the math. I can now build narrow tools that operate for the moment, in the moment, on the need, and meet the need when it is needed. The default architecture is shifting from one big system to many small ones. We hadn’t done it that way before. It is paying off.
A few weeks into the desktop chapter I picked up Apple Shortcuts as a way to make Siri actually useful inside the work I do — voice-activated lookups against my own infrastructure, everything processed on the phone, Apple privacy guarantees intact. To wire it up I needed to expose services running on my Mac to the public internet, securely. AI taught me Cloudflare. I built my first tunnel back to my own machine and hosted a working endpoint from a desk in my home office — a thing I’d worked around for two decades because I’d never been the person who knew how to set it up. The James-Bond feeling of asking Siri a question and watching my own desktop answer was the surface. Underneath: I now have the operator layer I’d outsourced to vendors and IT for my whole career.
The bet — a tool to combine multiple data sources into a coherent record per person, the kind of cross-source matching that’s expensive when humans do it and almost trivial when AI does, once the data is in front of the model.
The reality — a regulatory ceiling. The compliance work — what HIPAA actually requires versus what a careful Product Manager thinks it requires — became its own multi-week investigation. The technical detail mattered: you can run a HIPAA-compliant front-end on AWS or Google Cloud, but the surface for misconfiguration is large enough that one wrong setting leaks every record. With thousands of records per ingestion, the liability math is unforgiving.
The lesson — the structural insight was distribution, not architecture. Keep the AI processing client-side. Package the app as a desktop application. Call out to the cloud only for updates and shared logic. The data never leaves the user’s machine. The bigger lesson, the one I’m still processing: I’d spent twenty years defaulting to web apps because that’s what Product Managers did. The senior question is why we ever defaulted to that. Sometimes the right distribution model is the one we abandoned.
Started a project I won’t name here. The point isn’t the project — it’s the platform shift. I’d been building inside Replit for eighteen months. This was the day I left the browser and started writing Python on my own machine. First long sessions in Terminal — a window I’d previously never had open for more than a minute, now ever-present. The cadence changed again. Replit had taught me to ship at the speed of an iterating cloud IDE. Desktop development taught me to ship at the speed of my own infrastructure. The motivation was simple: the June talk was coming, and I wanted to see what I could build between this day and then that might be worth walking an audience through.
A proof of concept: could AI take a site built on an older CMS and rebuild it as a custom solution with ninety-nine percent style, layout, and function fidelity? It could. It did. The work I’d been treating as a six-month engineering project for the older sites I still own collapses into a weekend. The bigger question this opens for the industry — every “legacy CMS migration” line item in every IT budget — is one I’m sitting with.
A predecessor to this site. Built to accompany an AI talk — the same companion-app pattern that started in 2023, refined. The principle is consistent: don’t describe the AI work. Demonstrate it live.
A site for a CEO friend. The brief was curated — old-money aesthetic, considered selections, weighted-scroll feel, clean white space — a far cry from the wholesale UI work I’d defaulted to for years. The design lesson was real: imagery matters but flow and story matter more, especially for a reader you can’t assume context from. The deeper lesson was structural. Amazon’s referral program has rules with the same shape as HIPAA — specific, unforgiving, expensive to violate — that hard-capped how much of the workflow I could automate. The CEO wanted authentic, not algorithmic, referral picks. I wanted the easiest path to money. The tension was the whole project. Resolving it taught me more about workflow design under constraint than any of the unconstrained builds did.
I got a puppy. The volume of things to track is genuinely surprising the first time: food, water, output, color, vaccines, medications, allergies, symptoms. He had allergies and I had no working hypothesis. So I started building. This one’s a passion project. It’s on the backlog for the right week. Worth flagging publicly because the cadence of these builds — passion projects in the cracks between serious work — is part of why the serious work stays sharp.
Built to give the HOA board a quick read on incoming contracts — surface the language worth flagging, the obligations worth questioning, the clauses worth a closer look. Two lessons came out of it. The first was the obvious one: AI is not going to replace lawyers. It is going to let me have informed conversations with them, which is a much more useful outcome anyway. The second came from a lawyer friend who described contract work as artistry — that reading contracts is like looking at a painting, and writing them is like creating one. He’s right. Contract language is dense not because it’s bad writing but because it’s compressed argument, each clause carrying decades of edge cases someone fought through. AI is coming for our tasks, not our jobs. Our jobs morph. The artistry of the practice survives the automation of the tasks. I know how that sounds. I’m saying it anyway.
Built for a friend’s company. Fifteen evaluation engines — keyword density, schema validation, competitor mapping, and the rest — running in parallel, with a second AI pass that synthesizes their output into a prioritized punch list. The first time I architected one AI to optimize the output of another. A pattern I’ve returned to repeatedly since.
Built with a co-founder whose constraints were nothing like mine. Her time was scarce, her tolerance for friction was zero. She would not write the product description. I was technical and patient enough to be in the review-and-approve loop. The design problem wasn’t the technology — it was making the AI do the writing she wouldn’t, while leaving me a meaningful checkpoint that didn’t slow her down. The lesson generalizes: AI workflow design is rarely about what the model can do. It’s about which user’s friction you’re absorbing. Pick badly and the tool dies because someone gives up. Pick well and your busiest user can ship in thirty seconds.
The bet — API-integrated, AI-assisted quoting systems that handle the real algorithmic complexity of pulling rates from multiple sources and assembling them into a story a broker can act on.
The reality — multiple attempts across multiple market segments. Each got close to magnificent, then bogged down in the defect tail. The last twenty percent — the gap between a working demo and a system you’d stake business on — is wider than the demo suggests. I gave up on more of these than I’m proud of.
The lesson — the gap between “works in a demo” and “works on Monday’s production data” is where most AI initiatives quietly die. Knowing which projects to push through that gap and which to abandon is the actual senior skill the AI conversation hasn’t caught up to yet. The demos are the easy part.
Word & Brown’s Week of Webinars 2025
A practical CE course on the working intersection of AI in benefits, HR tech, cybersecurity risk, and governance — framed for applied decision-making rather than theory.
The bet — I spent my career building wholesale infrastructure. I rarely build directly for end users. A community I help run needed a platform. I volunteered to build it — a real production system serving real homeowners, paid for entirely in time, with no commercial pressure to ship by Friday.
The reality — every product instinct I had from wholesale broke. Direct-to-user product means designing for people who do not have your context, your tools, or your tolerance for friction. I implemented Passkeys and made MFA mandatory because the security threshold for residential financial data is higher than I’d defaulted to. I architected a custom headless CMS — one database, multiple front-ends — because the site needed to serve in Chinese, Spanish, Korean, Vietnamese, and Arabic, and Arabic was structurally different enough to require a separate front-end. I learned legal-compliance research by layering AIs across the work: one researches, one vets the research, one implements, one validates. The platform now handles announcements, role-based financial transparency, vendor RFPs with algorithmic vendor selection from Google and Yelp reviews, and gate-access codes that rotate per residence. Legally compliant community voting ships next year.
The lesson — direct-to-user product is the operator-level training wholesale never gave me. People bring their whole life to a homeowner-portal interaction in a way they don’t bring to a broker quoting interaction. The volume of edge cases is wider. The room for AI to translate intent across languages, abilities, and contexts is enormous. The site is still growing.
Started as a build investigation. Ended as an ethical decision. Studying the algorithmic mechanics of social-media platforms closely enough to consider architecting one taught me how much of “the conversation” is engineered by the systems carrying it — and how thoroughly the engineering rewards the worst instincts of the people inside it. I quit social media after this. There is an essay in this; it doesn’t fit here. For now it sits on the timeline as the point at which I stopped treating social as neutral infrastructure.
The shift that turned “AI on slides” into “AI in working systems.” From this point forward, talks come with demos, decisions come with prototypes, and the gap between thinking about a system and shipping a usable version of it collapses to days. The platform isn’t the point. The cadence is.
CE-accredited broker session
A fifty-minute CE-accredited session on AI fundamentals, practical applications inside benefits administration, compliance considerations, and the realistic near-term arc for the industry — including the research and tools brokers can actually pick up the next day.
California Association of Health Insurance Professionals (CAHIP)
An expanded session on where AI is actually working in insurance operations — from quoting and renewal to compliance — and where it is still over-promised.
California Association of Health Insurance Professionals (CAHIP)
An innovation-focused brief for CAHIP leadership covering emerging technology trends, general-agency modernization, and applied AI in insurance operations — framed so working brokers could think about the shift without getting paralyzed by it.
Vice President of Technology & Innovation
Lens widened again — from product and digital strategy into the operational technology layer beneath the whole business. The case for treating AI as production infrastructure, not a slide topic, starts here.
Continuing-education broker session · CE #388884
A live broker session paired with a custom-built companion application — demonstrating, rather than describing, what AI in the broker workflow actually looks like. The companion-app pattern became the model I’ve repeated for every AI talk since.
Continuing-education broker session · CE #387205
The evolving cybersecurity landscape in the health insurance space, framed for working brokers rather than IT specialists.
Continuing-education broker session · CE #385839
How brokers can run a digital practice without losing the relationship work that makes the practice worth running.
Continuing-education broker session · CE #385669
A practical security walkthrough for working brokers — what the real threats look like, and the small habits that close most of the gap.
Vice President of Product & Digital Strategy
Field of vision widened from a single product to the broader operational shape of the broker workflow. Everything below sits before this pivot; everything above sits after.
The bet — could we teach machines to read carrier proposals well enough to skip the manual data-entry layer the rest of the workflow depended on?
The reality — the predecessor mapping approach had already taught us the brittleness of hand-coded rules: every carrier shift broke the maps, and the language they were written in had exactly one expert in the building. ML taught its own lesson. Roughly a hundred thousand training examples to get a model anywhere near useful. Vendor talent thin and concentrated in single experts. Costs that ballooned. An accuracy ceiling too low for production. We watched another vendor in the same problem space scale by hitting a million examples through methods compliance would have flagged in five minutes had it been our deal. We shut the project down.
The lesson — this was the “throw ML at unstructured documents” era, and most organizations that tried it quietly retreated for the same reasons we did. LLMs eventually eclipsed the whole approach by removing the training requirement entirely. The deeper lesson isn’t about the technology. It’s about the pendulum. Organizations adopt new tools, fail to operate them at the level the technology actually requires, retreat to the old way because it’s more comfortable, and then the technology evolves past the operational barrier and the same problem becomes solvable. The work today is recognizing which swing you’re standing in — and not retreating when the tooling has finally made the bet winnable.
Sacramento Association of Health Underwriters (SAHU) Expo
A live presentation to brokers and association members on benefits-administration technology and broker workflows. The talk that pulled my attention beyond a single product toward the broader operational shape of the work — the lens-widening that the 2019 role formalized.