Agentic AI that solves the business problem.
Anyone can demo an agent. I build the ones that solve a real problem and survive production. Tested against real cases, governed for safety, and measured by the outcome: revenue, savings, risk reduced. That’s how 110+ of them ended up running in healthcare, finance, and government, behind a patent and an AWS-published architecture. I am the translator between the C-suite that wants ROI and the engineers who build it.
Built for regulated environments: model-risk governance, prompt-injection isolation, cite-or-refuse grounding, and confidence-scored human-in-the-loop on every production system. See the approach →
Seven that show the range
Document intelligence, a company I founded and led, payer policy, procurement, governed clause review, fraud, and credit. Each one started as a business problem I translated into an agentic system. Click any to open the full breakdown.
Beyond client delivery, I co-lead roughly $6.8M in internal AI investment programs for 2026, reinventing how the firm itself works with AI. I run this kind of multi-program slate year over year.
42 projects, grouped by the problem they solve
Clients anonymized; public repos linked. Click Details for problem, approach, architecture, stack, output, impact, and the framework rationale. Filter by industry or technology to jump to relevant work.
From running the program to writing the code
I lead AI delivery at the executive level and still build the systems myself. Highlighted chips are the technologies I use as a primary stack across projects, drawn from the cross-project tech matrix.
Executive & Delivery Leadership
AI & Agentic Engineering
Claude Skills · Agent Specialization
ML & Data Science
Cloud, Data & MLOps
Product & Full-Stack
Governance, Safety & Compliance
Domain Expertise
Research & Credentials
The hard part of enterprise AI isn't the model. It's making it solve a real problem, in production, that people trust.
That gap is where most AI projects die, and closing it is what I do. I am the translator between the C-suite that wants ROI and the engineers who want to build, and I've closed that gap as a researcher, a founder, and now a delivery director: understand the business pain, design the architecture, build and evaluate the agents, govern them for safety, and tune them until they hold up. I still write the code and the reference architectures myself.
From a business problem to a production system
Five steps. Each one exists because skipping it is exactly where single-prompt demos fall apart.
Understand the problem
Sit with the operators. Find where the money, time, and risk actually are, and define the outcome and its metric before any model.
Design the architecture
Decompose into single-purpose agents, put deterministic code where guarantees matter, and choose the right pattern and framework per problem: LangGraph, CrewAI, Strands, AgentCore, or deterministic orchestration.
Build & evaluate
Write evals against real cases first, encode domain rules into the prompts, wire strict JSON tool contracts. Iterate on the eval set, not on vibes.
Govern for trust
Confidence-scored human-in-the-loop, explainability, prompt-injection isolation, and an immutable audit trail. Confidence ≠ correctness.
Optimize & operate
Tune cost, accuracy, and latency together with model routing and caching. Measure tokens and dollars per outcome, and watch it in production.
Enterprise adoption of frontier models lives or dies on trust. Confidence ≠ correctness is the principle I build by.
- Confidence-scored human-in-the-loop on every production pipeline
- Explainability that satisfies regulators, not just engineers
- Prompt-injection isolation and deterministic output guardrails
- Incident response: rollback, disable, immutable audit trail
- Model-risk management: bias, drift, adversarial testing before deploy
- Vendor governance: BAAs, zero-training clauses, PII tokenization
Autonomy is earned with evidence, not claimed.
My latest engine, a 7-agent contract clause assessor, ships 85% of its assessments with no human review because every release must reproduce two frozen baselines before it counts. The other 15% routes to a person by deterministic rule, not model mood. That is what governed autonomy means in practice.
Safety and performance are not a trade-off. I engineer for both.
Every production system has to clear the non-negotiables (safety, governance, grounding) and still hit its numbers (accuracy, cost, latency). Here is how I hold both at once.
Non-negotiables first
Grounding, guardrails, confidence-scored human-in-the-loop, and audit trails are entry criteria, not features. If a system can't clear them it doesn't ship, however good the metrics look.
Then optimize the triangle
Accuracy, cost, and latency trade against each other. I tune them together: right-size the model per step, route easy cases to cheaper models, cache aggressively, and measure tokens and dollars per outcome.
Framework & reasoning selection
I fit the pattern to the problem: LangGraph for stateful multi-step control, CrewAI for role-based crews, Strands and AgentCore for AWS-native deployment, deterministic orchestration where guarantees matter, and text-to-SQL or RAG by the shape of the data.
Prove it with evals
Real-case eval sets decide every change. Nothing ships on vibes, and regressions are caught before users ever see them.
Not a model-caller. A builder who ships, and owns the outcome.
Translator
I sit between the C-suite that wants ROI and the engineers who want to build. I turn business problems into agentic systems, and agents into revenue, savings, and risk reduced.
Builder
I write the code and the reference architectures myself. A U.S. patent, an AWS-published architecture, and 110+ agents running in production.
Founder & CEO
Brane: raised $625K, built and led a 25-person team, now building an AI grid-planning platform. I know exactly what 0→1 costs.
Program leader
I co-lead ~$6.8M in AI investment programs for 2026 on top of a multi-client delivery portfolio, with value frameworks and value-based pricing. I turn AI from a demo into a business line, year over year.
Researcher
PhD in ML / applied AI, 451 citations, h-index 9, published in ASCE and MDPI. I read the papers and I ship the systems.
Builder, translator, founder, program leader, researcher.
I'm an AI product and solutions leader who takes agentic systems from a blank page to production inside regulated enterprises, and I own the outcome end to end. I designed the architecture and led the build of a GenAI document-intelligence platform (Doczy.ai) that reached $15M+ in revenue, $330M+ in client savings, a 2025 patent, and a feature on the AWS Architecture Blog, processing 2.5M+ contracts at 99%+ accuracy, and I've shipped 40+ systems and 110+ specialized agents across six industries.
Consulting taught me the other half of the job: I am the translator. I sit between the C-suite that wants ROI and the engineering teams that want to build, turning business problems into agentic systems and agents into revenue, savings, and risk reduced, and I win the room from discovery and pre-sales through close with the executives and non-technical stakeholders who own the budget. And I don't just build, I co-lead multiple multi-million-dollar AI programs: in 2026, roughly $6.8M in internal AI investment programs: an AI SaaS product build ($3M), a healthcare configuration automation engine ($2.5M), and a network cost-analytics program ($1.3M), with value-and-prioritization frameworks, change management, and value-based pricing. I've run this kind of multi-program slate year over year.
Before consulting I founded a smart-mobility startup: raised $625K, built and led a ~25-person team, ran USDOT and SBIR collaborations. I earned a PhD applying machine learning to forecasting (20+ papers, 451 citations, h-index 9, published in IEEE Access, MDPI, and ASCE journals) and taught project management to engineering students at UCF.
My conviction: the hard part of enterprise AI isn't the model. It's understanding the real business pain point, designing the right solution architecture, and building in the governance that makes it trustworthy. I still write the code and the reference architectures myself: framing the problem, designing the optimal architecture, building and testing it with human-in-the-loop, and tuning cost, accuracy, and latency until it holds up in production.
At a glance
Teams are systems too. I have built them from zero twice.
I build teams the way I build systems: clear ownership, evals for everything, autonomy that is earned. Engineers I have mentored now run their own workstreams and teach the standards forward, which is the only leadership metric I fully trust.
Everything's verifiable. Take a look.
The fastest way to reach me is email; I read everything that comes in.