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.

BEFORE — FRAGMENTED Document portal File storage CRM + trigger rules DEAL CONTEXT LAYER full loan lifecycle AFTER — ONE MODEL Processing agent Sales agents Config monitor reasoning, not triggers
Fig. 1 — AI enablement strategy: from workflow automation to data architecture

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.

BEFORE — SINGLE WRITER Agent A Agent B Agent C single writer ✕ last write wins ✕ silent data loss AFTER — EVENT SOURCED Agent A Agent B Agent C append- only event log immutable, one file per event view · A view · B regenerable NO LOCKING. THE COLLISION IS REMOVED, NOT MANAGED. A SECOND, NON-TECHNICAL BUILDER SHIPPED AGAINST THIS IN ONE SPRINT.
Fig. 2 — Event-sourced, CQRS-style write model for multi-agent context

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.

REQUEST plain-English request code generation SPLIT BY PERMISSION read-only ships, no gate writes data engineering review gate ADOPTED ORG-WIDE. ZERO ENGINEERING BOTTLENECK ON PERSONAL, READ-ONLY AUTOMATIONS.
Fig. 3 — Governance model for company-wide AI automation adoption

What I’ve built

← Back