Approach
The goal is not more AI. It is more capability.
What follows are positions, not values. Each one is something a reasonable person could argue with, which is the only kind worth stating.
01
Start with the business problem, not the model.
An AI initiative that begins with a capability is looking for somewhere to put it. The ones that produce value begin with a constraint the business already feels, and arrive at AI only if it is the right instrument. Sometimes the answer is a database, a process change, or hiring two people, and saying so early is worth more than an engagement.
02
Product judgment matters more than technical novelty.
The hard question is almost never which model. It is what the workflow becomes, who is accountable for the output, what the system does when it is unsure, and whether anyone will actually change how they work. Those are product decisions wearing technical clothing.
03
Decide deliberately what is AI and what is software.
A model is the right tool for ambiguity, language, judgment under uncertainty, and problems where the rules cannot be enumerated. It is the wrong tool for arithmetic, lookups, and anything that must be exactly right every time. Most systems that fail in production failed by asking a model to do a job deterministic code should have owned.
04
Autonomy is a design decision, not a technical achievement.
Whether a person stays in the loop should follow from consequence, confidence, reversibility, and risk, not from whether full autonomy is technically possible. A system that acts alone on a reversible low-stakes decision and escalates an irreversible one is better engineering than one that does everything itself.
05
Evaluation is part of the product, not a phase near the end.
If you cannot state how you would know the system is working, you are not ready to build it. Evaluation designed after the fact measures what the system happens to do. Evaluation designed first defines what it is for, and is the difference between improving a system and merely changing it.
06
Design the feedback loop before you need it.
The systems worth building get better because they ran. That requires deciding in advance what to capture, what a correction means, how a human override becomes signal rather than an unlogged workaround, and who looks at any of it. Retrofitting this is expensive and usually never happens.
07
Organizational context is part of the architecture.
A design that requires three teams to change how they work, when none of them report to your sponsor, is not a design. It is a proposal. What an organization can actually absorb is an engineering constraint as real as latency.
Evaluation
A compelling demo is not evidence of a reliable AI product.
A demo is a sample of one, chosen by the person who built it, on the input it handles best. It tells you the system can work. It tells you almost nothing about how often it will.
The gap between those two facts is where AI projects lose their budgets. It closes only with evaluation built as part of the product: a representative dataset drawn from real inputs including the ugly ones, success criteria stated in business terms rather than model metrics, and failure analysis specific enough to act on.
None of this is exotic. It is the same discipline any serious engineering organization applies to correctness, applied to a system whose correctness is statistical.
What we build alongside the system
- Evaluation datasets drawn from real inputs, including the failures
- Success criteria in business terms, agreed before the build
- Failure analysis specific enough to act on
- Human override paths that produce signal rather than silence
- Production telemetry on quality, not only uptime
- A regression gate, so improving one thing cannot quietly break another
Human involvement
AI should not be autonomous simply because autonomy is possible.
Where a person sits in the loop is one of the highest-leverage decisions in the design, and it is usually made by default. These are the questions we make it against.
- ConsequenceWhat is the worst thing that happens if this is wrong?
- ConfidenceDoes the system know when it is uncertain, or only when it is wrong?
- ReversibilityCan the action be undone, and by whom, and how quickly?
- VolumeIs human review sustainable at real throughput, or theatre after week three?
- AccountabilityWho answers for the outcome, and do they have the context to?
Disagree with any of that?
Good. The engagements that go well usually start with an argument about what the real problem is. Bring the business problem and we will work out together whether AI belongs in the solution.
Based in Folsom, California. Working with organizations regionally and beyond.