NewPraxa is onboarding design partners for 2026.Read more
[ 00 ]About Praxa

The work between the systems.

Praxa builds AI operators that carry out administrative work inside US health systems — not advice, not another dashboard, the execution itself. We are early. We are onboarding design partners for 2026. Everything on this page is what we are willing to put our name to before there is a track record to point at.

[ 01 ]Why Praxa exists

The bottleneck is not decisions. It is handoffs.

A health system does not stall because someone cannot decide. It stalls in the space between decisions.

A physician orders a scan in seconds. What follows takes a week. The order leaves the EHR as a document. A coordinator reads it and re-keys it. A payer portal wants the same facts in a different shape. A fax comes back asking a question that was already answered on page two. Nobody in that chain exercised judgment. They moved information between systems that were never built to talk to each other.

That is where the time goes: unstructured documents, fragmented data, disconnected systems, and people hired to be the glue between them. We think it is the layer no incumbent actually owns: the EHR does not, the payer will not, and outsourcing only puts more people on the same seam.

And once the data is structured, most of this work is deterministic. The rules are knowable, the steps repeat, and the genuine exceptions are a minority of the volume. What kept it manual was never the logic. It was that the input arrives as a scanned PDF, a fax, an HL7 message, and a portal screen with no API behind it. Reading that reliably is the part that only recently became possible.

So Praxa does the unglamorous half. Structure the chaos, execute end to end across the systems of record, and log every action so a person can check the work. That is the whole company.

Not the bottleneck
Clinical judgment. Health systems are full of people who already know what should happen next.
The bottleneck
Getting information into a shape the next system will accept — and then actually acting on it, on time, every time.
Why now
Multimodal models read a messy referral packet or a remittance at accuracy levels rules-based OCR never reached.
Out of scope, permanently
Clinical decisions. Praxa executes steps a qualified person has already decided on.
[ 02 ]What we believe

Four positions we hold, and expect to be held to.

  • 01

    Proof over narrative

    This category has already produced one company that sold an AI workforce years ahead of anything it had delivered. We would rather be checkable than impressive. Each workflow we run reports its own accuracy and its own time-to-value, measured on your documents and your queue, and we publish those numbers to the people paying for them before they have to ask. If a use case will not clear the bar, the honest answer is that we are not ready to ship it.

  • 02

    Execution, not judgment

    Praxa does not diagnose, triage, or make clinical decisions, and it is not going to start. It moves information and carries out steps that a qualified person has already decided should happen. Keeping that line bright is what makes everything else safe to deploy, so we treat it as a product constraint rather than a line of legal text at the bottom of a page.

  • 03

    Auditability is a feature

    Every read, every write, and every decision an operator makes is recorded, attributable, and replayable. That is not paperwork we tolerate to satisfy a reviewer. It is the reason a compliance officer can sign, the reason the second workflow is an expansion rather than a new sale, and the only honest way to answer the question that eventually gets asked: what exactly did it do, and on whose record, at two in the morning?

  • 04

    Autonomy is earned

    A new workflow starts with a human on every single item. Confidence thresholds then let the routine cases through, one workflow at a time, as measured accuracy justifies it — never as a launch setting and never across the board. Nothing irreversible runs without a reviewed history behind it. This ramp is slower than a demo makes it look, and it is the correct speed for work attached to a patient record.

[ 03 ]How we work

We send engineers, not a login.

Praxa is forward-deployed. When we take on a workflow, an engineer sits with the people who run it today — watches the queue, reads the rejections, learns which payer wants the form in which order, and finds the four undocumented steps that keep the whole thing standing. We build against that, not against a requirements document written by someone who has never worked the queue.

We work with a small number of design partners and we work with them closely. A partner gives us real access and blunt feedback. They get the workflow in production rather than in a pilot sandbox, the instrumentation to prove what it actually did, and a direct line to the engineers who wrote it. There is no account layer in between to translate.

This does not scale to a hundred logos, and it is not supposed to yet. Getting two workflows genuinely right inside a real health system is worth more this year than a demo that impresses a hundred people who will never deploy it.

Talk about a workflow
Design-partner engagement
Fig. 01
  1. 01Sit with the queue

    The real process · not the documented one

  2. 02Build against it

    Your documents · your portals · your edge cases

  3. 03Run in production

    Live work · human review on every item

  4. 04Measure, then widen

    Accuracy reported back · autonomy raised by evidence

Same team throughoutNo handoff to support
[ 04 ]Team

No headshots yet. Here is the honest version.

Praxa is early enough that a wall of portraits would be theatre. We would rather tell you what the team is being built out of, because for this problem the composition is the strategy.

  • Revenue cycle operators
  • ML engineers
  • Security engineers
  • Forward-deployed engineers

The mix is deliberate. A model that reads a denial packet correctly is worth very little if nobody on the team has ever worked a denial. A workflow that works is unsellable if it cannot survive a hospital security review. And software written far away from the queue it is meant to clear tends to solve the wrong half of the problem. We would rather hire one person who has run a revenue cycle department than three who have read about one.

If that is the room you want to be in, the open roles, the scope of each one, and how we interview are on the careers page.

See open roles
[ 05 ]Company facts

What we can state without a footnote.

US

Built for and operating in the United States

2026

Design-partner cohort now onboarding

2

Launch workflows — denial appeals and referral intake

Two things we are deliberately not saying on this page: who backs us, and who uses us. Not because the answers are uninteresting, but because a company whose entire argument is proof over narrative does not get to open with an unverifiable claim. When there is an investor to name, a partner who has agreed to be named, or an outcome we have measured and can stand behind, it will appear here with the number attached.

Until then, the fastest way to judge us is to put a real queue in front of us.

[ 06 ]Get started

Talk to us.

Bring the queue that hurts most. We will walk through how an operator would run it, what it would record at every step, and exactly what we would need from you to prove it worked.

Request a demo

Come build it.

We are hiring the four kinds of people described above. Small team, real deployments, and the unusual luxury of watching your own code clear someone's backlog.

See open roles