AI
Most companies are automating workflows when their actual problem is that their data can’t be reasoned over. Those look similar from the outside. They are not the same project, and one of them compounds fragility.
I watched this happen up close. Every new automation made the system a little more brittle, because loan context was split across a document portal, a file store, and a CRM, and no automation could see the whole deal. The instinct was to add more automation. The fix was to stop and build a centralized deal context layer, so agents could reason across the full loan lifecycle instead of firing on triggers.
Trigger-based automation scales with how many rules you can maintain. Context-based agents scale with how good your data model is. That reframing is the whole strategy, and it’s why I stopped a push for more automation and redirected the effort at the data layer instead.
The second thing I believe: the interesting constraint is no longer capability, it’s governance and cost. A model can write the automation. The open questions are who is allowed to deploy it, what it’s permitted to write to, and whether anyone modeled the bill before shipping. Those are product decisions, not engineering ones.
Third: I build the things I propose. Writing a strategy for AI adoption without having shipped an agent is like writing a mobile roadmap having never used a phone. Everything below is something I built and ran, not something I specced.
Three systems, drawn
The write model
The multi-agent context system had a single-writer model and was losing data whenever two agents wrote at once. The obvious fix is locking. The better fix is making the collision impossible: immutable per-event writes, with views regenerated from the log.
The governance model
Company-wide AI automation stalls on one question: who is allowed to ship. Blanket engineering review kills adoption; no review kills data. The split that worked was by permission, not by person — read-only automations run unrestricted, anything that writes goes through a gate.
What I’ve built
-
An AI-native PM operating system
A working operating system for product management built on Claude Code — PRD authoring, prototyping, roadmap management, meeting intelligence, data analysis, task management, and idea capture, all automated and wired to the same context.
- 7 automated workflows
- 8+ custom agentic skills
- 6 integrated data sources
The point wasn’t speed for its own sake. It let one PM operate the surface area that normally needs a team.
-
PRD-to-prototype pipeline
A system that autonomously generates interactive, design-system-compliant HTML prototypes directly from PRDs. Prototype turnaround went from days to minutes, which changed what stakeholder validation could happen before engineering investment rather than after it.
- Days → minutes
-
A monitoring agent that cost-models itself
CRM configuration changes were silently breaking code across four repositories, and we only found out when a customer reported it. I designed a scheduled agent that audits config changes for downstream breakage risk — roughly 125 hardcoded CRM string literals under watch. Cost modeling before any code was written cut about 40% off the naive always-on design.
- 4 repositories audited
- ~40% cheaper than the ambient design
- ~$6–8/wk vs ~$17–19/wk
-
Sales conversation analysis at scale
An AI system analyzing thousands of sales calls and deal-loss reasons on an ongoing basis. It started as a proof of concept and surfaced objection patterns and rep-level coaching gaps that nobody had visibility into; the findings reshaped sales onboarding and ongoing training.
- Thousands of calls analyzed
- Rep-level coaching gaps surfaced
-
AI agent strategy for loan processing
Authored the AI Agent Vision for automating loan processing as a crawl/walk/run roadmap, and designed four AI sales agent concepts. I built a working interactive prototype the same day to validate them with stakeholders rather than debating a deck.
- 4 agent concepts
- Same-day concept to prototype