Just because you can use AI doesn't make it right
Just because we can use AI doesn't mean it's the right tool for the job — sometimes a standard REST API is perfect. The failure comes from saying “AI will solve this” without actually knowing that it will.
Parker Phillips is the Chief Technology Officer of InStride Health, a fully virtual clinic that treats children, teens, and young adults — roughly ages seven to twenty-four — living with severe anxiety and OCD. He leads the company's AI, product, engineering, design, IT, data, and security teams. InStride builds its own technology in house because, as Phillips puts it, modern healthcare systems simply aren't built around a care-team methodology. Each patient gets a coordinated team — a coach, a therapist, and optionally a psychiatrist — who actually communicate with one another, something traditional care rarely manages. Families enroll for six to twelve months and then graduate from a single episode of care, with symptom-improvement metrics that hold up well after they leave.
Phillips was one of InStride's earliest employees, and he built the technical foundation that now powers its coordinated, value-based care model. Before InStride he spent nearly three years at Commure, first as a full-stack engineer and later as an engineering manager, working on platforms aimed at transforming care delivery. Earlier he spent over three years at Palantir Technologies, moving through quality engineering, forward-deployed engineering, and full-stack software roles — experience that shaped his habit of embedding close to real operational problems. He holds a bachelor of science from Stanford University. From the company's start he treated clean, well-structured data as foundational, building InStride's data system and proprietary core platform years before AI made that groundwork suddenly valuable.
Phillips approaches AI like a scientist rather than an evangelist. Every experiment starts with a hypothesis — “we think this tool can do X” — followed by the smallest possible way to validate it: a fast pilot, a before-and-after survey, a clear definition of success. When InStride tested voice AI for outbound insurance calls, only about a fifth of attempts returned usable data, so he shelved it for a year, noting wryly that it worked best when an AI agent sat on the other end too — at which point, why not just use an API. His test is blunt: just because you can use AI doesn't make it the right tool, and in healthcare it has to improve clinical outcomes, never quietly trade them away for a better bottom line.
That discipline shapes how Phillips hires and where he points InStride next. He looks for engineers who treat AI with open-minded skepticism — people who can say “I used it here and it worked, here it didn't” — rather than refusers or true believers, because he believes even seasoned engineers are genuinely new at their jobs again. He sees AI as compounding the fundamentals of building good technology, not replacing the need for product-market fit, traction, and real customers. With a handful of agents already in production doing specific tasks well, his ambition is steady and human: use data and AI to make personalized, value-based mental health care more accessible to the kids and families who need it, while keeping outcomes — not headlines — the measure of success.
Read full transcript of interview
In this conversation: Josh Rubin (Host, CTO Studio) and Parker Phillips (Chief Technology Officer, InStride Health).
I am the CTO of InStride Health.
And what is InStride Health?
InStride Health is a pediatric anxiety and OCD telehealth clinic. So we treat kids who range in age from seven up to around 24, who suffer from severe anxiety and OCD. It is fully remote and fully virtual. It's tech-enabled clinical services, so we build our own technology in house to provide tools for our clinicians and our operations teams as well as for patients and families. And patients' families enroll with us for six to twelve months and then they graduate. So it's a single episode of care, and it works. Our metrics are really good in terms of patients who show improvements in their symptoms post-graduation.
Is this... you know, these therapists, are we talking about psychiatrists? Like, is there medication involved?
Yeah, it is a care team. So each patient that enrolls, they get a coach, a therapist, and they have the option of a psychiatrist. Some choose to have psychiatry from outside, but we also offer psychiatrists for most of our patients. And that's one of the beautiful things about it. Traditionally you'd have to see your therapist, and you have to go talk to your psychiatrist, and they're not communicating. And so for our system we have a care-team approach to providing care for those patients and their families. One of the reasons we built our technology is because modern healthcare systems aren't built around that methodology. It's like, here's a visit note and here are the CPT codes, and I saw this and this is what's documented. But there's no opportunity to say, how's the patient doing? If the psychiatrist does prescribe medications, and we don't prescribe all of them, but a certain range of them, our coach, who then meets with the patient a couple times a week, understands that they're titrating and can monitor the patient and communicate that back to the psychiatrist.
But these clinicians don't work for you directly, I assume?
They are, yes. Our therapists are W2 employees. Our coaches are W2 employees. So we're expanding insurance networks and we're fully employing our clinicians here.
How many clinicians are you guys employing at this point?
The company itself totals a little less than 400 people. A little more than 200 of which, and I don't have those numbers exactly right, are clinicians. There's a difference between coaches, who are providing clinical care, and our licensed clinicians, which are therapists, and then our psychiatrists, which are MDs. But we put them all in the same bucket, so around 200.
How old is the company?
A little less than five years, or five years.
Five years? Okay. So right as the pandemic hits, which is the age of anxiety, you guys kind of step in. I have anxious children. This feels like a very necessary thing.
I'm not one of the founders, but when InStride was first founded it was not meant to be virtual, and then the pandemic hit, and it was like, oh, this has to be virtual for this to work. And I think it was a really great move, because now we can provide care at just an incredible scale in a way that you couldn't before. The stigma around virtual has changed. And yes, it's really unfortunate: there are a lot of sick kids out there suffering from anxiety, OCD, and many other things that are all related in that same family.
And I imagine clinicians are focused in major cities, so suddenly this opens it up. There are anxious children everywhere, not just in places where there are enough healthcare providers for them.
Yeah. So we open access to people who are in more rural areas, but we also provide very, very high quality of care, and waitlists that are much, much shorter. In a more traditional sense, if you were to go to a program that was in person, maybe they can see nine patients at a time and the waitlist is six months. And so even in high-density metropolitan areas, we're still providing a level of care and access to care that was previously unavailable.
All right. So this company starts and you start working on it, and AI, machine learning, is not... yes, machine learning is a thing, deep learning is a thing, but AI and OpenAI have not launched yet. Suddenly these technologies come screaming onto the scene about two years ago, but really start getting in gear, I would say, the last six to eight months. How are they affecting you as a CTO, and InStride in general?
Immensely, right? Everything is now around these new tools. One of the things that's really interesting for us, and I think we did this right, is that from the beginning, data is always really, really important. You want to make sure that whatever tools and systems you're using, you're collecting the data, you're cleaning the data, you're analyzing it, you're able to do something with that data. And with AI that just becomes even more important, an even more compounding factor. So we built our data system very, very early on. On top of it, the proprietary technology that we built: in healthcare, you either go big solution or a bunch of point solutions. We have a core system that then integrates with all these other point solutions. So when AI came on, we had the data already, and we had the system already connected to all the other systems. And so for us it was, okay, great, as long as we can figure out how to incorporate AI into our core system in a way that is strategic and smart and effective, we can use it in any workflow that makes sense for us. We don't have to provide it blanket access to everything. We can fully control what it's doing and how it's accessing that data. So the big thing for us was just wrapping my head around, what can it do, what can't it do, what is hype, what is real, what is not real? How do we approach this scientifically? How do we try this out, how do we pilot, determine if this is a fit or not a fit, and then move on from there? And eventually we're getting to the point now where we have real AI infrastructure built in. We have a few agents in production that are incorporated into our system and doing very specific tasks very effectively.
But what you're describing is an information environment where there's so much stuff coming out, new tools. Plaud's the best this week, Codex is actually where we should be, 4.6, whatever is rolling out. Do you have a framework that you use to say, okay, let's look at this, how am I going to determine if I want to incorporate this? What do you do in those circumstances?
Yeah, it's core technology best practices, the iterative, agile approach. What is the hypothesis? We think that this tool can do X for us. Great. What is the smallest way for us to validate that it can do that? Let's pull a pilot together, pull a group of people. Being a startup, you can grab some people who are also very excited and motivated by this, tell them, this is what we're doing, this is how we're doing it, this is how we're measuring success. You take a survey before, you take a survey after, and then you say, does this work? So one example: we tried to use voice AI for outbound calls to insurance companies, because we are value-based care. We have specific contracts, we're not fee-for-service. We can't just say, this CPT code gives us this amount of money. It's complicated, we have a lot of custom things. One of the things we were struggling with is visibility into how much the program is going to cost out of pocket for patients and families. And one of the best things to do is just call the insurance. When we call the insurance, we have to go to the specific line, then go in the InStride number, then get that information. And we were like, AI probably can do this. So we spun up a pilot really quickly. We didn't build it ourselves, we worked with a third party who was also a startup, and we said, let's call these nine insurance companies and see what we can get. After a week they're like, well, these four insurance companies won't work because of X, Y, or Z. Okay, so we'll do these three. And then at the end of the day they're like, well, of all the insurance companies you called, this whole data set, only 20% actually returned data that we think is successful. So yes, it does work for these specific use cases, but not really. And we're like, okay, put this down. We can pick it up again in a year when AI is better and everything is different. But right now this is not worth pursuing, whereas there are companies spinning up around, oh, we'll just do AI voice everything at this point. For us, in our specific use cases, it just was not a viable option.
So it basically works out that AI is great in a vacuum, if the rest of the world didn't exist, if you didn't have to interface with the rest of the world and deal with their legacy product, their protocol, their systems, their AI. Sure, it might work, but...
That was actually one of the funniest things about this pilot. What worked most successfully was when there was an AI agent on the other end of the line too. So our AI agents talking with their AI agents, because then it was just two phone trees going at each other and coming to a solution at that point. It's like, why isn't this just an API? If we have our system talking to their system, an API is more effective, it's more consistent, we have a contract here. When we talked with people that didn't know how to interact with it, it was unclear, it was not a very good result at the end of the day. But it was really interesting to see that, oh, they have a phone tree and we're using AI agents, and that is consistently the best outcome for this.
Right. So what you're talking about is this era of the translation layer. How do I take this new technology and make it interact with old technology? But ultimately the goal is, this needs to talk to this in this way to be most effective. So at some point we're going to need to upgrade everything to interact, or build. What is the medium for AI to interact with other systems most effectively?
Yeah, exactly. Or, we're interacting with this old technology, which is also evolving and changing in a way that's hard to predict, because everyone is trying to do all these different things with all these different tools. And, trying not to forget, we have technology systems and protocols that have worked and continue to work. Sometimes it's like, well, we can do this with an AI methodology instead. Great if that works, but also, is AI the right tool for the job here? In certain cases, absolutely, it's a great tool. In other cases, no, a standard REST API is perfect for what we're trying to do. Just because we can use AI doesn't mean it's the right tool for this job.
We are at the cusp of starting AI's validation phase. That means different things, I imagine, for different companies. For a company like yours, what does validation of AI tools mean?
Yeah, it's complicated, because in healthcare everything is complicated. There's the bottom line: are we seeing the right ROI with these tools when we're applying AI to this process? Does that make us more efficient? Does this get us more revenue? How does it actually change what we're doing or affect how we're getting paid? And then there's the clinical outcomes. We are very lucky, we have fantastic clinical outcomes. It's one of the amazing strengths of InStride. So when we're applying AI to clinical workloads, we want to make sure that, one, it is improving outcomes, or at least not worsening them, and making our clinical team more efficient and effective. But that's a more nuanced thing. We don't ever want to apply AI to something, have it improve our bottom line, and make our actual outcomes worse. So validation here is staying very good with our outcomes in a way that continuously builds trust with patients and families, because we don't want them to say, we don't want to work with you because you're using AI. We want to use AI in ways that help the situation, not just, hey, here's more technology thrown at it. And then on the administrative side, we want to make sure things are moving more smoothly, more effectively, more efficiently. Or, if we can use it to get a better conversion rate and a higher number of enrollments, that's also a win.
I mean, you're living in the valley. Are we going to see a lot of crash-outs in this validation era, from your perspective? Like, some people aren't going to make it.
I mean, that's always true with startups, absolutely. If you were to say everyone who's doing AI right now is going to be successful, that's definitely not the case. What I've seen and experienced personally is that the people closest to the problem, who are looking at ways to apply AI for specific problems to get to specific solutions, are seeing a lot more success, because they can iterate faster. They know what that success looks like, versus the more generic, general, we're using AI as a thing. This is true for any startup in technology: you need the product-market fit, you need the traction, you need customers to acknowledge whether this is successful or not. I don't think that's different. I think there's more of it and people are building faster. As much as people have tried and failed before, that's going to continue. I don't know if AI is dramatically reshaping that, but it's definitely compounding the fundamentals of building technology for a population.
The last thing I want to get into, and I'm on my own product-market journey at the moment: you mentioned in our initial call that you only hire people based on being endemic to these tools. If I'm going to hire an engineer at this point, they need to understand the fundamental frameworks, they need to use the tools most effectively. So trying to understand what the engineer, the software developer of the future, looks like is kind of the ball game right now. We also talked about the Series B wait-and-see moment, because we don't actually know what the future engineer needs to have, so how do we know what to hire for? What is your gut telling you? If you had unlimited money and we're hiring tomorrow, who are you hiring for?
It's a really good question. In terms of who I'm hiring for right now, I don't think it's realistic to say you have to have X years of experience using these tools. But you have to be able to talk about it with some intelligence. You have to have experience. You can say, oh, I've used it here and it's been successful, I've used it here and it's been not successful. I don't want someone who's like, I've never used this tool and I never will, absolutely not. And I don't want someone who's like, I use it for absolutely everything, it's the best thing ever. Those are not the right ways of going about it. So when I'm looking for someone, I'm looking for someone who's willing to grow and change and adapt with this, because, like you said, we don't know what's going to be at the other end of that, and anyone who tells you they do is either getting really lucky or lying to you. So hiring right now is about people who are willing to go through that evolution and journey and keep an open mind about how to evolve. You have engineers right now with 15, 20 years of experience who are like, I am now completely new at my job, this is all very much the beginning again. And you have others with decades of experience being like, I'm not touching it, I'm so good at this, this is what I'm doing. You want the person who recognizes that they're starting over from scratch. In terms of the unlimited funds, that's a more complicated question, because it honestly depends on what we're trying to do at InStride. We're not a massive company with a massive tech team. So in terms of who I'd be hiring, I'd be hiring someone who has some semblance of experience deploying these things in production successfully. I don't think that's a really big field, but you said unlimited money. It's not like we need that to be able to do it, but we need it to be able to do it more quickly, and experience helps you navigate around pitfalls and avoid delays and blockers.
That's the level of experience that would be really beneficial. However, if you have a good team who understands how technology works, understands those core principles, you can get to where you need to go. It's just going to take a little bit longer.
Part of that: we're six months to a year away from having a large enough core of people that have shipped product, AI product, successfully. Plenty of people will have shipped.
Exactly. Successfully is the really big difference there.
Yeah. I wonder how we start measuring that. Like, I not only shipped a product, it was a successful thing by these metrics. It's not the amount of code I produced, it's everything else around it.
What's the difference between shipping an AI product successfully versus just shipping a standard technology product successfully? At the end of the day, the business metrics shouldn't be different. Maybe the numbers could be bigger, but the general things are: are you affecting your margin, are you trying to get more customers, are you trying to build something that can do X, Y, or Z capabilities? That's how you're being measured. It's all about the outcomes, not so much about what you did. What we'll see is that the people who can deploy successfully are the ones who understand that AI can solve this problem, so we're going to deploy it in this way. Where the failure is going to come is when people say AI is going to solve this problem, even if they don't know it will, and are just going at it. So the metrics of success, I think, are the same, maybe more extreme, maybe slightly different, but just because it's AI, I don't think it should fundamentally change what success looks like.
Thank you so much.
Be part of the
conversation.
Whether you're a CTO who wants to be featured, a company looking to sponsor, or an engineering leader wanting a seat in the room — there's a place for you here.