HOW I WORK
Before I ask an AI system to perform revenue-cycle work, I want to know what a competent specialist should actually do.
What information matters? What decision has to be made? What evidence supports it? What changes when the case stops following the happy path?
Once that is clear, the system has something real to inherit.
THE PRINCIPLE
The goal is not to take a messy human workflow and make it happen faster.
The goal is to understand the judgment underneath the workflow, preserve the parts that matter, automate what can be automated, and create a reliable path for everything else.
Fast wrong answers are still wrong answers.
THE METHOD
I treat AI workflow development less like writing instructions once and more like building an operational system that gets tested, challenged, and refined.
INVESTIGATE
Start with the operational problem as it actually exists, not the simplified version of it.
DEFINE
Before evaluating a model, define the standard it is being evaluated against.
TRANSLATE
Specialists make dozens of small decisions that often never appear in formal documentation. Those decisions have to become visible before they can become scalable.
PRESSURE TEST
Happy-path testing tells you the workflow can succeed. Edge cases tell you whether the system actually understands what it is doing.
VALIDATE
An agent can execute every documented step and still fail the actual operational objective.
LEARN
A bad output is useful if it teaches you something about the workflow, evaluation standard, available evidence, or system behavior.
NOT A STRAIGHT LINE
Every failure, escalation, exception, and unexpected result is information about how the system understands the work.
THE STANDARDS
A fluent answer can still rely on unsupported assumptions, incomplete evidence, or the wrong operational interpretation.
Task completion matters only if the underlying revenue-cycle problem actually moved toward the intended outcome.
They expose assumptions, brittle logic, missing context, and places where the workflow understands less than we thought.
If the evidence is insufficient, the right answer may be “I don’t know yet.” A safe system has to know when to stop guessing.
“Human in the loop” should not mean a specialist silently fixes everything the automation could not handle. Escalation should be intentional, observable, and useful.
WHAT GOOD LOOKS LIKE
I’m looking for a system whose failures are understandable, detectable, and useful.
It uses the evidence it actually has.
It knows when the evidence is not enough.
It takes actions that match the current operational state.
It escalates situations it should not resolve alone.
Its mistakes can teach us how to make the next version better.