plain meets healthcare

---

Introduction

For over 20 years of living in the US, I always thought of the healthcare system as a black box. Every year I go through the exercise of selecting an employer-sponsored health plan and every year the options are difficult to parse. What is covered, what is not, which providers are in-network, what the actual cost of a procedure will be. These are questions that never seem to have clear answers. Even the simple act of going to a doctor feels daunting. You don't know what you will end up paying, whether the visit will be covered, or if there is a better option you should have chosen instead. I always assumed this is just how healthcare works in America. A highly regulated, highly complex system that is not really meant to be understood from the outside. You just pick a plan, hope for the best, and deal with the surprises when they come.

Over the past few weeks I have been sharing the vision for the plain platform with friends, family, and people I know professionally. The goal was simple: get honest feedback and brainstorm use cases for the platform. People suggested ideas across a range of industries, but a few conversations with people who work in healthcare changed my perspective entirely. What they described was not just complexity on the consumer side. It is an industry that is deeply fragmented at every layer, built on legacy systems and legacy providers, and heavily dependent on manual, time-consuming workflows like denial management and prior authorization etc. Teams spending hours on work that should have been automated years ago. I never thought that healthcare would be one of the first few verticals on plain. I think the healthcare vertical just found me / plain.

Under the hood

Healthcare in the US is a $5.3 trillion industry. It represents 18% of GDP and is the largest employment sector in the country with over 17 million workers. Behind those numbers is a system that is deeply fragmented. There are over 3,500 payers, more than 500 EHR vendors, and the average health system operates across 18 different platforms. Roughly 3 billion medical claims are processed every year, and about 15% of them are denied on first submission. That translates to approximately 450 million denied claims per year. Providers spent $25.7 billion in 2023 just on fighting those denials, and 70% of them were ultimately overturned and paid. Billions of dollars spent arguing over claims that should have been paid in the first place.

The natural question was why this has not been fixed. The short answer is that healthcare is one of the hardest environments to build software for. The industry operates under strict regulatory requirements like HIPAA, follows rigid data standards like EDI and X12, and demands a high level of security and compliance. The result is a familiar tradeoff. Teams that move fast tend to cut corners on compliance. Teams that prioritize compliance and security tend to take months or years to ship. Very few teams can do both, and that is a big part of why the industry is still running on manual workflows and disconnected systems.

This is exactly the kind of problem plain was built to solve. plain is a spec-driven platform designed for building complex, production-grade systems that need to be secure and compliant from day one. Systems that connect to multiple backend APIs, aggregate data across fragmented sources, and expose that functionality through autonomous AI agents. The spec-driven approach means that security, authentication, and authorization are not afterthoughts. They are defined in the specification and enforced at every layer of the generated system. What would normally take months of engineering work, plain delivers in days.

Three healthcare agents, three days

Once I understood the problem, I wanted to see how quickly plain could address it. I connected plain to healthcare payment APIs, defined the agent specifications, and had three autonomous agents running within three days. Not prototypes. Production-grade agents with authentication, authorization, and the ability to take real action against live systems. Below are the three agents I built.

Claim Status Concierge. This agent monitors submitted claims through their entire lifecycle, from submission to final payment or denial. It checks the status of claims in real time, tracks how long each claim has been sitting at each stage, and flags the ones that need attention. Claims that are stuck, rejected, or approaching filing deadlines get surfaced automatically instead of waiting for someone to notice. It maintains a complete timeline for every claim so that the revenue cycle team always knows exactly where things stand. When a claim is denied, it routes it directly to the denial triage agent for follow-up. When a claim is paid, it can be verified against the actual payment record. The result is full visibility into the claims pipeline without anyone having to manually check payer portals or chase down status updates.

Denial Triage. When a claim is denied, this agent identifies the denial, classifies why it was denied, and builds a prioritized work queue for the revenue cycle team. It maps each denial to a root cause, whether that is an eligibility issue, a missing authorization, a coding error, a medical necessity question, or a timely filing problem. It ranks denials by dollar value and likelihood of recovery so that teams focus their limited time on the cases that matter most. It also recommends specific next steps for each denial, whether that is an appeal, a corrected resubmission, or a write-off. For organizations processing hundreds or thousands of denials, this agent turns what is normally a slow, manual review process into a structured, prioritized workflow that can meaningfully accelerate revenue recovery.

835 Explain and Post. Healthcare payers send payment information in a format called an 835 Electronic Remittance Advice. These files are dense, complex, and difficult to interpret manually. This agent processes those payment documents, extracts what was paid, what was adjusted, and what the patient owes. It reconciles those payments against the original claims, identifies discrepancies, and flags exceptions like zero-pay claims, underpayments, or payments that do not match any submitted claim. It then generates a clear, actionable summary that a revenue cycle manager can review immediately. No more manually reading through complex payment files line by line. What used to take hours of skilled labor becomes an automated, auditable process.

Technical overview

It is worth noting that these agents are not traditional workflow automations. A typical workflow follows a fixed sequence of steps that is defined at build time and executed the same way every run. The agents built on plain are different. They are powered by large language models that can interpret context, reason about what needs to happen next, and decide which actions to take based on the data in front of them. They connect directly to healthcare APIs to perform real transactions, check claim statuses, retrieve payment documents, and interact with payer systems in real time. They also have access to a persistent memory layer, which means they retain context across runs. Every claim they process, every denial pattern they identify, every status check they perform gets stored and becomes available for future decisions. The system gets smarter over time. When the Denial Triage agent receives a denied claim, it does not follow a static decision tree. It reads the denial codes, evaluates the context, draws on historical patterns from previous denials, and recommends a course of action. The reasoning is dynamic. The behavior is consistent because it is constrained by the specification, but the path it takes to get there adapts to the situation.

Below is an example of the specification that was used to build the "Claim Status Concierge" agent. As you can see it has access to real APIs, agent memory and no workflow hard coded.

Below are the input specs that were used to generate the agents.

As you can see below, just from the specs above, plain generated fully production deployable agents. Below is the code output that was generated by plain.

Going all in

Healthcare was not part of the original plan for plain. But the more I dug in, the more I realized that the opportunity here is not just large, it is a natural fit. Healthcare needs complex, secure, compliant systems that connect fragmented data sources and automate manual workflows. That is exactly what plain was built to do. The three agents I shipped in three days are just the starting point. Over the coming months, the goal is to go deep into this vertical, build more agents, cover more workflows, and work closely with teams that are dealing with these problems every day. If you are building in healthcare or thinking about it, I would love to hear from you.