2026-06-23 05:23:00
Most technical founders carry a quiet ranking in their heads. Research sits at the top. Engineering comes next, a notch below, because engineers implement what the researchers discover. Then, somewhere down in the basement, sits sales and marketing: the dirty work, the part you’d skip if you could. The comforting form of this belief is the line you’ve heard in every Bay Area kitchen: “If we just build a good enough product, it’ll sell itself, and we won’t have to deal with all that sales stuff.”
\ It’s a delusion, and an expensive one. Call it the Silicon Valley fallacy, and it’s worth naming where it breeds. The idea that a great product sells itself survives because it lets the people who love building things avoid the part of the business they find distasteful. It tells engineers that the work they already enjoy is also the only work that matters. That’s a flattering story. It is also how good products die in obscurity while worse ones take the market.
\ The fallacy has a cost you can measure. It shows up as a sales team treated as overhead instead of a discipline, hired late, paid on a different floor of respect, and handed a product nobody bothered to make legible to a buyer. It shows up as marketing reduced to “make the website nicer” instead of the work of deciding what category you’re in and what question you want a buyer to be asking when they go looking. Companies that believe products sell themselves tend to build products that require a genius buyer to understand them, then act surprised when the genius buyers are scarce.
There’s a reason this fallacy is having a moment. We’re in a gold rush. Demand for anything with “AI” on it is so hot that founders barely have to sell; buyers are lined up, desperate to sign, eager to throw budget at tokens before they’ve figured out what they want from them. When inbound is that strong, you can run a company with no real sales muscle and post numbers that look like product-market fit. The orders arrive. The dashboard goes up and to the right. Who needs a sales team?
\ The right picture for this is the astronaut’s. The companies coasting on inbound are like astronauts in zero gravity. Float around long enough with no load on your muscles, and they atrophy without you noticing, because nothing is asking them to work. The astronaut feels fine. He feels great, actually; everything is effortless up there. Then he comes back to Earth, gravity switches on, and he can’t stand up.
\ Gravity always comes back. The AI hangover is already starting: the CIOs who approved six-figure monthly bills are now asking what they bought, the token-maxing debauchery is meeting the morning-after invoice, and the easy inbound will cool the way every gold rush cools. When it does, the companies that built a real GTM discipline while it was unfashionable will still be standing, and the ones who decided their product would sell itself will discover their selling muscles wasted away during the years they didn’t need them. You don’t build a sales organization in the quarter you suddenly need one. You built it before, while you can still pretend you don’t.
\ “Sales” in this challenge is doing double duty; the phrase is “sales or marketing,” and the marketing half is where the fallacy does its quietest damage. Salesforce is the cleanest case. Marc Benioff is a marketer first, and the “No Software” campaign, the red circle with a slash through the word, decided how a generation of buyers thought about the category before a single rep dialed a number. Gainsight didn’t just sell software; it named “customer success” and convinced a market that the function should exist. That naming work is marketing at its most load-bearing, and it’s the part technical founders are quickest to dismiss as fluff. Deciding what category you’re in, what question you want a buyer asking, and what words they’ll use to ask it: that’s not decoration applied after the product is built. It’s a choice that determines whether anyone understands what you made.
The fix isn’t to bolt a sales team onto an engineering culture that quietly looks down on it. That just relocates the contempt. The fix is to redefine what “the product” actually is.
\ Define the product as the entire journey, from the first time someone hears the company’s name to their tenth renewal a decade later. The software is a large part of that journey. So is the marketing that frames it, the discovery call where a salesperson actually listens, the demo, the solution engineering, the onboarding, the renewal conversation. All of it is the product. Which means the people doing all of it are building the product, and there’s no second class.
\ The org runs to match. No engineering corner and sales corner. Engineers and salespeople sit intermixed. When a salesperson closes a deal, the engineers say, “We closed a deal.” When an engineer ships a feature, the salespeople say, “We shipped a feature.” One team, one scoreboard, no priesthood. This is shockingly controversial in the Bay Area, especially in AI. That it’s controversial is the tell. The contempt is so baked in that treating sales as equals reads as a radical act.
\ You can feel why it works once you stop ranking the functions. The engineer who sees sales as beneath her builds features nobody can sell. The salesperson who sees engineering as a black box sells things the product can’t do. Put them on one team accountable to one business outcome, and the engineer starts asking how a customer actually behaves and how to change that behavior so they get more value, and the salesperson starts being able to demo what was actually built. The seams between the functions are where deals leak. Sitting people together and giving them a shared number is how you close the seams.
The lesson generalizes past AI startups, because the fallacy isn’t about AI. It’s about respect, and respect shows up in your org chart, your comp, and your calendar.
\ Hire your first real GTM person earlier than your instincts say, and give the role the same seniority as your first principal engineer. Treating the first salesperson as a hire you’ll “get to once the product is ready” is the fallacy in scheduling form. The product is never ready in the sense that it lets it sell itself.
\ Tie everyone, including engineers, to a business outcome rather than an intermediate metric. “We shipped four features this quarter” is the kind of number that lets a bloated org feel productive while moving nothing that matters. Revenue, retention, the share of a market you actually want: those are the numbers a one-team culture can rally around, and they’re the ones that survive a downturn.
\ And kill the seating chart that separates the believers from the help. The literal version matters less than the cultural one, but the literal one is a fast diagnostic. If your engineers have never sat in a discovery call and your salespeople can’t get an engineer to return a Slack message, you have two companies pretending to be one, and the gap between them is where your best deals go to die.
\ The companies that become legendary don’t get there because their product was so good that it sold itself. They get there because they refused to believe that was possible, and built the muscle to sell while everyone around them was still floating, weightless, certain they’d never need it.
2026-06-23 05:17:20
I Built a RAG Agent That Was Always Confident and Often Wrong. Here's What Fixed It.
A few months into running one of our newly deployed project - an internal AI agent that let our support team ask plain-English questions about customer accounts instead of digging through four different admin panels, I got a Slack message that started with "hey this is probably nothing but."
It was not nothing. The agent had told a rep that a customer's subscription had been cancelled. It hadn't. The cancellation request was sitting in a queue, not yet processed, and our agent had pulled from a table that only updated once a batch job ran every few hours. The rep, trusting the tool we'd told her to trust, had already told the customer their service would end at the end of the month.
Nobody yelled at me, which honestly made it worse. Everyone was very understanding. That's usually a sign you're about to spend your weekend in the data layer instead of doing literally anything else.
Here's the thing that took me an embarrassingly long time to internalize: I had spent most of my effort on the model side. Prompt structure, retrieval relevance, chunk sizes, which embedding model gave better recall on our knowledge base. All of that mattered, and all of that worked fine. The retrieval was relevant. The generation was fluent. The agent answered exactly the question it was asked, using exactly the data it had access to. The data was just wrong, and the agent had absolutely no way of knowing that, because nothing in the pipeline ever asked it to check.
That's the part nobody really warns you about when you're building one of these things. An LLM doesn't have a gut feeling that a number looks stale. A human support rep glancing at an admin panel might pause and think "huh, that field hasn't moved in a while, let me double check." The agent has no equivalent instinct. It gets a row from a table, treats that row as ground truth, and writes you a confident paragraph about it. Garbage in, fluent garbage out, and fluent garbage is so much more dangerous than obvious garbage because nobody questions it.
I went looking afterward for whether this was just us being sloppy or an actual pattern, and it's very much a pattern. Atlan published research on agent failures in production that found the majority of incidents they looked at traced back to the data layer feeding the agent, not the model itself, and that those failures are uniquely hard to catch because they don't look like failures, they look like answers. Which tracks exactly with what happened to us. Nothing crashed. Nothing threw an error. The agent just confidently said something false.
So here's roughly what we changed, in case it's useful to anyone building something similar.
The first fix was embarrassingly simple and probably should have been there from day one: every piece of retrieved data now carries a timestamp of when it was last synced, and the agent's system prompt explicitly tells it to surface that timestamp when the data relates to anything time-sensitive, like subscription status, payment state, or account standing. Something like:
retrieved_record =
{
"subscription_status": "active",
"last_synced": "2026-04-12T03:00:00Z",
"source": "billing_db_replica"
}
If that timestamp is older than some threshold for that specific field (we landed on fifteen minutes for billing-adjacent data, a lot looser for things like account history that don't change moment to moment), the agent is instructed to flag it rather than state it flatly. "Subscription status as of the last sync was active, but this was [X minutes/hours] ago, you may want to confirm directly" is a very different sentence than "the subscription is active," and it's the difference between a rep double-checking and a rep promising something to a customer.
The second fix was less about the agent and more about the plumbing underneath it. We'd been treating the replica database as good enough because it was "close enough to real time," without ever actually defining what close enough meant for each kind of data. Turns out nobody had. We went through and explicitly classified data by how stale it's allowed to get before the agent has to either refuse to answer confidently or fall back to a live query instead of the cached version. Billing and account status: near zero tolerance, query live or flag it. Historical support tickets: a few hours of staleness genuinely doesn't matter. Treating all of it the same was the actual root cause, more than any one bad sync.
The third thing, and probably the one that mattered most long term, was just building a dashboard nobody had to remember to check, that flagged when any data source the agent depended on had gone stale past its threshold. Before, staleness was invisible until it caused a visible problem, like a rep telling a customer the wrong thing. Now it shows up as a yellow flag in a Slack channel before anyone downstream acts on it.
None of this required touching the model at all. We didn't switch providers, didn't change the prompt structure beyond adding the staleness instruction, didn't retrain anything. The fix lived entirely in the boring layer underneath the part everyone gets excited about.
I think this is worth saying plainly because of where the industry's attention currently sits: a huge amount of energy right now is going into agent frameworks, tool-calling patterns, multi-step planning, which model reasons best. All of that is genuinely interesting work and I don't want to undersell it. But none of it helps you if the thing the agent is reasoning over is wrong, and "wrong" in a way that looks exactly like "right" until someone downstream gets burned by it. We didn't have a model problem. We had a "nobody had ever explicitly decided how fresh this data needs to be before an autonomous thing acts on it" problem, and that's a much less glamorous bug to go looking for.
If you're building something similar, the question I'd actually sit with isn't "is my retrieval good" or "is my model good." Both of those are checkable, and you'll check them, because they're the fun part. The question that's easy to skip is: for every piece of data this thing can act on, what's the actual tolerance for staleness, who decided that, and what happens when a number crosses that line — does the agent know, or does it just keep talking?
We found out the answer to that the hard way. Cheaper to find out from a blog post than from a Slack message that starts with "hey this is probably nothing but."
\
2026-06-23 05:07:23
Every year, more than $450 billion is bled out of US healthcare administration before a single patient is treated or a single claim is paid. It is not lost to fraud. It is not the product of badly drafted contracts. It evaporates in the space between the moment a patient first picks up the phone and the moment the provider finally collects what was owed for the visit, because no system in the modern healthcare stack was ever built to own that workflow end-to-end.
\ Prosper AI believes that gap is the largest unclaimed software category in healthcare. The New York-based startup announced this morning a $30 million Series A, led by Andreessen Horowitz, with participation from Base10 Partners and continued support from Emergence Capital, Y Combinator, and Company Ventures, to deploy a generative-first AI platform that runs the entire patient access workflow inside one execution layer, across both the inbound patient call and the outbound payer call, with state carried from intent to reimbursement.
\ The pitch is unusual for a healthcare AI company in 2026, because it contains no productivity promise at all. Prosper does not claim to make nurses faster, schedulers smarter, or call-center staff more productive. It claims to take over the workflow they were doing manually, end-to-end, and to be measured in financially cleared appointments and recovered dollars rather than minutes saved.
\
\ The numbers behind Prosper's thesis come from a decade of research that healthcare executives have read, internalized, and never solved. The National Bureau of Economic Research estimates that broad AI adoption in healthcare could deliver up to $360 billion in annual savings, the Healthcare Financial Management Association puts total administrative waste closer to $900 billion a year, and the $450 billion-plus figure that anchors most internal CFO conversations sits between those two estimates without doing any favors for the providers carrying the cost.
\ The structural problem is simple to state and brutal to solve: every system in the healthcare enterprise stack is a system of record, and none of them is a system of execution. The electronic health record records the appointment. The practice management system records the visit. The revenue cycle management platform records the claim. Then the obligation enters the wild, and nothing in the stack verifies whether the patient was financially cleared, whether the payer was actually called, whether the deductible was actually collected, or whether the denied claim was actually appealed within the payer's window.
\ The macro condition making this market addressable right now is hidden inside a curve that has only sharpened with time. Initial denial rates have climbed from 7.5 percent in 2018 to 11.8 percent in 2024, hospitals lost more than $48 billion in 2025 to denied claims and unpaid patient bills, and 94 percent of physicians reported in 2024 that prior authorization delays had directly caused care to be delayed or abandoned for their patients. These are not statistics that get fixed by adding another point solution to the stack, because the problem is precisely that the stack already contains too many point solutions and no single layer accountable for the financial outcome.
\
\
If any founding team has earned the right to make that diagnosis, it is, plausibly, this one. Xavier de Gracia and Josep Mingot started Prosper AI in 2023 after spending years inside the patient-access and revenue-cycle workflows they are now trying to automate, and they did the unfashionable thing for an AI startup founded that year, which was to spend the first product cycles not on the model layer but on the integration layer.
\ The result, three years in, is a platform with deep native connectors into athenahealth, ModMed, Veradigm, eClinicalWorks, and ImagineSoftware, which is to say into the five systems where the majority of US outpatient care actually gets scheduled, documented, and billed. That is the unsexy work that determines whether an AI agent can actually do anything inside a real clinic, as opposed to demoing impressively on a conference stage, and it is the reason Prosper has been able to deploy at the scale and speed it has in the last six months while still claiming a competitive win rate four times the industry baseline.
\ The growth trajectory in the six months between funding announcements is the data point that closed the round. Revenue grew 5x. Provider coverage went from roughly 30,000 to more than 150,000. Forty-plus healthcare organizations signed. The platform is now powering more than $1.3 billion in patient care. That is not the trajectory of a company selling features, because feature-led growth in healthcare software historically caps at a fraction of that rate; that is the trajectory of a company whose customers are picking it up for one workflow and immediately asking for the next, which is the single highest-conviction signal a Series A investor can find in this category.
\
\
Prosper's platform connects to existing EHR and practice management systems, interprets the patient and payer obligations attached to a visit, executes the workflow across both directions of the call, and follows the financial outcome from intent to paid claim. No rip-and-replace. No new system of record. That deployment posture is itself a strategic weapon, because it sidesteps the multi-year implementation cycles that have killed most enterprise healthcare software momentum and lets the platform prove its value against live patient interactions from week one rather than month thirteen.
\ The platform runs across the full pre-care and post-care sequence. It answers the inbound patient call, identifies the patient against the EHR, books the appointment directly in athenahealth or ModMed or whichever system the clinic runs, verifies insurance benefits in real time, places outbound calls to payers when benefits cannot be confirmed digitally, navigates payer IVRs, waits on hold, conducts the conversation with a live payer agent when the call gets escalated, initiates prior authorization if the procedure requires it, generates the financial-responsibility quote for the patient before the visit, and then follows the resulting bill through patient collections after care has been delivered. The platform is generative-first for both the patient call and the payer call, which is the technical detail that almost nobody covering the funding announcement is going to dwell on, but which is the entire architectural argument behind the company.
\
\ Most healthcare voice AI platforms are inbound only. They were built to replace the call center, which means they were built to receive patient phone calls and reduce average handle time. Prosper places outbound calls to insurance companies in the same architectural footprint, with state carried from the original patient request across the entire downstream interaction, and that single design decision is what separates a voice front-end from an execution layer.
\
The phrase "voice AI for healthcare" has been flattened into a category label, so it is worth showing what the underlying claim actually means. Voice is the channel. The product is execution of a financial workflow that happens to use voice as its primary input and output.
\ The clearest way to see this is to consider what scheduling alone actually does for a provider's P&L. A first-generation voice AI that answers the phone, books the appointment, and writes the booking into the EHR captures roughly four percent of US healthcare administrative cost. Patient billing and collections sit closer to six. Insurance verification sits around twelve. Prior authorization sits well above fifteen. Claim denials and appeals sit at twenty-two. The scheduling layer is the entry point, but it is not where the money lives, and a voice AI that only does scheduling is competing for the smallest slice of the administrative cost stack while letting the rest of the workflow disappear into manual handoffs.
\
\ This is the diagnosis the press release does not quite spell out but that the analytics behind the announcement quietly confirm. The 20 to 30 percent end-to-end automation rate that the COO of Piedmont Dermatology referenced in the announcement is not a function of model quality, because the underlying voice models from OpenAI, Anthropic, and Google have closed most of the gap between vendor implementations; it is a function of which slices of the workflow each platform was ever architected to address. Scheduling alone caps at scheduling alone. Verification and billing require a fundamentally different platform shape, with payer integration, financial-responsibility logic, and dispute workflow built in from the architectural foundation rather than bolted on as a Q4 roadmap item. Prosper is winning competitive RFPs not because its voice model is dramatically better than the competition, but because the buyer has stopped buying voice and started buying execution.
\
Here is where the SaaS analysis gets interesting, because Prosper's market can be sized two completely different ways, and the gap between them is the whole investment story.
\ Sized conventionally, Prosper lives inside the US revenue cycle management software market, which stands at roughly $73 billion in 2026 and is projected to reach $196 billion by 2035 at an 11.6 percent CAGR. Respectable, growing, crowded with incumbents from Optum and R1 RCM to Epic Resolute and a half-dozen point-solution vendors that have collectively raised billions to chase slivers of the budget line. If Prosper is fighting for software-line-item RCM dollars, it is competing on a category map that already has scale players defending their turf.
\ But that is not the market Prosper is claiming. Its category framing, an execution layer scored on workflow outcomes rather than seats sold, points at the $450 billion-plus administrative waste pool itself, and inside that pool at the $48 billion in annual hospital losses to denied claims and unpaid patient bills that nobody has been able to recover at scale because nobody has owned the workflow end-to-end. The two numbers are separated by more than an order of magnitude, and a platform that captured even one or two percent of the recovery surface annually would be operating against a revenue ceiling structurally larger than the entire software market it supposedly belongs to. That is the arithmetic of category creation: the company that convinces buyers to price execution as a share of recovered dollars, rather than as a software subscription priced against seat count, is not competing inside the RCM software market at all.
\ There is precedent for this exact maneuver outside healthcare. Stripe did not compete inside the payment-processing software market when it launched; it competed for a percentage of online transaction volume, which was an addressable opportunity orders of magnitude larger than the software budget it appeared to be selling against. The patient-access workflow today looks structurally similar to online payments in 2010, fragmented across a scheduling vendor, an eligibility-check vendor, a billing vendor, and a denial-management vendor, with a small army of human call-center staff stitching the four together at the boundary. Prosper is the Stripe-style consolidation of that stack, with the same pricing geometry quietly available to it if it can demonstrate recovered or accelerated dollars at enough lighthouse customers in the next two cycles.
\
For readers building or evaluating SaaS, the Prosper model rewards a closer look, because almost none of the classic SaaS mechanics apply in their usual form.
\ Pricing. Seat-based pricing is incoherent for an autonomous layer, because there are no seats sitting in it. The natural model is a platform fee plus a share of recovered or accelerated dollars, which is the structure the broader agentic market is already converging on as outcome-based pricing. The strategic consequence is non-trivial: revenue scales with leakage closed rather than licenses sold, which means the sales conversation begins with a free workflow assessment and ends with a number the CFO has already validated against her own P&L.
\ Net revenue retention. Land-and-expand is built into the data rather than the sales motion. An outpatient group that deploys Prosper for inbound scheduling is one integration cycle away from adding outbound payer calls, and one integration cycle from there to patient billing and financial-responsibility quoting, and each new workflow the platform learns to execute expands the recoverable surface inside the same customer. Expansion revenue arrives without expansion headcount, which is what best-in-class NRR actually requires, and which is the metric that determines whether the next round prices the company as infrastructure or as software.
\ The moat. Every denied claim that gets appealed inside Prosper, every benefits call that resolves a payer ambiguity, every patient billing exchange that gets to a paid invoice feeds a vertical failure-pattern library that makes the next recovery faster and more accurate. The library is generated by doing the work, in regulated workflows, against specific payer behaviors that vary by region and product line; competitors cannot shortcut that library with a bigger foundation model, because the data is not on the public internet. Combined with the EHR integration depth, switching costs compound in both directions, which is the cleanest definition of a software moat that anyone has come up with.
\
\ The honest tension. A recovery business theoretically shrinks its own TAM, because perfect prevention would eventually leave nothing to recover. In practice, healthcare leakage is structurally regenerative: every new payer contract, every new plan year, every new coding update, every PA requirement change creates fresh failure surface, and the prevention analytics Prosper accumulates over time become the expansion product rather than the cannibalizing one. The recovery wedge funds the customer relationship; the prevention layer deepens it.
\ The round itself fits the model. At $30 million, the Series A is deliberately modest for an a16z lead in 2026, where the median healthcare AI Series A has run closer to $40 to $60 million. For a capital-efficient, outcome-priced model with the growth trajectory Prosper has demonstrated, that reads as a milestone round, not a moonshot: prove the platform thesis at scaled customers in two or three buyer segments, then raise a Series B on referenceable P&L impact rather than on narrative.
\
Prosper enters a market with incumbents on every side, none of whom currently does what it does in one platform.
\
\ The first ring is healthcare voice AI for inbound patient access. Hyro, a Cornell Tech spinout that has raised roughly $95 million across its life, has deployed across 50-plus health systems including Intermountain, Baptist Health, and Bon Secours Mercy Health, and resolves up to 85 percent of routine patient interactions including registration, routing, scheduling, and prescription refills. Hyro is accurate, mature, and deep on inbound voice; its limitation is that the workflow ends at scheduling and refills, which means the financial-clearance lane becomes somebody else's problem, and the customer either integrates a second platform or accepts the 20 to 30 percent automation ceiling.
\ The second ring is workflow automation that started in registration and intake. Notable Health, backed by ICONIQ Growth, Greylock, Oak HC/FT, and F-Prime, raised $100 million in its Series B in November 2021 and is deployed at 12,000-plus sites of care, with deeper digital intake and registration capabilities than Hyro but a weaker outbound payer-call workflow, which is the architectural differentiator Prosper has chosen to defend. Luma Health covers patient access with its Spark AI orchestration layer and saved more than 2.5 million staff hours across its health system client base in 2025, structurally positioned around the labor-savings TAM rather than the revenue-recovery TAM.
\ The third ring is the broad-but-shallow platforms. Innovaccer Gravity has 100-plus EHR connectors, 50-plus prebuilt agents, and the broadest data-and-agent fabric in the category, with the inverse limitation of Hyro: broad but shallow, configured for a much wider set of operational workflows that do not all reach the depth required to autonomously close a patient-access loop. The fourth ring is the legacy RCM names, Optum and R1 RCM, which sit further toward the breadth axis with even shallower automation rates because their software was built around human-in-the-loop workflows and the agentic retrofit is still in progress.
\ The competitive question is not whether the others can see the workflow. It is who gets to referenceable end-to-end recovered-dollar proof first, because in enterprise healthcare software, audited P&L impact compounds faster than feature lists, and the platform with the strongest customer mix today has the structural advantage in the buyer's evaluation tomorrow.
\
\ The customer mix is the structural advantage. Athenahealth, covering 60 million-plus lives, and ImagineSoftware, processing more than $65 billion in claims annually, both selected Prosper after running competitive evaluations, and both are distribution channels that none of the competitors above has access to at this scale. Every athenahealth client that turns on the integration becomes, in practical terms, a Prosper deployment, and the unit economics of distribution through a Fortune 500 EHR vendor are categorically different from the unit economics of acquiring health systems one at a time.
\
The AI market just flunked its ROI exam, and that is Prosper's opening. MIT's NANDA initiative found earlier this year that 95 percent of enterprise generative AI pilots delivered no measurable P&L impact despite $30 to $40 billion in cumulative spend, with budgets misallocated toward sales and marketing pilots while the highest-return opportunities sat in unglamorous back-office automation. Prosper is, almost line for line, the inverse of the pilot failure profile: workflow-native rather than user-facing, back-office rather than top-of-funnel, vertical-tuned rather than horizontal, and priced against recovered or accelerated dollars rather than productivity vibes.
\ The Rughani check is the one everyone covering the deal is going to write about, but the reading that matters is not the dollar amount; it is the precision of the observation embedded in the quote. Rughani does not claim that Prosper has the best voice AI in healthcare, or the cheapest fee structure, or the deepest model integration, or the strongest team. What he claims is that customers deploy Prosper for one workflow and then ask, unprompted, for the next, and that sentence is the single highest-conviction signal a Series A investor can find in this category, because customer pull-through across product lines without sales pressure is the only proxy that reliably predicts net revenue retention above 130 percent, which is the threshold at which a16z's enterprise playbook prices a company as infrastructure rather than as application software.
\ The Rughani portfolio underlines the read. Pearl, Tennr, Aradigm, Orchestra, Counsel, Thatch, and the rest of the names that have come out of his desk since 2018 are not model companies and they are not consumer healthcare companies; they are workflow owners, picked one rung at a time across the healthcare administrative stack. Rughani worked at Flatiron Health before joining a16z, where he watched, from the inside, a workflow software company turn structured oncology data into a $2 billion acquisition by Roche over the course of less than a decade, and the thesis he is now deploying on Prosper is the same thesis Flatiron proved in a different vertical: workflow software deployed inside a regulated healthcare environment accumulates clinical and operational data that compounds in value at a rate the broader software market consistently underprices.
\
\ The Ajao check is the one that almost nobody covering the deal is going to read correctly. Base10's portfolio reads strangely for a healthcare deal, because it is heavy on consumer fintech and operational software in adjacent verticals, with Notion, Figma, Nubank, Stripe, Motive, Chili Piper, and Popmenu in the named bets, and the pattern across those names is not healthcare adjacency, it is workflow consolidation in fragmented categories where the winner is the platform that absorbed multiple point solutions into a single execution layer with outcome-based pricing.
\ The word order in Ajao's quote rewards a careful read. He cites "savings, but increased revenue and better patient experience," and the conventional healthcare AI pitch leads with savings, because savings is the easiest line to underwrite against a labor budget the buyer already understands; revenue recovery is the harder argument to make in a procurement context, but it has a structurally larger ceiling, because the $48 billion in annual hospital losses to denied claims is not constrained by what the buyer was willing to spend on labor, it is constrained by what the buyer was willing to write off. The line Ajao is drawing is the line between the smaller TAM and the larger one.
\ The detail almost nobody is going to write about is that a16z and Base10 led the same round, which is unusual because a16z is the most prominent healthcare technology investor in the Valley and Base10 is the most prominent workflow automation investor outside healthcare; the fact that two firms applying entirely different lens systems to the same company arrived at the same investment conclusion is a stronger validation than either firm individually, and it means the cap table is now structured to support both narratives in the Series B, priced against either a healthcare workflow comparable set or a Stripe-style consolidation comparable set depending on which produces the better valuation framework eighteen months from now.
\
\
Honest analysis requires naming the hard parts, and Prosper has three worth naming.
\ The first is the 80 percent RFP win rate, which is a number extraordinary on the face of it and which deserves to be tested over more cycles before it is treated as a permanent fixture of the company's competitive position. A few quarters of dominant win rates in a category still being defined is structurally different from a multi-year track record against mature competitors, and as the addressable market grows and as more enterprise buyers run formal RFPs, the win rate is almost certainly going to drift toward 50 to 60 percent rather than hold at 80; the right reading of the current number is as a snapshot of the present-tense product differentiation, not as a forecast of permanent market share.
\ The second is the partner-as-competitor risk that runs through both of the platform-of-platforms relationships. Athenahealth and ImagineSoftware are distribution channels today, but they are also organizations with the technical capacity to build a competing voice AI internally tomorrow, and the strategic question that lives inside every infrastructure-on-infrastructure relationship is whether the partner's incentives stay aligned with the integration or whether they eventually compete with it. The mitigation in Prosper's case is that the platform is integrated across enough EHRs and software vendors that no single partner's strategic shift would be catastrophic; the mitigation is not that the risk goes away.
\ The third is the regulatory exposure attached to outbound payer-call automation. When Prosper places a call to an insurance company on behalf of a clinic, it is operating in a regulatory environment still actively being shaped by the No Surprises Act, by CMS prior-authorization rule changes, by state-level patient-protection statutes that vary considerably across the country, and by HIPAA enforcement practices that have not yet been fully tested at scale for AI-driven payer interactions. Any platform that takes autonomous action on behalf of a healthcare entity carries a non-trivial regulatory exposure that does not exist for platforms that confine themselves to recommendation rather than execution.
\
The most valuable enterprise software categories have always been built where the money already is and nobody has been watching it. ERP claimed the transaction. CRM claimed the relationship. CLM claimed the contract. Workday claimed the employee record. The patient journey, the workflow that determines whether care happens and whether the provider gets paid for delivering it, has never had a dedicated execution layer.
\ If Prosper's thesis holds, the prize is not a software budget line carved out of the $73 billion US RCM market. It is a percentage of the $450 billion-plus administrative waste pool that currently belongs to no one, and inside that pool a percentage of the $48 billion in annual hospital losses that nobody has been able to recover at scale, and inside that the network effects that come from owning the data the workflow generates as it runs. That is a structurally larger opportunity than the conventional RCM software comparable suggests, and it is the opportunity that explains why an a16z partner with a Flatiron pedigree and a Base10 partner with a Stripe pedigree wrote checks into the same round on the same day.
\ Series A announcements are easy to make and hard to interpret, but this one comes with an unusually clean test: either the recovered dollars show up on customer P&Ls in the next four quarters, or they do not. In an AI market exhausted by narratives, that kind of falsifiability might be the most valuable feature this funding announcement actually communicates.
\ Don't forget to like and share the story!
:::tip Vested Interest Disclosure: HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR.
:::
\
2026-06-23 05:06:04
Is AI a Frankenstein's monster that threatens to devour its creator by taking away their ability to earn a living? Is it a genie with potentially irreversible destructive tendencies that can never be reined in or stuffed back into the bottle that we released it from? Is it going to mark the end of the careers of the educated young with degrees who view a white-collar job as their passport to success and a good life? With as many as 71 million young people not being able to find the right kind of job worldwide because of the rapid expansion in the use of AI across businesses, organizations, and industries, will we not see a worsening of an already bad situation? The gravity of this state of affairs can be gauged by the fact that, according to UN DESA data, the global population will reach 9 billion by 2050, 6 billion of whom will be of working age.
So, are we looking at a ticking time bomb with regard to the future employment prospects for the educated young who had hitherto been assured of decent employment? Will profit-focused businesses and corporations preferring super-efficient AI in place of slow, inefficient, and plodding human workers lead to people of working age increasingly being rendered unemployable? What sort of a future are the young people really looking at?
\ Going by how technological upheavals have been managed by people down the ages, it does seem that ultimately, we will take AI in our stride and leverage it to advance humans to a much better way of living than before. But the trouble with AI is that it is well on its way to working autonomously of human oversight and even take decisions of its own volition, which may possibly make it do what it sees as being in its own best interest and not that of the people it is supposed to serve. This is something that has not escaped the attention of experts, social scientists, industry doyens, civil society, and governments around the world. There is already much talk about regulating AI and putting stringent safety measures in place.
\ It is not surprising, therefore, that a minimum of 72 countries around the world have come forward with more than a thousand AI-related policy initiatives as well as legal guardrails to assuage the people's concerns and worries pertaining to AI.
It is important to understand and appreciate the fact that AI, no matter how sophisticated, is, after all, no more than a set of productivity technologies and tools meant to serve human needs and not the vested interests of anyone or anything at the cost of depriving people of their livelihood. Rather than ensuring employment for AI at the cost of the human workforce, one has to ensure that AI enhances and empowers the latter to grow and flourish.
\ The economy is run as a pact between capitalists and the workforce to have a mutually beneficial symbiotic relationship that serves both of their interests. Any rupture of this compact on account of business owners edging out workers and making huge profits in the process cannot bode well for society.
Fortunately or unfortunately for total AI takeover votaries, there is a limit to how capable it is to completely perform every known function performed by real people and perform it substantially better than them. For one, the cost of large-scale implementation of AI is prohibitive for most organizations and businesses. Second, one may talk about Agentic AI and all that, but there isn't enough trust in the technology and its ability to work well autonomously and with minimal supervision. So, there is this requirement of having to create a whole new class of workers to help supervise and manage these new-fangled technologies.
One cannot also rule out the possibility of the massive hype surrounding AI having created this huge bubble, which could burst and end up tarnishing the image of AI as a knight in shining armour slated to transform human destiny, hopefully for the better.
History is a great teacher, and it tells us that mighty empires come and go, and every once in a while, a great new technology dazzles the world for some time. Our home, the planet Earth, meanwhile, continues to spin on its axis, and another epoch changes. The more the world changes, the more it remains the same.
Concept and prompt by Vipin Labroo; illustration generated using OpenAI's ChatGPT
\
2026-06-23 04:57:19
Dryfus stared through the portal he’d just opened, his heart seized by a sudden rush of fear. He could see a barren, rocky landscape backed by a stormy sky — nothing to hang his hopes on. This was not one of those commercial gateways kept open for long stretches as tourists and travelers stepped between worlds. This was an emergency portal. It had the capacity for only a small group for a very short time. They had been distributed to the cadets by groups, a failsafe should everything go wrong.
And everything that could go wrong, had gone wrong. Over the last 46 hours, his group of 16 had dwindled by twos and threes until now it consisted of only one. The portal pack had been passed from one cadet to another, as they each met their untimely death, picked off by a dying planet, unable to support anything more complex than a virus. The toxic air seared the lungs, and was barely tolerable with a rebreather on. Water was nowhere to be found, at least within any reasonable distance from their drop point. Or should that be their crash site?
What was meant to be a routine first mission for a new cadre of graduating cadets — a final test of their training — had turned into a disaster of epic proportions, all because of Lieutenant Cadet Foreman, a true ass if ever there were one. He’d come from a family of Space Corp officers and he behaved as though their achievements were his own.
Dryfus thought him completely pathetic. What was Foreman doing with the enlisted cadets if he were all that? Why wasn’t he in officer training? To make matters worse, the CO had made him a cadet lieutenant, after which, there simply was no living with him. If it hadn’t been for the unspoken rule among cadets, that Space Corp had each other’s back, he’d have washed out right away. Instead, they covered for him, sometimes by ignoring his orders, other times, by taking the blame when things went wrong.
Now, too late, Dryfus saw the folly in that thinking. It would have been so much wiser to have let him hang himself and allow a new company leader to be selected. By covering for Foreman, he squeaked through undetected by the instructors whose job was to sort out the bad apples. Instead, they all had paid the price.
Dryfus realized, as he paused before the shimmering circle, that the warp drive breaking, was not Foreman’s fault. It was everything that happened after, everything that led to the crash onto the surface of this restricted planet, and the death, so far, of 15 cadets, including Foreman. He shook himself, and pulled to him as much equipment as he could. He’d tied a triple cord through the straps of most of the now dead cadet’s backpacks. He couldn’t budge the bundle when it included everyone’s equipment, so he’d sorted through it, focusing primarily on food supplies, water, first aid, and weaponry. Shelter and communication gear, and the personal fliers, were simply too much weight and might or might not make that much difference in a survival situation.
He’d dialed up no fewer than six different portals, each one more dismal than the last. They didn’t have the power to reach very far, so it limited his selection. On top of that, he didn’t have the power to pull up telemetry on each target to determine suitability. All he had was a visual, and nothing more. That, and a gut feeling.
Then the unit indicated only enough power for this final window, and it was time to roll the dice. Win or lose, he had only the choice to stay or go. Staying was only an option if his intent were suicide. If he wanted any chance at all to live, stepping through this portal was his only hope. If it proved fatal, he was already dead. Anything else would be a win.
The circle collapsed in on itself, as Dryfus pondered. He worked the dial, and tapped the unit, like he’d seen his father do with their atmospheric unit back home. It appeared to do the trick, as the circle flicked back on, this time with a crackle and a bit of static.
It was now, or never. Dryfus pulled on the harness he’d made, with all the equipment he could carry attached and dragging across the ground. Then bending low, he ran for the circle, aiming to haul it all through before the portal collapsed. He’d delayed so long, he wasn’t sure he’d make it through himself, let alone any of the survival gear.
There was a charge of energy as he passed through, like a shock to your skin when the humidity is just right and you touch your cat to pet it, a jolt of electricity, and then he stumbled forward, sprawling across the alien soil, having lost his footing on the uneven ground on this new planet. He’d fallen hard, bruising his shoulder, then struggled to regain his feet. He realized that gravity here was heavier handed than what he was used to, but not unbearable. The weight of his baggage train, had likewise increased, and he realized that not all of the gear had cleared the portal.
Though it still flickered severely, it remained open. For how long, Dryfus had no idea. He began pulling on the cords that led back through the opening, pulling each backpack one by one. He’d gotten four more clear when the portal closed, leaving two leads cut off and one bag cut at about the two thirds mark where the portal had been. All in all, not a bad hall. He wasn’t yet sure what hadn’t made it through, but between the backpacks and the duffels, he’d rescued the lion’s share, and felt his chances improved.
Now to assess his new situation. The sky above was heavily clouded and shot through with reds, oranges, blues, purples, as though painted with great abandon. The ground for as far as he could see in every direction, was dark, almost black, and very uneven. The sun hung just above the horizon and he didn’t know if it was rising or setting. Opposite the sun, the horizon was hazy, but he was almost certain mountains rose in the distance and stretched at great length in either direction.
The air was breathable, with none of the searing bite he’d just left behind. It bore a musky and dank scent he could not identify. There were no plants in view, just the clumpy, disturbed looking soil. A steady breeze blew in from the direction to the right of the sun. If the sun set shortly, he would call that direction north. It had a chill to it, suggesting he was right.
There was nothing he could see that could be hastily turned into shelter, and he’d carried none with him. He made a quick decision, to prepare for the worst. Digging through several backpacks, he found some hand tools, and he began to dig a trench, not deep, just enough to create a mound of soil in a line perpendicular to the wind. On top of it, he stacked the backpacks and duffle bags, curving them around in a short crescent, and sliding each layer out to overhang the bag below it. In this way, he quickly formed a small redoubt, a buffer against the wind. Then he began removing some of the impacted soil beneath the redoubt, carving out a slight hollow that, if he pressed himself against the embankment, he could further increase his protection.
When he finished, he found some rations, and taking it into his shelter, he huddled down and ate. As he did, rain began to fall from the sky, landing in big splotches at first, slowly, but soon hitting faster, and faster. Dryfus stood for a moment, arms outstretched, letting the cool liquid splash against his face. He had never seen rain in his life, having grown up under a dome on a barren moon, then moving to a space station for university, and then to an asteroid for cadet training. It was glorious to behold, this water, and he assumed it was water, raining down from the heavens.
Slowly, he sank again to the ground, and pressed against the wall of the redoubt. He didn’t know what his chances for long-term survival were — his hunch was about as long as the rations lasted. After that, who knew? But to die with the sun, the wind and the rain on your face — who could ask for more? With that thought, he slept, even as the trench began to slowly fill up, too tired and too content to care.
\
2026-06-23 04:33:09
They Invented Eight Different People.
\ A few days ago, a tool called In the Weights made the rounds. You type a name, and it asks the leading AI models what they know about that name from memory alone, with no web search, and tells you how strongly they recognize it. Mozart and Taylor Swift score near the top. So, I typed my own name, and the names of the things I have spent years building, and what came back is the clearest demonstration I've seen of how these systems actually work.
\ Here is what the models think I am.
\ Asked who Adam Zachary Wasserman is, the panel produced eight different people: a litigation attorney at a firm called Eiger Law, a film and television actor, a former chair of the Democratic National Committee, a political scientist, the founder of a media company, a sports agent who represents Christian Pulisic, and an orthopedic surgeon. None of them are me. The tool's own honesty meter rated the existence confidence at fifteen to forty out of a hundred. The machines are quite sure I am someone, but have no idea who.
\ It gets more interesting with my body of work. I built the Honest Framework, a standard for writing software that is correct by construction. The models described it, confidently, as a Python framework for explainable AI. It has nothing to do with explainable AI. I built the Slop Audit, an instrument that scores the quality of a production codebase against compliance standards. The models variously called it a social media account that critiques AI slop, a Twitter account that exposes scams, a YouTube channel that reviews junk food, and a punk rock band. The Open Honest Foundation, which governs this work, came back as a generic nonprofit promoting transparency.
\ The humor of this situation is not lost on me. The Foundation exists, in part, to study exactly this: the way confident language hides how little a system actually knows. And here was a system, confidently, not knowing me.
\ So, I built a second tool to check the first one properly.
\ The difference between the two is the whole point. In the Weights asks the model to describe you and counts any confident description as recognition. My version asks the model to describe you, but gives it an explicit way out: if you do not recognize this, say UNKNOWN. Then it grades the answer against the truth. Done this way, the scores collapse. The Honest Framework, a strong 440 on the first tool, is recognized correctly by essentially none of the panel once the models are allowed to admit they do not know.
\ The Open Honest Foundation, an apparent 484, is zero. The high scores were not knowledge, but rather the models' willingness to generate a plausible-sounding description out of the words in the name. "Honest" plus "Framework" plus the ambient noise of AI discourse produces "explainable AI," with total confidence and no basis.
\ I’m not complaining; I just want to describe how the models work. A language model is a powerful instrument for resolving the structure already present in language. Ask it about something the linguistic record holds a great deal of, and it will tell you something true. Ask it about something the record barely contains, and it does not go quiet. It assembles the most likely-sounding answer from the pieces of the name and delivers it in the same confident voice it uses for things it actually knows. The voice is identical.
\ This is the clearest small version of what my research is actually about. The “knowing” here is a property of language in general, not of the size of the network. Where the record is thick, the model knows. Where it is thin, the model interpolates from the words and calls it knowledge. And the confident description is a reading from an instrument that will not tell you its own limitations. A microscope is silent about galaxies. A language model is silent about nothing, which is why you have to supply the silence yourself, by giving it permission to say UNKNOWN and by checking its answers against the world.
\ For the record, since the record is the point: Adam Zachary Wasserman is an independent AI researcher and software architect, the founder of the Open Honest Foundation, and the author of Honest Code (a book), the Honest Framework, the Slop Audit, and the Language-Only Hypothesis research program. The Honest Framework is a standard for code that is correct by construction. The Slop Audit is an open instrument for objectively measuring software quality. The Language-Only Hypothesis is a pre-registered claim that the emergent capabilities of large language models come from the structure of language rather than from the scale of silicon. And although I once was a musician, I haven't been in a band since before the Internet was a thing.
\ I'm not worried that the models don't know me yet. They learn from what the world writes down, and the world hasn't written much of this down yet. That's a problem I can work on, slowly, by putting accurate, verifiable descriptions where they'll be read, and it's one I can now measure, because the second tool runs every week and tells me when the next generation of models has caught up, or when it has hardened a wrong answer I need to correct. What I won't do is take the obvious shortcut and flood the channel with filler to inflate a score. An honesty project can't game a measurement of honesty without becoming a joke. So, the plan is the boring, correct one: write true things, in durable places, and wait.
\ In the meantime, if you ask a model who I am and it tells you I represent a soccer player, you'll know exactly what you're looking at: a confident guess from a system that doesn't know it's guessing.
