I'm an applied-AI leader who came up through strategy consulting and two CTO seats — fluent across the full arc: identifying and setting the AI agenda in the room, architecting the systems that deliver on it, engineering the agents and infrastructure underneath, and driving adoption through implementation and training. I help firms turn expert workflows into governed AI systems — reusable, validated, auditable, and owned by the teams that run them — for work where being wrong has consequences.
I've set AI strategy in the executive room, built the system in code, and led the team that runs it — and the judgment behind all three traces back to where I started, in finance and strategy. Across six years at Galt & Company (now AlixPartners), I led teams of four to eight consultants on Fortune 200 value-creation work — performance improvement, shareholder value, and the granular profitability analysis underneath it. I ran the executive workshops and C-level briefings, worked across consumer, retail, pharma (including direct strategy work at Mylan/Upjohn), and infrastructure and industrial clients, and contributed to engagements that found more than $100M in economic-profit opportunity. It taught me the part most technologists never learn: how a business creates value, which levers move it, and how to make a CFO believe a number.
Then I co-founded and led two bootstrapped companies as CTO — Granulytix and Enterprise Neo. Bootstrapped is the operative word: there was no team to absorb the hard part, so I built it. In each, I designed and built the entire core end to end before anyone else was hired — Neo's deterministic rule engine and the IP behind it, Granulytix's multi-agent analytics platform and its full software stack — and ran and maintained the first version myself, the one solid enough to win early customers and earn the right to scale. That 0-to-1 build is the part most large-firm technology advisors never touch: I wasn't recommending the system, I was responsible for it.
Only once the product had real traction did scaling let us bring on engineers — teams of ten to twenty that I hired, directed, and set the architecture and delivery standards for. That's when going hands-on became a choice rather than a necessity. I keep the work that genuinely needs senior judgment and AI expertise — the hard core — and hand the rest to the team: I build the first working version of whatever has to be right, then lead the people who harden, extend, and run it. How far I take it myself depends on the stage, the leverage, and what a company should keep in-house.
Today I do this independently — most recently an AI reporting and delivery system for a mid-market analytics firm — and I still work in these systems daily: my own multi-agent toolchain, every major model provider, both Azure and AWS, and a repeatable method for finding and scoring AI opportunities across an organization's functions. What ties it together is a conviction I can defend from both sides: consulting judgment about where AI is worth doing, the engineering depth to build it, and the discipline to make it trustworthy — governed workflows, clear owners, review gates, traceable results, no over-engineering and no black boxes. It's why, in my experience, firm-level AI return comes from operating-model change, not tool access.
They size the opportunity, hand over a roadmap, and depend on someone else to make it real. I lead the build too — directing the team and going hands-on at the core — so the plan and the system never drift apart.
Strong hands — but whether a use case is worth doing, and how it moves enterprise value, lands on someone else. I own the value thesis and the architecture, and lead the team that delivers it.
Slideware and pilots that demo well and stall before adoption. I've led teams through the messy reality of governance, ownership, and handoff — and built enough of it myself to know what that takes.
The four places I create the most value — from deciding what AI is worth building to making it compound across the firm.
Every team has more AI ideas than it can fund, and demos are built to impress. I assess operations, score opportunities by impact, data readiness, and dependencies, then sequence a roadmap with success metrics — so investment backs measurable outcomes, not theater.
When the method walks out the door with the person, it can't scale. I turn expert workflows into reusable, inspectable systems — source provenance, bounded facts, deterministic checks, and human review where it matters — that keep the judgment and remove the grind.
Most teams rebuild AI from scratch for every use case, so cost climbs with each one. I build a shared operating layer underneath the work — project state, reusable modules, typed contracts, and validation patterns — so each project makes the next one cheaper and faster.
The value thesis and the build have to agree, and most orgs split them across people who can't check each other. I own the whole arc — diagnose where AI is worth doing, design the architecture and adoption path, pressure-test feasibility, and translate the tradeoffs for the executive room — without the seams showing.
Real systems, designed and shipped — each one built to be trusted in client-facing workflows and handed to the team that runs it.
Engagements are described by scope and industry; specifics available in conversation.
The bet was reusable infrastructure over one-off automation. I designed and built a private AI operating layer for consulting and professional-services delivery — a catalog of versioned workflow assets coordinating through a shared project-state hub, with agent roles deliberately separated from deterministic analytics, CI-enforced content rules, and validation/publish gates. The suite spans workplanning, source canonicalization, structured investigation, profitability modeling, workflow validation, developer tooling, and a governed analytical-method catalog in active development — built to compound across engagements rather than be rebuilt each time.
The patternReusable AI workflows need shared state, typed contracts, and clean boundaries between agents and deterministic code.
The engagement opened with a week-long operations assessment: I scored roughly ten AI opportunities by impact, data readiness, and dependencies, then sequenced a roadmap — reporting was the highest-leverage first phase. From there I built and handed over a private AI reporting workflow that turns behavioral-test data and project context into validated reports, decks, support packs, run history, and recovery-aware operations. It's JSON-first and schema-driven: deterministic code computes and freezes the numbers, AI agents author the narrative from bounded facts, and every stage is validated before anything reaches a client — delivered with an install path, runbooks, halt-recovery docs, adoption materials, and training, so the team runs it without me.
The patternAI writing becomes trustworthy when analytics, evidence, validation gates, and human review are cleanly separated.
As CTO, I led technology strategy and product direction and architected a deterministic, auditable engine that converts complex regulatory and legal text into traceable, machine-evaluable rules. Bounded AI assistance is paired with deterministic validation, so outputs are checked against structured business rules rather than accepted as black-box answers. Named inventor on a filed U.S. utility patent application covering the approach.
The patternCompliance-sensitive AI needs deterministic structure around probabilistic assistance.
As co-founder and CTO, I led product and architecture for a multi-agent financial-analytics platform spanning the full stack: a Flask product surface, a Pydantic-governed agent runtime (orchestrator, planner/synthesis, document search, data analyst, code reviewer and executor), Redis-backed memory and artifacts, PostgreSQL and vector retrieval, Azure OpenAI, serverless specialist agents on Azure Functions, and Terraform-managed cloud infrastructure.
The patternAgentic products need product surface, memory, retrieval, execution, and infrastructure designed together — not bolted on after.
The résumé has the full chronology. This is the compressed version — the parts of the background that explain why I can evaluate AI opportunities, build the systems, and lead adoption with business-value discipline.
AI transformation, use-case prioritization, opportunity assessment, investor-grade business cases, value streams, ROI / KPI design, operating-model design, roadmaps, adoption planning, and CFO-ready value framing.
LLM applications, agentic workflows, multi-agent systems, RAG architecture, vector retrieval, source provenance, output validation, evaluation patterns, audit trails, deterministic rules, guardrails, and human-in-the-loop controls.
Python, APIs, PostgreSQL, Redis, AWS, Azure, Azure OpenAI, OpenAI, Anthropic Claude, Azure Functions, Azure Key Vault, Terraform, GitHub Actions, CI/CD, pgvector, Pinecone, and cloud infrastructure.
Management consulting, technical advisory, C-suite stakeholder management, executive discovery, client delivery, engagement leadership, reusable delivery IP, frameworks, playbooks, financial modeling, and strategic alternatives.
Lessons I keep coming back to — earned building and shipping these systems, not reading about them.
Firm-level AI ROI comes from operating-model change, not access. Model and seat access is commoditizing fast and, on its own, produces no durable edge — the return comes from the operating layer above the model: governed end-to-end workflows, persistent state, codified methodology, validation gates, and audit trails. This is the thesis behind how I approach every implementation.
A foundational model is a brilliant intern with no memory and no method. Every system I've shipped proved the same thing: the return comes from the layer above it — orchestration, persistent state, codified methodology, validation, and audit trail — that turns a capable model into a process a firm can actually run.
MIT's NANDA initiative found roughly 95% of enterprise GenAI pilots produce no measurable P&L impact. That matches what I've seen: the gap is rarely the model — it's the absence of governance, reusable infrastructure, and a real path to adoption. The systems I've watched actually survive all had those built in from day one. More pilots won't close the gap; operating discipline will.
Every multi-agent system I've built — from financial analysis to a deterministic regulatory engine — taught the same lesson: given latitude, an LLM will hallucinate, and it bites hardest on anything numeric. So computation never rides on the model. Anything calculated, summed, or aggregated runs through deterministic code or a dedicated subagent; every figure in a finished output traces back to a verifiable source; and validation gates sit in front of anything client-facing. Keeping probabilistic assistance separate from deterministic truth is what makes output a team can trust and defend — not just output that looks clever.
If non-technical users can't run it, recover it, and trust it, the system is unfinished. I learned to treat runbooks and recovery paths as part of the build — not documentation written afterward — so non-technical client teams have actually operated these systems without me. The work is done when the team can run it, not when the demo runs.
I'm best fit for senior roles — director through C-suite — where AI strategy, architecture, delivery, and production judgment live in one person. I'm not just advising on AI; I've built enough of these systems to know feasibility, risk, and what delivery actually takes. If that's the kind of partner you're looking for, I'd like to hear from you.