I lead product and ship code.

AI lets me take a customer conversation all the way to working software myself: work out what needs to change, build a functional first version, and put it in their hands. That lets us test the workflow, its logic, and its edge cases while the direction is still taking shape.

I stay hands-on through production: I lead the team that delivers the product and contribute frontend and backend code alongside them. I also build the shared tools and standards that make the next release faster.

I co-founded InquisitHealth and led its 12-person product and engineering team as the business reached $5M ARR and was acquired by Pyx Health. At Pyx, I led product and engineering for an AI platform deployed across dozens of health plans, with responsibility for data engineering and machine learning.

Explore the work

Now

Behavioral health
In-person and virtual group scribe
Leads the clinician pod
Frontend and backend code

Give clinicians a reason to bring patients in

We wanted clinicians to invite patients into an app for support between sessions. Working through a functional prototype with clinicians showed us the adoption problem: the invitation added work to their day and did nothing for the work already on it.

Goal: Patients in the app for support between sessions, invited by their clinician.
First step, as planned: ~~Removed: Ask clinicians to invite their patients.~~
What clinicians told us: The invite added work. Group-session notes were still a burden; the scribes they had covered only one-to-one sessions.
First step, as released: Added: A group scribe drafts session notes for clinician review. Those notes inform each patient’s clinician-approved care plan. The care plan is what the patient app delivers between sessions. It gives the clinician a reason to invite the patient, and the patient a reason to join.

My decision: start with group-session documentation.

I led those conversations, built and iterated the prototype, and set the roadmap. The engineering team and I took the group scribe from concept to production in less than one month, with me contributing frontend and backend code.

For in-person groups, we mapped voices to participants. For virtual groups, a bot captured the session.

The first release had fewer defects and needed a shorter user acceptance test than our previous launches.

Make the next release easier for the team

Alongside the product, I built the instructions and development workflow our coding agents use: codebase conventions, design guidance, and review rules. Product specifications and prototype screens gave engineers and agents a shared reference for expected behavior.

Roster and record

Create the group session

Map utterances

Attribute who said what

Lock and sign

Finish the notes

A frontend engineer built this three-screen workflow using the shared specifications and prototype screens. Delivery included code review, automated checks, user acceptance testing, and a feature flag.

Under three days. The previous comparable took more than two weeks.

Decide the behavior before implementation

The prototype let us test logic and edge cases, like a workspace with 50 records instead of five. Product and engineering settled those questions before anyone wrote production code.

From one group session to individual notes

I built this illustrative group workflow separately, without employer code. Patients, voiceprints, and audio are fictional. Capture a session, confirm who said what, and review each person’s note. Try an unmatched voice, a quiet participant, an interruption, or a failed save.

Group Scribe

Illustrative workflow · fictional records

Open group scribe

Stress & coping group

One conversation, distinct voices.
Individual notes for clinician review.

AMJRSRCC5 attending

Avery MorganSaved voice profile

Jordan ReedSaved voice profile

Sam RiveraNew voice · confirm attribution

Capture a group, match the voices, then review each person’s participation and follow-up.

How the prototype carried into engineering

I walked internal clinicians and prospective users through the prototype, and what they ran into shaped the first release. JavaScript facades stood in for live integrations, so we could test with realistic data and make things fail on purpose.

The product spec recorded decisions we had already made in working software. Product and engineering used it as the shared reference for expected behavior, and checked it again in user acceptance testing.

Live use still turned up differences across devices and working habits. We kept collecting feedback and refining after launch.

The engineering workflow draws on Addy Osmani’s open-source agent skills, adapted to the team’s system.

2024 to 2026

Pyx Health
Led product and engineering
Data engineering and machine learning

Resolve the barrier behind the referral

A referral can be opened without helping the person who received it. At Pyx Health, I led the team that built an AI platform to find what stood in the way, using prior conversations and recorded needs, then match the member with support and follow up on the outcome. It is deployed across dozens of health plans.

I made barrier resolution the outcome the system learns from. A finished task counts as progress, and the case stays open until we know whether the member got help.

Build the data foundation behind the conversation

I built high-throughput ETL and ELT pipelines for large incoming datasets, including AI-assisted header parsing. I also built the platform’s HIPAA-compliant cloud infrastructure on Azure.

Start from what the member has already shared

Each conversation uses the care gap on file, ninety days of care-coordinator notes, prior conversations, and recorded social needs. That context helps the system choose a response that fits the member’s circumstances.

Keep a human in the loop where judgment is required

The system chooses what to say, when to say it, and how much support to offer. A policy gate checks every message for clinical advice and for protected health information leaving the system. I kept benefit enrollment with a human navigator: the agent can identify the need and route the request, then it waits. Members below the readiness threshold also go to a person.

Decide what is ready to ship

Offline test suites and live guardrails covered quality, safety, latency, and cost, with audit logs behind them. Each release went through a weekly go or no-go, and routing was judged on whether the member’s barrier resolved.

A member may know where the food pantry is and still have no way to get there. This example uses a fictional member. Answer for her and watch the routing change.

09:14
A referral goes unused
A member has not acted on a food referral. Her coordinator’s notes mention cut hours and no car. The agent’s first message starts from those facts, in Spanish, after a policy check.
11:52
She answers three questions
Answer for her. Every choice maps to one defined value, so the system never has to guess what she meant.
When it comes to food, what feels like the biggest challenge right now?
If I shared the steps for the next thing to do, how comfortable would you feel doing it on your own?
Do you have a phone or computer you could use to get it done?
Readiness
Can she do it65%
Can she get to it40%
Does she want to80%
Lowest score 40%. Guided, resources with follow-up.
Under 30% a person takes over. Under 50%, guided.
11:52
A navigator books the ride
The resource she needs is a ride, and the ride comes through a plan benefit that requires enrollment. I kept enrollment with a human navigator, so the agent routes the request and waits.
pass message policy: tone, no clinical advice, no protected informationrefused a ride requires a person
15:07
The outcome stays open
The ride is booked. Food access is still pending, so the system keeps tracking it.

Read the full run, annotated