Jenny
The first and most important thing is that context is everything, as Chai alluded to. I also think about how we go from reactive alerting to truly proactive intelligence at the point at which it matters most. One thing we like to say is that we want our product to feel like air conditioning. It should be in the background, just making things better, and if there is something that carries great clinical risk, and we're acutely aware that intervening now rather than later is incredibly important, we should decide to act.
swyx
Before we get into today's episode, I just have a small message for listeners. Thank you. We would not be able to bring you the AI engineering, science, and entertainment content that you so clearly want if you didn't choose to also click in and tune into our content. We've been approached by sponsors on an almost daily basis, but fortunately enough of you actually subscribe to us to keep all this sustainable without ads and we want to keep it that way. But I just have one favor to ask all of you. The single most powerful, completely free thing you can do is to click that subscribe button. It's the only thing I'll ever ask of you and it means absolutely everything to me and my team that works so hard to bring the In Space to you each and every week. If you do it, I promise you we'll never stop working to make this show even better. Now let's get into it. Okay, this is a special crossover In Space and Supervised Learning pod.
Alessio Fanelli
Very, very excited to do this. Once a year at this point, we get together, and this is a fun occasion to do it on. I really wanted to talk to Abridge, but I felt very underqualified because healthcare is not something we cover very intensely. It just so happens that we at Redpoint are big investors and supporters of Abridge.
swyx
Anytime you want to have a portfolio company on your podcast, please, by all means. So let's introduce our guests. Chai and Jenny, welcome to the pod.
Jenny
Thanks for having us. We're excited to be here.
Chai
Thank you.
swyx
For listeners, what do you guys do, just to situate you in the company?
Jenny
Abridge is a clinical intelligence layer for health systems. We really started with documentation and building for clinicians. As we think about reducing the burden that clinicians have, they're spending 10 to 20 hours a week on documentation, and there's a massive doctor shortage in the country.
We also think that conversations between patients and clinicians are probably the most important workflow in healthcare. It's obviously where care is given and received. But if you think about the 20% of our GDP that goes toward healthcare, almost everything is a derivative of that conversation, whether it's the claim, the payment, the actual diagnosis given, or the treatment.
We've started with the conversation to reduce the burden of documentation for doctors, but we're really excited about the path ahead as we become this broader clinical intelligence layer.
Chai
I'm Chai. I work on clinical decision support at Abridge. As Jenny said, we're uniquely situated because we started with the clinical note. What I'm really excited about, and where we're expanding toward, is what are all the things you can do before the conversation, during the conversation, and after the conversation?
If you did have access to all the context about patients, care guidelines, and medical literature, and put that together, healthcare could look fundamentally different.
swyx
That's the context engine that you guys have. Is that what it's called?
Yeah, okay. Historically, as I understand it, the company started in 2018. A lot of people would be familiar with the AI voice-notes form factor, where doctors would be like, “Do you consent to being recorded?” It replaces handwriting and what have you.
It sounds like more recently there's been a big transition in the company. Tell me about the broader transition.
Jenny
From a transition perspective, we really think about our journey as: How do we, in our first chapter, our first act, help save time? That's where a lot of the original product was.
Alessio Fanelli
One of the interesting stats on your landing page was that doctors spend time after hours. They call it “pajama time.” Why is that pajama time?
Jenny
Doctors after work, in their pajamas at home, are just writing and catching up on their notes every day. We think some of our favorite customer love stories come from that. We have a Slack channel called Love Stories, where clinicians tell us that Abridge has helped them retire early or that they're finally able to go home and eat dinner with their kids for the first time.
Alessio Fanelli
Save the marriage and some of that. One of your quotes was, “We're not divorcing anymore.” I'm like, why? Because they're working too much, I guess.
Jenny
Yeah. In terms of where we're going and where we're expanding, we really think about our second and third acts around how we help health systems save and make more money. Health systems are operating with record-low operating margins. It's getting harder and harder to serve patients, and they have regulatory tailwinds but also a lot of headwinds coming their way.
We think AI is right for helping with the saving-and-making-more-money piece. Ultimately, how do we help save lives? The fact that our software and product are opened millions of times a week before, during, and after a patient walks in the room gives us a massive opportunity, with products like clinical decision support, which Chai is building, and so many others, to actually improve patient outcomes.
It's probably one of the most important workflows and problems to be going after right now.
swyx
One thing that's interesting, Chai, is that you came over to Abridge from Glean. I think about clinical decision support, which, for our listeners, is basically, in the context of a visit, helping a doctor figure out the right type of care. It's really a search problem in many ways, right, going through lots of different data sources, very analogous to your previous role as one of the earliest engineers at Glean.
I'm sure a lot of our listeners are curious: What's similar about the problems that you're going after now, and what feels different now that you're in healthcare?
Chai
Very similar. Taking a step back, with every wave, there are a lot of similar patterns that happen across different products. A lot of social networking products have the same patterns, and a lot of credit-based products have the same patterns. I think we're seeing something very similar in the agent era, with many companies, of course, in Redpoint's portfolio and so forth.
The key insight across both companies is that you have amazing models, but context is king. Context is what actually puts them to work. In a lot of ways, I see many similarities. This is a healthcare-coded version of Glean.
But I think the differences are really interesting. A couple of things come to mind. First and foremost is the rigor in the setting we're in. The downside risk is extremely high here in healthcare. It can actually be fatal in some cases. You prescribe something that the patient is allergic to, for example, whereas at Glean, you got the question wrong and it wasn't the end of the world in most cases.
What does that mean? That shapes our evaluation strategy, both offline evaluation and progressive rollout. There's a lot more we could go into there.
The second thing that comes to mind is vertical versus horizontal. At Glean, it's a much more horizontal company. There's a lot of variance in the personas and companies that you're working with. We also have a variety of personas—different types of specialties and different hospital systems—but the variance is a little narrower.
From a product perspective, you're able to focus far more, especially when you have a maturing technology and you're building new products that never existed before. It lets you go specific and go after them much more easily, especially in healthcare, where so many problems were solved with labor and process. That's actually extremely ripe for AI to keep helping augment and enable.
The thing that I think is really interesting about Abridge specifically, compared to many other companies in the AI area, is the modality we started with. We're ambient and we're always listening in the background. I think many more AI products will go that way, but it's actually how we started.
I think that's the greatest form of AI we can create: AI that's seamless. You're not actually looking at your screen. It's all always there, always helping you out, and being proactive. The Jarvis vision—that every hackathon I went to over the past decade always had a Jarvis competitor—but I actually think Abridge very much started from that opportunity and continues to go that way.
Alessio Fanelli
One thing I think is super interesting from a product perspective is that you have this always-on, seamless system in the background. Then you have to decide when to break the wall, almost, and say, “Hey, clinician, you might not have thought about X,” or whatever it is that you want to do.
Obviously, in healthcare, traditionally there's been this idea of alert fatigue: just a million pop-ups, and then a doctor ignores all of them. It's probably a pattern that a lot of builders are thinking through now. How do you think about the right way to intervene or pop up in a doctor visit?
Jenny
Yeah, it's such a good question. I think alerts are notorious in healthcare specifically. I think over 90% of alerts are ignored. I think the first and most important thing is that context is everything, as Chai alluded to, and I also think about how we go from reactive alerting to really proactive intelligence at the point at which it matters most. One thing we like to say is we want our product to feel like air conditioning. It should be in the background, just making things better, and maybe if there is something that has great clinical risk and we're acutely aware that intervening now and not later is incredibly important, we should decide to act.
But I think if you think about proactive versus reactive, instead of alerting a clinician during a visit when they're with their patient, having a pretty serious and sensitive conversation, how do we actually prep a clinician before they walk into the room with that patient? Historically, clinicians might have to manually go through charts with a patient they've had over the course of months or years, and they'll try to suss out what are the things they should be doing. You can imagine a world with Abridge where we'll summarize all of the most recent contacts for you and tell you, based on the reason for the visit the patient is coming in for, the types of things you should be discussing.
You're actually going into that conversation prepped rather than walking in cold to that patient visit and then having this product interrupt you 5 or 10 times throughout the visit. There might actually be times where it's really important to interrupt. We have a product called prior authorization. This is when you may go into a doctor's office with knee pain, they'll prescribe you an MRI, and I think so many of us have had this experience before where, in 4 weeks, you'll get a call saying, “Hey, Sean, that MRI that you were prescribed wasn't approved. Why don't you come back in? We'll figure it out.”
Jenny
In a world with Abridge, we might choose to quietly but still alert a doctor in that visit. An alert is probably not even the word we would want to use. Before a patient leaves, we would want to tell the doctor, “Hey, doctor, before Sean leaves, you should ask him: Has he had physical therapy, and has his pain lasted for more than 6 weeks? The Aetna plan that he's on in California requires 6 things. We've already confirmed 4 of them have been met because we have all the context, but these last 2 criteria—if you can address them with Sean before he leaves the room—we could actually guarantee that his MRI is approved before he leaves.”
When you think about clinical usefulness and impact to the patient, I think there are instances in which, if we can catch a doctor while the patient is still in the room, as we think about “save time, save money, save lives,” you kind of get to check all of those boxes. But when doctors have 15 minutes between visits, we have to be really, really thoughtful about when it actually matters.
I think there's an interesting product opportunity that AI can have: reduce latency in the world. For example, prior authorization is an example where care gets delayed, and great AI can reduce that. I think the problem with alerts before is partially a technical problem. The quality of your alerts really matters. They're going to get ignored if you get alerts that are noisy, similarly to engineering, where there are noisy alerts that you can't act on. But if you can make really high-quality alerts with both the context, as Jenny said, and really high-quality models, then I think you can create a whole other game.
Alessio Fanelli
Yeah, and I really like that experience because I think it starts to tease apart what makes this so hard and unique. To make that prior authorization example possible, think about all the data that you need to have. You need to integrate with an electronic health record to know all of the patient context. We have access to your previous labs and previous imaging. Then, to actually match you and know that you're on Aetna, we have to collect all of the different payer policies, and they vary by state. Some of these payer policies live on websites; some of them live in unstructured 50-page PDF files.
I thought this episode was to make sure we didn't scare people away from health care, but when you think about the things that make it hard, it also gives you the moat. The second is the AI and model quality we need to be able to hang our hat on. The bar, I think, is similarly high: when I worked at Opendoor, I worked on pricing models, and every outlier wiped out the margins of 30. Similarly, here in health care, the bar for accuracy is so high.
Then I'd say the last is workflow. Workflow is everything. If insurance companies deploy AI, it typically happens too late, and this is when you have the notorious, comical examples of AI just fighting each other when it's too late. But if we can pull forward the use of both the AI and the ability to solve problems when the patient's in the room, you can start to collapse what typically takes weeks or months after your visit, ideally down to minutes or real time. I think it's where health care is both very difficult but also extremely rewarding if you can crack it.
Just to get some baseline on the form factors, because I've seen some videos on your website and stuff, you guys talk a lot about ambient AI. Is the primary form factor mobile? Is there any other form factor that people get Abridge in? Is there an Abridge room setup where it's just always on? I don't know—an Abridge podcast studio?
Jenny
The primary form factor is mobile and desktop. Usually, clinicians are walking in and out of rooms with mobile, but at the end of the day, when they're closing out their notes or wanting to prep for the day ahead, they might use desktop.
We've been having a lot of really interesting partnership conversations with many of these in-room device companies as you think about the power of multimodality and even more data, and all of the context that isn't captured today. It's really fascinating to think about, especially as we go into building and scaling our nursing product. Nurses are constantly walking in to check in on a patient for 2 minutes or maybe even 30 seconds. Starting an Abridge experience is probably going to take longer than the visit. What we can do with in-room devices that are always on starts to beg really interesting and fun questions.
Alessio Fanelli
The way in tech companies we have all these Google Meet and calendar things, we might as well set up entire rooms with just Abridge tech.
Shiv Rao
Very much. I also think similarly about AR glasses and so forth. It's quite relevant: how do we bring it in a way without a screen, but also bring the information to the clinician in real time while letting them focus on the patient?
Alessio Fanelli
Do you think they want that? I'm very skeptical of AR, but I'm curious what you've tried.
Chai
Admittedly, it's not a near-term product roadmap by any means, and I'm being far-fetched. In surgeries, actually, when people are trying to visualize—you know, you're about to make an incision, but you want to see what the cut might look like or what the body might look like inside—they can basically layer in imaging.
Alessio Fanelli
Yeah, that's cool. Yeah, yeah, yeah. At some point in the future.
Jenny
But a lot of our largest customers at the largest health systems are already integrating. Even as we think about building into it, I think it unlocks a lot of product capabilities.
Alessio Fanelli
Yeah. To establish the terminology, and I know I'm asking basic questions somewhat for myself but also for the audience, when you say health systems, it's the Johns Hopkinses and Kaiser Permanentes. These are your customers, right? The outcome that you deliver for them is happier doctors, reduced costs—whatever costs, I guess, of processing—reduced mistakes. I think it's weird, in a sense, that there's also a secondary customer, the customer of the customer. Do you think about it that way?
Jenny
Yeah, we have, I think, the other interesting and complex part of building a product. We have our buyers, who are the chief medical information officers, the chief financial officers, and the CIOs of these large health systems. Our users today are clinicians, but if you think about who downstream is impacted, it's patients.
As we build with every product in mind, we think about who we're building for, who's the secondary user, and what that means either in terms of experience, security, compliance, or ROI that we have to make tangible. Time savings is one of them, but for CFOs, they care about a lot more than just time savings. We have to show that for every dollar you put into Abridge, because you have more compliant documentation or because you have fewer queries coming from your billing team, we actually save or add real dollars to your bottom line or top line. Those are things that we're constantly thinking about because of the dynamic across all 3 sets of users.
I think there's a whole other axis, too, with the payers and pharma, and connecting all 3 of these big stakeholders in health care is really important.
Alessio Fanelli
Do the payers ever see your data? Sorry—the payers mean the insurance companies, right?
Shiv Rao
Mm-hmm, yes.
Alessio Fanelli
They also see Abridge data?
Jenny
No, they won't see the raw Abridge data. When you're working together on something like prior authorization, whatever information they need, we would communicate to them.
Alessio Fanelli
All right. That's cool.
swyx
I would love to dig into—obviously, you said you solve a lot of problems on the AI side. Maybe to start at the highest level, what's 1 of the hardest problems you have to solve in AI at Abridge today? To make things simple, let's build off the prior auth example.
1 thing Jenny talked about is that this data is all over the place, and there's this combinatorial explosion of procedures, payer policies, and sometimes even different health systems. There can be some cross-product of all these considerations that you have to take into account.
But what's really hard about this problem is actually doing it in real time in the conversation.
Chai
In any AI product, usually the 3 KPIs you care about are quality, latency, and cost. What we're saying is that we want you to do this in real time in the conversation, guiding the clinician. How do we do it in a way that doesn't break the bank?
But we also need very intelligent models because you're working with this cross-product of data and all this context layer as well. You need high intelligence and high quality because you don't want alert fatigue, but you also need to be fast and cost-effective.
That's where a lot of clever engineering goes, actually. It's like, without getting into all the details here, can you model these policies in some intermediate representation, or do other things that can actually make this problem tractable? The product frontier is always changing, but we're also trying to do this now.
swyx
Yeah. What implications has that had for what you take off the shelf and say, “We don't need to be world-class at X; we'll just take this from the model providers or from some infrastructure player,” versus what you're like, “No, this is where we spend most of our time focusing”?
Chai
Yeah. This is the fun challenge in AI, right? Of course, with the shifting landscape, we try to be extremely thoughtful about predicting the trends of where third-party models are going and where we can uniquely go.
Sometimes I feel like when we talk about AI models, we're like, “The models are just going to get infinitely better.” But I don't think you can say that—maybe in the grand scheme of time you could, but actually, within every month or quarter, there are specific ways they're getting better. They're training on a lot more coding data to be better coding agents, for example.
We have to think about what unique data we're uniquely training on. Or, actually, to step back a little, where does a proprietary model bring an advantage to us? It does if it can give higher quality, or lower cost or latency at similar quality. That's very similar to many other companies.
We can do that when we have proprietary data. For example, we have on the order of 80 or 100 million—it's actually now getting close to 100 million—medical conversations. It's insane.
This data set is very interesting because it's effectively a large part of the trace between the patient and the provider. That's where the hardcore debugging happens in healthcare. We actually have these traces at scale. Our CEO has even called it an exhaust that comes out of our product.
When you have these traces, that's how you can train better agents on certain use cases, whether it's our transcription and diarization use cases or note-generation models, and we can do that much cheaper and faster. We're also always working with these third-party model providers. We collaborate closely with them, and that's how we predict where the trends are going.
The thing that I think about a lot is that I know the model providers are going to train much more on agentic workflows and so forth. That's great, because then you have a better agentic harness. But the other thing that's interesting is that, because a large class of queries to consumer model providers consists of healthcare queries, they might actually optimize by training on a lot of healthcare data to encode that knowledge in their weights.
I think this is just a great thing for us as well, because the off-the-shelf models can keep getting better at general healthcare information. Our strategy is that we have a constellation of models: we can use something for this, that, and the other, and we only care about the best product experience at the end of the day.
swyx
Yeah. Obviously, you have overall capabilities improving. I'm curious: as these models get better, is there something you look at and think, “3 months ago, we really couldn't do that, but the latest models really allow us to do it”?
Chai
Here's something interesting I've been toying with. This wasn't super obvious a year ago, but now it's become clearer and clearer that almost every agent is a coding agent underneath the hood, right? You give it, say, a file system, and it can write its own code and so forth.
When you think about healthcare and the use cases that we have, you can think of the EHR effectively as a file system. It's just a storage of all this information. There's actually a lot of information there that cannot fit into the context window, at least with today's models. You want to use that context effectively for all these product use cases we're talking about.
If you have better agents that can manipulate data, read that data, and treat it as a file system, as we see them moving toward—and we know model companies are investing this way—then that very directly benefits us.
swyx
Yeah. Okay, cool. Again, just establishing basic things, but going back to the model stuff, I'm really interested in double-clicking more on the real-time element, which is pretty important for both of you. Is real time basically just batches of every 1 minute or 5 minutes? Is that how we actually do it, or is there some more native, genuinely real-time approach, in the sense that OpenAI has a real-time API or Gemini has a real-time API?
Chai
Today, it's more on a batch basis, but we have interesting prototypes that aren't yet fully deployed as voice-in, text-out. Can you trigger your models, agents, or agentic workflows at the right times in the conversation?
You can imagine different techniques to bring this latency down. You want to bring the feedback loop down as much as you can, so there's a lot of clever engineering there. Maybe one day we'll do full voice-in and text-out and train the model to do something like that.
swyx
Do people want voice-in, voice-out?
Chai
Right now, we aren't creating experiences that happen during the conversation and are interjected. It's almost like it might be too disruptive.
Shawn Wang
Too disruptive.
Nikhil Buduma
Who knows? Maybe eventually you could have full voice agents once we improve the quality and the comfort of the technology. But right now, I think that change is much more gradual, and it's more text-focused—text out.
So much of what our product is currently trying to do is allow a clinician to focus on their patient. Maybe at some point, but right now, patients and clinicians don't want a third voice, at least not a literal voice, in that room. How do we be there with all the context and information ready at hand when there's the right moment?
swyx
Yeah. What I'm curious about is how you think about personalization in the product. I imagine every doctor is a special snowflake in their own way and has their own way they like to do things. There are probably a bunch of different approaches you can take to doing that, both within the model layer itself and with clever prompting or engineering. How do you actually deliver on that?
Jenny
It's such a good question. Personalization is massive for us. We think about personalization at 3 levels: the individual level, the specialty level, and the health system or organization level.
To your point, there are a lot of individual preferences. When a note is produced, it almost is such a deeply personal reflection of a doctor's work and how they give care. Do they have preferences on things like style? They might want bullets versus paragraphs, or something really concise versus comprehensive. They also might have phrases they really like to use or templates they want every note structured around.
We see it in our feedback all the time: “We want 2 spaces in between sentences,” or, “I refuse to use this tool.” That's something we've had to build in. The tricky part is making sure that stylistic preferences don't actually interrupt accuracy and quality. That's something we've really had to refine and hone over time.
The second is at the specialty level. A cardiologist's note or workflow is going to look very different from a dermatologist's workflow. Specialties require a lot of personalization, both in terms of what the product actually looks like—we make sure that as new users onboard, we catch that and the product proportionally reflects it—and on the back end. Evals at the specialty level are hard-earned to calibrate and get right.
swyx
Cardiology notes are the highest stakes for you guys, given that your CEO is a cardiologist. It's like, I'm not a doctor.
Jenny
Yeah, sure. Our CEO is still a practicing cardiologist. He rounds once a month, so he's our first call when we want quick and easy user feedback, too. But specialties require a lot of personalization, both in terms of what the product actually looks like—we make sure that as new users onboard, we catch that and the product proportionally reflects it—and on the back end. Evals at the specialty level are hard-earned to actually calibrate and get right.
swyx
What does a really great dermatology note look like?
Jenny
What actually makes it complete, compliant, and billable is very different from a primary care doctor. It's not just about what the product experience looks like; it's also about backend tuning and really, really deepening our understanding of what great output looks like for the specialist. That's obviously a problem that we need to calibrate internally and externally, online and offline. It takes lots of cycles, but it's necessary in a high-stakes environment.
At the health system level, for products like clinical decision support, you have health systems that have spent years or decades refining their best practices. They want to know, “Hey, we love your clinical decision support product, but how do we embed our own hospital guidelines into it to actually inform clinicians before, during, or after a visit what best practices should look like?”
I think, as you think about deepening moats as well, when health systems trust us with that data and allow us to productize it directly into the clinical workflow, it makes us a really, really great partner to health systems who want to build something that truly meets their needs and their practice guidelines.
Chai
I want to add on to that: for the clinical documentation problem, it's very similar to AI writing—AI writing that doesn't feel like your own—and then we call that slop. One framing of slop is AI without context. But we have all that context, and the clinicians can have it and can guide it.
Part of the other interesting exhaust for us is memory. It's actually one of these new systems of record, almost. We also have all the edits people make on our product. When you think about a data flywheel and how we get better over time, it becomes really, really powerful as a mechanism to go deeper in personalization.
swyx
Yeah, it compounds. It's interesting. I love this idea of working with systems on the guidelines they've built up over a long time. I feel like so many of the best AI app companies today are asking the question: how do you take the expertise that a law firm or a bank has built up over many years and then add that as context and also a special sauce over an AI tool? It seems like you all are really doing that very effectively.
Nikhil Buduma
We're now starting to have our customers ask, “What are other customers doing? How are they doing it?” As we think about having visibility across such a large set of care being delivered right now, it's a really interesting place where we could also partner.
Shawn Wang
I'm just kind of curious. This may be a nothing question, but how different are health system guidelines from each other? Don't they all converge to the same thing? And if not, where do they differ?
Nikhil Buduma
At a really high level, they're going to talk about very similar things. The difference is probably in some of the details, like, “Oh, you should refer to a specialist only when XYZ conditions are met,” or so forth. Different organizations may have different practices and guidelines around that.
At a high level, they're talking about similar things, but the details are what, of course, shape the context and the decisions you make.
Shawn Wang
Yeah. This all goes into the context engine and might affect the notes, but maybe not. For these local pathways, we're definitely thinking about it a little more for our clinical decision support product.
Mike Ng
Yeah, yeah.
Shawn Wang
Okay, and then the memory, which you raised—just tell us more about that. What have you tried in memory? What's the structure of the memory? What works, and what doesn't work?
Chai
Of course, there are many different ways you could do memory. Can you actually bake it into the model weights, or can you do it in some external store? For us, what's interesting is that when you think about how rapidly the models are changing, whether they're in-house or third-party, baking memory into the model weights sometimes makes you worry that it could be a little throwaway. You need to find a way to decompose the problem—the preferences from the underlying models and so forth.
The thing we're most excited about right now, and that's easiest to start with, is having a separate store for memory. You could have, for example, a memory sub-agent that's working in the background, figuring out what the important parts of the clinician's actions are that we want to remember for the long term.
You can also imagine other things where you have background jobs running that are collating these memories, similar to sleep and what other products and patterns do as well. You learn from all the action data we have—the edits, the conversations that they had, and the actual transcripts.
swyx
What about evals? How in the world do you do that? It's such a complex product and service area. We would love to hear you riff on that. Also, how has that evolved? I'm sure you've gotten better at it. Any learnings along the way?
Jenny
From an evals perspective, I think from day 1, when we build any new product or feature, we think about what good looks like. There are table-stakes things like clinical safety, but then you start to get deeper into what good quality looks like. When you go into something like our core product, there's style and completeness, and there are things like this now actually becoming something that can be billable, which is obviously very, very high-stakes for a health system.
We have a number of ways in which we get confidence in this. We have in-house clinicians who do what we call an LFD process to give us our very first pass at, “Is this or isn't this a good enough output?” Look at the effing data.
swyx
Effing data?
Jenny
Yeah. That's why I was smiling. I was thinking, “Is she going to mention what it stands for?” I don't know. I don't know. It's like a million acronyms. How am I supposed to know that? I don't. So it's like, “Oh yeah, of course, an LFD.” I've never heard of LFD. It's a bridge to the future. I think I got through 3 days and then I had to ask someone. I thought it was just me that didn't know, but it's our internal process.
swyx
I look at the data as a meme in ML because you tend not to look at it. You just want to look at number go up.
Jenny
Exactly. But we make sure we look at the data. As we think about all the components of good output, we first create all of our judges across all of these, and we make sure, with annotated data and either internal or external evaluators, that these judges are calibrated. Depending on the stakes, we also work with in-house and third-party evaluators across all of these before we ship any big change.
I think the goal, in terms of evolution, is figuring out how to go from this process taking months, down to weeks, down to days. Some of it is a true science and ML problem. A lot of it is also just hard operational work. Have you planned ahead in terms of what you need? Have you really optimized the capacity that you need across all of the different specialties you need? Have you gotten a really good sense of which third parties are great to work with for what use cases?
I think this takes a lot of domain expertise and, to be frank, lots of mistakes and errors in figuring that out. As much of it is an ML problem, so much of it has also been operational gains that I think are hugely, hugely important. Domain-specific expertise is everything.
swyx
Yeah, but it's funny to say that people talk about healthcare like it's one giant market, and the reality is it's dozens and dozens of submarkets. It feels like in your eval, you obviously have to build that up across the board. Is specialization the primary cardinality? That's the word that comes to mind.
Jenny
Sometimes, depending on the product or the use case. If we're making a note improvement or feature for a particular specialty, definitely. But we have products that are for nurses. We have products that are really, really aimed at making the document or the output a lot more billable. We actually want to work with coding teams and not necessarily clinicians.
Shawn Wang
Coding meaning healthcare coding?
Mike Ng
Yes—ICD-10. Is this output proportional to the work that was actually delivered? Is there sufficient documentation to justify the amount that a health system may end up charging? Specialty sometimes, but also domain—it's very different across all of the different products that we're working for.
Building out that network is not easy, and I think it's where a lot of our operational investments have gone into. I view a lot of analogies to self-driving cars here. Part of it is that we really want progressive rollout of features to actually test in the real world: is this useful, and is this going to work?
One big difference compared to past lives is that before, I'd build a product, maybe I'd alpha it, and then I'd GA it the next week because I was like, “Go, move fast, ship,” and whatnot. But the mentality is that I want to make contact with reality as quickly as possible, while progressively rolling it out. As large as an offline eval set as I can get, I want the distribution of that to actually match real-life distribution.
Over time, by rolling out early, I think, similar to Waymo's tagline, “The world's most experienced driver,” another thing that can at least increase linearly for us is the size of our evaluation, offline and online.
That, and it all feeds back. I think something that's been earned over time, speaking of evolution, is just the trust we've gotten with customers. Historically, a lot of these health systems, when they bring on new vendors, their release cycles are measured in quarters, sometimes twice a year. We've gotten our customers onto monthly release cycles, which is pretty fast for health systems, but I think what is more exciting over the last, call it, few quarters has been that a subset of our customers have said, “We actually want to innovate with you. We trust you.”
And we have a pretty decent chunk of our customers who say, “We'll actually develop with you outside of these monthly release cycles. We have a higher tolerance. We know that the stakes are very high, but we want to be the first ones using these products and giving you feedback.” And so, for a pretty substantial set of our customers, we've been able to convince them to ship in this gradual way, way before GA. I think something we talk about a lot internally is, “Trust is earned in drops, earned in buckets.”
So, we still can't do what I used to do when I worked at Loom. We had 30 million users. I'd just be rolling out experiments left and right. The bar is still quite high for iterative rollout, but because of the trust we've earned, we're able to learn at pretty high volume very quickly.
Shawn Wang
Yeah. I mean, your scale is still pretty huge. We were going to go into scale right in a sec. One thing I wanted to call out, following up on my eval, which, again, is just coming from a generalist engineer point of view, thinking through what people would be scared of in doing this, is the privacy and HIPAA elements of this. I have zero experience in that. What do you have to do? What is actually surprisingly not that bad?
Mike Ng
So, one thing that's really important here from a compliance perspective is that any of the data we use needs to be de-identified. Any real-world data we use as the basis of online eval sets that we're learning from needs to be de-identified. And there are actually very clear government guidelines about what counts as PHI.
We've even built models that can take, for example, a clinical transcript and remove all the key PHI indicators. And so, you have a scrubbed, de-identified version. One thing that's important is that first you have to get confidence in that model in the first place, right, and prove that out, because now you have multiple probabilistic systems on top of each other.
But once you have that, then you can actually train on it, use it for evaluation, and so forth. One of the cool things that you can also do from a business side is have the right data contracting with your partners.
Shawn Wang
Is the anonymization one way? Once it's done, you can't undo it? Or is there someone who holds the master key that can undo it?
Mike Ng
Yeah, okay. So, it's one way. It's one way.
Shawn Wang
One way. Yeah. I guess that's how it works. I just wanted to say, there's a lot of this learning from feedback and everything where you would want to debug more, but you can't because you just physically don't allow yourself to.
Mike Ng
Yeah. Well, some of it's also written in our customer contracts in terms of who can or can't access PHI data and how long we retain it before it gets de-identified. And so, we have a pretty high bar for who can access that PHI data, just to make sure that we always respect our customer data and privacy.
But that's something that we partner with our customers on, too, to make sure that we get as close to precision as possible in that quality while still being able to use it.
Shawn Wang
Yeah, but it'll be fascinating to see how that space evolves, right? I used to work at a company that did a lot of health care data in the cancer space. And if you ask the average cancer patient, “Hey, do you want other patients to be able to learn from your experience?”
Shiv Rao
Yeah, learn from your experience.
Shawn Wang
And they're like, “Please. I would love nothing more than for other people to be able to learn from the experience that I had.” Obviously, in the past it was a lot harder to do that kind of learning, but I think with this technology, that actually might really be practical. And so, it'll be fascinating to see how that continues to evolve.
Jenny
Yeah. There's so much in our dataset of 100 million conversations. You can imagine things like insights that you can give to the clinician. How could you have reacted to this in coaching? Or insights around which treatments are effective, because you have this data source that was never captured before. That's where intuition or experience is created from. Going back to this idea that the conversation is the agent trace.
Shawn Wang
Yeah. I guess, you know, about the 100 million conversations, I mean, I feel like you have this insane scale that maybe only a few other AI app companies have and everyone else dreams of. Not everyone has had to confront this yet, but maybe just talk about some of the challenges of operating at that scale and what our listeners have to look forward to if they ever get to this level of scale.
Chai
I think at a larger and larger scale, of course, there's general infrastructure reliability. In any given startup, you're building the plane while it's flying, so there's some notion of that. But I think what gets interesting on the AI and ML side, for sure, is that as you get at more and more scale, you have the data to first and foremost do this, but you actually start thinking about costs or infrastructure in a whole different way at scale versus a prototype.
You can use the most expensive model. You can burn as many tokens as you want, but when you're doing 100 million conversations—
swyx
Yeah, token leaderboards are less exciting than that, right?
Chai
When you're doing that, it comes from having the data, and we also have the team that's able to actually post-train based on this. You can optimize for efficiency, especially in areas where you believe that maybe a lot of the quality headroom is less, and you don't expect other off-the-shelf models to go that way, such that you want to do efficiency maximization in terms of compute and tokens.
Shawn Wang
Yeah. I mean, I feel like you guys live in the future in some way, where most use cases today are really just in use-case discovery mode, where it's like, “God, I really hope I can find something that can get to scale.” And so, you're always going to use the most powerful model, and then the few things that do get to this level of scale, you start to do those kinds of optimizations.
Shiv Rao
Yeah, it's a natural trajectory. From 0 to 1, we're not talking about any of these optimizations, but when maybe we're in the 1 to 100 or so forth, then we're in optimization mode. And what works out really well is you've got all this data from 0 to 1 that lets you do this.
Shawn Wang
Yeah, it's fascinating. But I feel like there's one thing that's so interesting about the Abridge footprint: you're in the doctor-patient visit in real time. There's probably 50 years' worth of product you could build on top of that. What gets each of you excited? What are you most excited about building in the short term, medium term, or even way down the line?
Jenny
I think something that I get really excited about is that the same conversation can serve so many stakeholders. If you think about the conversation, a doctor needs to know, “What is the documentation? How do I make sure that this fully represents the care I gave?” A patient needs to know, “What the heck just happened? This was really overwhelming. What are my next steps?” A payer needs to know, “Was this the proper and appropriate care given?”
A pharma company might want to know, “Why isn't this drug being properly used?” Or, “Is there actually a good candidate for this clinical trial that I'm about to run?” And I think where I get excited is that our product, our platform, and our infrastructure can be the same product across all of those things and start to take what today are separate, very expensive, complex systems that serve each one of these stakeholders in very different ways and start to collapse all of that into a singular platform.
That enables not just more efficiency across the board, but also better outcomes for everyone. And I think all of us experience health care in probably very painful ways. Knowing that there is a world in which we can simplify a lot is really exciting to me. And it all starts at the conversation.
swyx
You know, it's interesting. I think of it very similarly, going back to the KPIs that any AI product cares about: how do you increase quality of care, how do you reduce latency to care, and how do you reduce cost, which is huge in health care?
Chai
And they call it the Triple Aim in health care, right? But very similarly to building AI products, the thing that really excites me is when we talk about that latency piece. We talked about one example earlier of prior authorization: can you reduce the latency to care?
But you can imagine so much more. As soon as the lab value gets updated, do you have a background agent that kicks off and uses all the context to be like, “Oh, hey, actually, the patient should do this next,” for example? Flagging that to the clinician, who's always in the loop, but reducing that latency to care. And then you can imagine—this is much further down the road—even connecting that to the direct patient and the consumer.
Shawn Wang
And so, how can you build a bridge to all of these things? Very cool. I think the connections piece is an ever-growing thing. One of the key partners is the EHR, and I wonder what that relationship is like. Will they look at this as something valuable enough that they want to own someday?
Jenny
Yeah, I think our partnerships with the EHRs—we know that we have to be extremely close partners with all the EHRs we work with. Being able to pull and push all of the data into the right places is table stakes. If we can't do that, health systems don't want to use us.
The second reality of today is that clinicians spend a lot of their days in the EHR. So much of what allowed us to win in the largest health systems was having very direct and very close partnerships with some of the largest electronic health records, which allowed us to pull and push data with APIs that weren't ready out of the box.
Clinicians want to save clicks. Anytime we introduce a new product that adds 2 clicks for them in their day, they're like, "We're not going to use it." They have 15-minute back-to-back appointments with their patients. They're spending hours during pajama time doing documentation. Every second and every minute counts.
We really think about being deeply integrated into the EHR as table stakes to actually getting real usage and adoption. Anything that we build or introduce, we really talk about "earn the right" internally a lot. We have to provide so much value or save so much time that people will use us.
Those are the 2 things that are close to us. We know that the product won't be used unless it is deeply interoperable. Strategically, to your point, what does the EHR want to own versus us? EHRs are really focused on the clinical workflows and so forth.
But some of the things that we're talking about here are traditionally outside of that domain, like connecting payers and providers together with provider policies, or clinical trial matching, as Janey brought up. These are entirely new areas. We position ourselves as building an entirely new clinical intelligence layer across providers, pharma, and payers. It's a whole different ballgame that we try to play.
swyx
Yeah, but it's a layer of the stack. I'm curious: You obviously are both relatively newcomers to healthcare. People have these futuristic healthcare AI takes that everything will look different. Now that you've been in healthcare for a bit, and you obviously live at the edge of AI, what have you changed your mind on around this as you think about what healthcare looks like in 10, 20 years?
Any updates to your mental model from actually being close to the problems?
Chai
One thing I was hesitant about before—and it's actually a common thing people ask me when I'm trying to recruit engineers—is, "Oh, healthcare is a heavily regulated space." It is, rightfully so. You want to keep the patients safe at the end of the day.
But one of the interesting things that surprised me when I came to the company is that there are a lot of really favorable regulatory tailwinds as well. The government actually really wants interoperability between all these systems that we talked about, so agents can access this information.
In January, the FDA released updated guidance on clinical decision support, which is what I work on. They used to have guidance from 2022 that required you to mention all these options and do all these other things, but the new guidance is very forward-looking.
For me, what's been really cool to work on is that there's this very special moment in AI in general—we all know that—but there's also a special moment in healthcare regulation. I think one thing I would call out is that, for the very reasons things are higher-stakes or potentially considered more difficult in healthcare, I think it's where some of the hardest AI problems will get solved first, just because the bar is so high.
When I first joined, I thought, "Oh, this is where we'll be on the tail end of where all of the AI innovation will actually be able to be applied." But when you think about zero-error evals or multi-step workflows that have really, really low tolerance, I actually think a lot of the innovation will happen here, just because we have to, or else we can't ship.
Alessio Fanelli
Because another thing is that you'd much rather just solve the 80% and say that 80% is good enough.
Chai
Yeah, 80/20 doesn't work here. To build off that, I think traditionally there was a bit of stigma that healthcare companies aren't that interesting from a technical perspective. I've seen that and faced that myself. But these are actually really, really hard and fun problems from a pure technical perspective, beyond just the impact.
Alessio Fanelli
How do you bring the latency of these things down and make them really high-quality? So, okay, let's answer the latency question.
Chai
Maybe this is hopefully not too redundant with some of the things I've said earlier, but part of it is that with any latency, you have to ask: What is actually your bottleneck? In a lot of workflows, sometimes it's the model itself. That's where our data flywheel, our post-training team, and so forth come in. Can you make the models far more efficient? That's one aspect of latency.
But there's a whole other aspect of latency where, on top of that, if you use a constellation of different models, can you first use a cheap, fast model that triages and hands it off to a larger model, where you get more intelligence and so forth? There are all these clever tricks to make it work.
By the way, we also realize that the product frontier is changing, and these tricks may not get us to where we want to be in 5 years. But if we want to build a useful product right now, we need to use them.
swyx
Should we do the quick fire, or do you want to ask more about it? We can put everything that's not urgent into the quick fire, but I don't mind. I was just thinking that Jamie was on the topic of more long-tail stuff, which isn't the 80/20 thing, and that really matters. If you have any tips or cool stories, or just general approaches that have worked for you, that's interesting to dig into.
Jenny
I think one of them is simply how we staff our teams. It looks different from a traditional software engineering team, I'd say. We have a bunch of folks with different roles who are clinicians. We have this role called the clinician scientist.
I think I heard one of our leaders refer to them as "mutants" recently, but they are people who have clinical backgrounds—MDs, typically—and who are also deeply technical, somewhere on the spectrum from basically a full-stack engineer all the way to an extremely scrappy prompter.
Having each of these people embedded within our teams instantly raises the bar for everything that we build. Not only are they determining whether the product is clinically useful, but they're deeply embedded in our whole evals process. When we talk about LFDs and our actual evaluation criteria, you don't want Chai or me creating those, because we don't have a clinical background.
I think that is probably unique to Abridge, but it has been game-changing. When you think about where the puck is going, having people with clinical backgrounds who are technical—and where AI tools are going—they just become more and more critical, and like, the killers of the team. I think that's one.
The second is simply the scale at which we do evals to catch that long tail up front, before anything ever gets into production. That's something we've really started to fine-tune, both from a scale perspective and in terms of when we know we need several hundred versus several thousand offline responses.
What helps us make that quick decision and make this less of an art and as much of a science as possible? That's also been something we've had to tune over time.
swyx
And you have partners who basically opted in to give you those evals?
We work either internally or with third parties for offline evals. Then we have customers who also agreed to give us a lot of data, whether it's thumbs up, thumbs down, or choosing this or that, to get us as close to fully confident as possible.
Alessio Fanelli
The term that comes to mind is active learning on things where you know you're weak. I feel like it's a lost art, but it's a lot of the polish that comes into doing something like this.
Chai
Totally. 100%.
swyx
Maybe on a totally unrelated note, Chad, I think you obviously had a very storied run running Glean before heading over to Abridge. It's obviously one of the early AI app success stories. Reflecting back on that experience, what do you think Glean got most right, and maybe most wrong? I'm curious for your reflections.
I attribute Glean's success really to very strong technical foundations that have really stood the test of time. It started with a known problem: finding information at work is hard.
The best technology at the time was to build really high-quality search. I think a lot of times enterprise search startups failed because the quality wasn't great enough. But the learning that people took away from that is, “Oh, enterprise search is not good enough.” Quality really changes the game of whether something can be useful or not. Similarly, people may have taken away, “Oh, Alexa or voice assistants are not that useful.” But when you have quality, things can change the game.
I think Glean's early foundations—bringing in people who had built search at Google, the best place to have ever built search, being really creative, and having a very concrete problem to solve with the right technical backgrounds—laid the foundation for all of its success for many years to come. I think what's interesting is figuring out how the company adapts in this changing landscape, as we all know and have talked about many times. For Glean, figuring out how to put this context layer to use has been the fun challenge we've had over the last few years. You could say that's been the opportunity for the company as well as the challenge.
Alessio Fanelli
Yeah, definitely. I think the market feels like it's at the epicenter of the foundation models and the hyperscalers, so it'll be interesting to see how it all plays out. When you think about whether you can build something that helps everyone in knowledge work, that's a massive opportunity. My mental model is that there are a few markets that foundation model companies have to win, or that are big enough to go after, and it's probably consumer and code, among others. It'll definitely be interesting to see how it plays out.
I guess one thing we often think about on the investing side is that the pace of progress in models changes so fast, and the building patterns adjust so fast. It's always hard to figure out which pieces of the way people are building today, and the infrastructure tools they use, are going to prove persistent versus, “Okay, 6 months later, we're doing something completely different,” because models have improved. I'm curious about the stuff you use today. How do you think about the pieces of AI infrastructure software that feel a little bit more persistent?
Chad Fowler
Generally, if you take the thesis that the models are going to be more and more agentic, I think before we had to build a lot of scaffolding around that. In a previous case, we effectively made our own DSL, and you can view it similarly to other agent frameworks, because models were not capable enough, so you needed to simplify things. But over time, if the models become more and more agentic and can use the similar tools that we already have—whether it's computer use or writing code itself in a sandbox—I think much more about what the right context layers and tools are to give agents.
The other things that I think about are how you really build truly event-driven, real-time systems, especially at Abridge, where you're doing something real-time in the conversation. I think there's a lot of event-driven technology, and, by the way, stuff that we've always used in the past, whether it's Kafka, Temporal, sockets, and so forth. How do you bring that together? I think that's actually durable.
Or think about patterns in which humans collaborate with each other on Google Docs. How do you think about CRDTs and so forth when you have conflicts in multi-agent systems? All these things that we've built for humans are actually the things that are going to continue to be durable, just with 1,000 times more agents running on them instead.
Alessio Fanelli
Right. So make sure that they scale, of course, and fast and whatnot, without a doubt. Does Abridge become more agentic over time? What does the next, more agentic version of that look like? You're already pretty proactive with the notifications, I guess.
Chad Fowler
Yeah. I view that as a piece of being agentic, but I also view it as maybe some of the things we mentioned before, like reacting to labs, doing work in the background, or doing even more on behalf of the clinician, who we believe has a super important role to play in patient connection and so forth.
Alessio Fanelli
I'm curious for both of you: what's one thing you've changed your mind on in AI in the past year?
Jenny
I think the one I flip-flopped on—and this is much more product-specific—is probably the hotter take that prototypes are the end-all-be-all and PRDs are dead. We've tried switching, and we continue to evolve the way product is developed. The products that we're building are extremely complicated and nuanced, and it is very difficult for a prototype to capture the full complexity of what we can or can't do with this data.
What is the actual right problem to be solving for in a world where software has become so cheap? Yes, this is a cool-looking prototype, but should we be spending any of our precious hours here? If so, why? How does this deepen our moat in a world of decreasing moats? Does this require custom implementation from our customer to actually use? None of that gets captured in a prototype.
We're continuously evolving the way that we develop product here, but even if it's not written in the same traditional ways as it was 2 years ago, I think as a team we've gotten pretty high conviction that, in a world of so much noise, crisp written clarity is more important than ever. It might now live in a Markdown file that more teams and systems can use as context, but that's probably one that's much more product-specific to me.
Alessio Fanelli
You're disagreeing with the consensus that pure docs are dead and that prototypes are the end-all-be-all.
Jenny
We should partner with AI to create great documentation, but I think first, probably most important, is strategically answering: Why is this problem the one our company and our product should solve? What happens if the next 20 competitors build this? Why? What is our right to win? Does this help us differentiate in any way? Are we just adding noise? I think it's important.
Chai
I don't know if I could answer that, because a lot of the time the answer is just, “Let's do it first.” And I think when the cost of doing it first is so expensive—we just talked through the process of getting something out to customers—I think you need to have a higher bar for, as a business, whether we should invest here.
As all of our roles evolve, one of the product roles—or all of our jobs—becomes: Should we do this thing? I think that's something worth spending time on up front. As you think about prototypes, it's still really valuable to quickly show, “Here are the 20 ways we could do it. Clinician, I would love your feedback—which one resonates more?”
As you get into deeper fidelity, you can also make the prototypes higher fidelity and get them as close to production-ready as possible. But beyond that, to actually get it out to customers, there's a lot of implementation details, security, compliance, and edge cases—things that never get caught in a prototype—that I think need to be written out somewhere. They look different, but I think they're still more important than ever.
Alessio Fanelli
Yeah, it's interesting. I imagine a lot of that also is given the context of the stage that Abridge is at. For so many early-stage companies, it's just a desperate race: you throw 30 things at the wall, hoping something resonates with your end buyer. You find something, and that's why the prototype-first approach is so powerful.
But for you all, anything you're going to do is across 200 systems. There's a whole implementation and change-management side of things, and you get a few big bullets to fire at what you want those systems to do. I think being really thoughtful about that makes a ton of sense. Maybe the prototype-first takes will all grow into your view of the world when they're a bit more scaled.
Jenny
I think the weekend demo versus “it works at the largest health systems” is a massive, massive gap. I don't think it means we can't go fast. I think this is the fastest I've built in my career right now.
From the complexity and the scale of the products we're trying to build and the problems we're trying to solve, yes, maybe I updated a flow or shipped a new feature pretty quickly. But if you think about some of the products we're building, we're trying to collapse prior authorization—things that used to take 45 days across maybe 20 different touchpoints—into 1.
I think I'm building faster than I ever have, and the thoughtfulness actually allows us to go fast at the right things. It sounds contradictory, but I think, yeah: go slow to go fast.
Alessio Fanelli
Yeah, exactly. It's interesting. When a lot of things are changing in AI discourse, I think sometimes we lose sight of things that have always stood the test of time, like judgment and clarity. As an engineer, sometimes I don't want to prototype. Actually, I would like to see the written clarity that comes from writing, and then we build that.
swyx
And again, for some things, of course, where it’s a small thing, just ship the prototype. Don’t sweat the details. I think the interesting thing—the nuance that gets lost sometimes in discussion—is that sometimes we need to recalibrate our judgment, for sure, because the costs and gains have changed, but that doesn’t mean we go all the way to one spectrum or the other.
Shiv Rao
Yeah.
swyx
Outside of your specific tool, I always like to ask this question: Are there any other AI tools that you guys are enjoying?
Chai
Claude Code. But that feels too basic of an answer.
swyx
Is all of Abridge engineering very big on Claude Code?
Chai
Yes, very much so. We also have Cursor. I’m just checking the boxes here. Many of the tools are available, but earlier today, you see an engineer’s screen with 6 different Claudes running at a time. Sometimes it’s the same person—I’ve seen them on the sofa now with the remote control as well, on mobile.
One of the interesting things for me, as a relatively new person to the company, is that Claude Code actually helped me onboard much faster. With any of these AI tools, I feel like I learned so much.
swyx
I do love the memes of Claude going to do this. I’d like to see Claude, the venture capitalist. I’d like to see Claude go do a company at $1 billion pre-revenue.
We always like to leave the last word in these conversations to you both. Any place you want to point folks where they can go learn more about Abridge, the work you’re doing, or any of the research you guys have done? Whatever—the floor is yours.
Jenny
A couple of places. If you go on our Abridge website, we have a lot of our white papers where we’ve done interesting work, such as reducing hallucinations.
swyx
Very well presented, by the way. I liked it.
Jenny
Thank you. Our science team rigorously defined what actually is a problem. One of the interesting things, by the way, at Abridge is that we actually have multiple statistics professors on staff as well. In that specific white paper, Michael Luby, who’s a professor at Johns Hopkins University, is one of them. We have multiple, and from that comes very high rigor.
Our taste for design also comes from really good presentation. Setting that aside, we’re going to have many more technical topics there. Please follow our Twitter account as well, Abridge HQ. We have an open house on deep-diving into AI and healthcare coming up with Indu Aurora.
swyx
Amazing. Well, thanks so much. This is super fun.
All right, thank you.