Selected enterprise context
ServiceNowCharles SchwabCompass Healthcare Digital
Enterprise platforms · financial systems · hospital operations
Case studies
Two different questions. One is what an AI product should let a person do before its output counts as a decision. The other is what has to be true of a system before an organization can build on it at all.
Judgment
Deciding what an AI system may do on its own, and what it has to hand back to a person, is the call I make on every product I work on. It is rarely a model question. It is a question about consequence.
Three things decide how much rope a system gets: how easily the action can be taken back, what a wrong call costs, and how far the damage travels.
Where can the system act?
Low-cost, recoverable actions can move without a person.
Where must it ask?
Consequence and permissions can make review part of the product.
What happens when it’s wrong?
Recovery, reversibility, and accountability have to be designed in.
Recommended operating mode
Easy to take back and costly to get wrong, while the impact stays with the person acting. The system can prepare the action, but a person makes the commitment.
Experiments
Where I test these decisions in code, interfaces, and policy. These are unfinished on purpose: each one exists to answer a question I could not answer by reading about it.
Can a research report stay honest after it ships?
Re-syncs against source data
Where does an always-on agent actually spend its money?
Token spend tracking
Does giving an agent the design system beat pasting a screenshot?
Figma to design-token context
Working notes
Ideas I keep returning to while building AI products.
Compare notes
System acts
Where errors are bounded and recoverable.
Pauses for approval
Where a person sees evidence before the system commits.
Hands control back
Every action leaves a record, a reason, and a recovery path.
