Peer AI + 4D Molecular Therapeutics: Why Most AI Pilots in Medical Writing Stall

Overview

Most pharmaceutical companies have launched AI pilots for medical writing. Few have moved beyond them.

This webinar, presented by Peer AI in partnership with 4D Molecular Therapeutics, examines the structural reasons AI pilots stall in regulated writing environments, and what distinguishes the implementations that achieve sustained adoption.

Drawing on cross-industry patterns, our presenters will walk through the most common failure modes: misalignment between AI capabilities and writer workflows, underestimating the role of institutional knowledge, over-indexing on speed metrics at the expense of quality and trust, and deploying tools that ask writers to change how they think rather than how they work.

Viewers will leave with:

• A practical maturity framework for evaluating AI readiness in medical writing organizations

• A clear view of the organizational conditions that predict successful scale-up

• An understanding of why the transition from pilot to production depends more on change management than on technology selection

Speakers

• Catherine Campbell - VP of Regulatory Affairs, 4D Molecular Therapeutics

• Anita Modi - CEO and Co-Founder, Peer AI

Transcript

[00:01:00] Anita Modi: Thank you, everyone, for joining our webinar here at Peer on AI pilots and medical writing. I’m thrilled to be joined by Catherine Campbell from 4D Molecular Therapeutics today.

A quick note on housekeeping: you should see a Q&A option at the bottom of your screen. If you have any questions, please add them there, and we’ll go through them as we go or at the end. We’re also recording the webinar so you can reference it later.

With that, let’s jump in. I’ll start with some quick introductions. My name is Anita Modi, and I’m the founder and CEO of Peer. I’ll share more about Peer shortly, but we started the company about three years ago. Before that, I spent about two decades building technology specifically for this industry, most recently as Chief Quality Officer at Science 37 in the decentralized trial space. There, I worked with regulatory leaders across biotech and pharma, from starting pilots, which is the core of our conversation today, all the way through scaling into production. Those experiences are what led me and the team to start Peer.

Catherine, I’ll pass it to you.

[00:04:17] Catherine Campbell: Thank you, it’s a pleasure to be here, and thanks for inviting me, Anita. My name is Catherine Campbell, and I’m the Vice President of Regulatory and Quality at 4D Molecular Therapeutics. I’ve been in the industry for about 20 years, and I’m looking forward to this discussion today. Thank you.

[00:04:33] Anita Modi: Wonderful. Before we dive in, let me give everyone a bit of background on Peer for context.

As I mentioned, we started the company about three years ago, with the advent of generative AI and what’s now known as agentic AI. This is a company and a product built by regulatory experts. Our founding team comes from places like Vertex, Veeva, PPD, and Syneos, and is joined by an engineering team led by people from Google, Facebook, and Microsoft. We brought that expertise together from day one to think about what a solution for regulatory submission documentation should look like.

The platform we’ve built is used to draft regulatory documents from the preclinical and CMC side through clinical, and it’s designed with a full interface for regulatory experts to interact with agentic AI across the workflow.

It’s been a privilege over the last three years to work with companies from mid-sized biotech through larger pharma across many of these use cases. We’ve seen the value AI can bring in speed, when we look at the reduction in drafting time, but really in quality, which is what much of today’s talk will focus on. We’ll spend some time on how you actually evaluate quality when you’re dealing with AI-generated content. It’s been an incredible journey.

If you’re interested in a demo or in learning more about Peer, please reach out to me or visit our website at www.getpeer.ai.

With that, I want to shift to the main focus of today: the P-word, pilots. Anyone who’s worked in innovation in life sciences is familiar with the term, especially as we’re all on the frontier of AI adoption and the role pilots have played in our industry. Today, we want to focus on what it means to go beyond the pilot, and what the factors behind success ultimately look like.

We’ll approach it in a few ways. I’ll talk about some of the patterns we’ve seen at Peer for why pilots stall. Catherine will share 4DMT’s framework for pilot readiness and evaluation. And then we’ll share our perspectives on what successful, scaled implementations have in common. We’d love for this to be an open discussion, so please use the Q&A to share your perspective as we all continue to learn on this frontier.

So let’s jump in.

At Peer, over the last three years, we’ve worked with many companies at the piloting stage. We’re big believers in the pilot. Right now, when AI is so new to many workflows and companies, it’s important to start understanding what AI can mean for your organization, and to benchmark what that looks like in terms of value across multiple time horizons.

But there are many reasons pilots tend to stall, and it’s important to design pilots in the right way for your organization. I’ll share more on each, but some of the themes we see are: workflow misalignment, using pilots to evaluate tools based on capability rather than workflow fit; institutional knowledge gaps, surfacing gaps in knowledge and how it gets built in; the wrong metrics for determining pilot success, where companies often look at speed alone rather than a fuller set of metrics; and fourth, cognitive restructuring demand, which is about why writers resist, what makes these pilots stall, and how to avoid moving into production for the wrong reasons.

Let’s jump into each of these.

The first is workflow misalignment: the tool is evaluated on what it can do, but not on how it fits into how writers and teams actually operate. The key thing we sometimes see is the question of what a writer or team is ultimately doing with the generated content. If they’re still verifying every single sentence against source documents, we haven’t actually changed the workflow; all we’ve done is add a step.

So it’s important to ask what the workflow looks like with AI, and whether we’re evaluating the pilot around that alignment. What we’ve seen, when it doesn’t happen or is misaligned as part of the evaluation, is that the speed gains being measured disappear. Worse, writers and users disengage, because you’ve created a step rather than thinking holistically about what the workflow should look like.

The second reason is institutional knowledge gaps. Everyone in this seat knows that medical writing isn’t just about text production. It’s a reflection of an organization’s accumulated judgment, based on the history of its experience. This shows up in a lot of ways. Most obviously, it’s compound-specific history and clinical positioning: the history, the detail, and the conversations specific to your compound and your organization.

Often, by the time we’re working with companies, they have deep knowledge of their engagement with regulators and of agency reviewer preferences that may not be captured anywhere. It’s accumulated judgment about what makes sense as they approach various regulatory submissions.

At Peer, we’ve worked across therapeutic areas, and we know there are conventions specific to each one, again, accumulated judgment that builds over time working in a specific domain.

And this one is probably closest to many of our hearts: internal reviewer sensitivities. Every organization looks so different, and these documents are highly cross-functional. There are often sensitivities among various stakeholders, all for good reasons, that need to be reflected in how writing is done. So it’s not just text production; it’s the accumulation of this kind of judgment.

What we’ve found, especially in pilots, is that AI tools trained on more generic data surface this gap the moment that complexity and accumulated judgment need to be represented. It’s important to account for that, even in pilot design.

Next, the wrong metrics. From the moment AI entered our conversations, it was synonymous with speed. The issue we’ve seen in pilot evaluations is over-indexing on speed. We’ve seen pilots designed to measure time alone: What’s the time to first draft? What’s the turnaround-time reduction? We’ve seen companies measure the number of pages authored, or in one case even paragraphs authored per document.

These are all important; they show the work being done. But our view at Peer is that it’s equally important to consider the aspects beyond speed. In cases where pilots stalled, it was because the things that weren’t measured were writer trust in the output, which is a reflection of quality; reviewer acceptance of AI-assisted documents, and what happens downstream; and what that downstream quality actually looks like from a measurable perspective. There’s also scalability: if the pilot is one moment in time to benchmark for your organization, how are you measuring what it looks like at scale?

We’ve seen cases where trust problems emerged later and were attributed to the tool, when really there hadn’t been enough emphasis on quality or scale in the evaluation design.

Finally, the fourth aspect: cognitive restructuring demand, or tools that change how writers think. Having been operators in this space for the last few years, we know some tools ask writers and teams to restructure their entire cognitive approach and to think with AI from the start. When that happens and pilots meet resistance, the assumption becomes that writers are resisting because they’re change-averse.

In reality, writers resist because they’re protecting expert judgment and the way their cognitive process works today, all for good reason, going back to that accumulated judgment. What we’ve seen work, and the pilots structured this way ultimately scale into production, is meeting writers where they are: embedding AI in their cognition rather than replacing it, and thinking about how the expert and the AI work together in a workflow to get to the best place, fastest.

So those are some of the reasons we’ve seen, across our experience over the last three years, for why pilots haven’t progressed. The theme is that they aren’t failures of adoption; they’re failures of design. And, I’ll come back to this at the end, the organizations that got past the pilot stage didn’t have better writers, more expertise, or better technology. They entered the pilot phase designing for integration, and for production, a little differently. It was really about intentional design from the start.

One of my favorite examples of being intentional about pilot readiness is the experience we’ve seen with 4D Molecular Therapeutics. So I want to turn it over to Catherine to share their experience.

[00:14:38] Catherine Campbell: Thank you, Anita, I appreciate it. Today I’ll walk you through our experience at 4DMT evaluating an AI solution for our company.

First, I’ll talk about the key drivers that enabled a successful AI pilot. The initiative was anchored in solving a critical business need, with a simple goal: accelerating our BLA submission timeline despite having no medical writing group in-house. Its success was supported by strong executive and cross-functional endorsement, the necessary financial investment, the infrastructure to integrate AI into our existing systems, and, importantly, a champion to lead the implementation. Finally, the value proposition was clearly demonstrated through substantial time and cost savings, while maintaining comparable quality and enabling scalability.

At a high level, here is the evaluation process we used to identify vendors and assess the AI-generated outputs. We initially identified 10 vendors with out-of-the-box capabilities suitable for our purposes. We interviewed each vendor, attended live demonstrations, and conducted capability assessments. From that group of 10, we narrowed it down to 4 for a pilot trial, in which we evaluated AI-generated CSRs, or clinical study reports, against a human-generated clinical study report.

The pilot trial consisted of the following workflow. First, we shared and uploaded our source documents: the protocol, the statistical analysis plan, and the TLFs, which are tables, listings, and figures. The AI agent then generated the first-draft CSR, which was generally verified by the agent. The last step, which was critical to our evaluation of the four vendors, was the human review.

This is the step where we did a comprehensive evaluation of the AI-generated output. It was the most time-consuming part of the process, but the most important in our final decision. We conducted a thorough assessment of each AI-generated CSR against more than 50 qualitative and quantitative performance metrics, including accuracy, completeness, readability, and consistency. The evaluation was conducted by a cross-functional team spanning regulatory, clinical sciences, and quality assurance, to ensure an unbiased, balanced assessment.

The results are interesting, because we provided the exact same input to each of the AI systems, and the output was sometimes similar but sometimes substantially different. At the end of the day, we selected the vendor with the best-quality output that would meet our accelerated deliverable timelines, and that was Peer.

There are limitations to AI. Here’s a side-by-side example of conclusions generated by two separate AI vendors, and I’ll remind you that the inputs were exactly the same. In the first CSR, the agent highlighted a high frequency of ocular and systemic adverse events, a progressive decline in all cohorts, and no evidence of dose-dependent improvement. The CSR generated by the second agent used much more muted, neutral language. That was actually more in line with our own conclusions, because the CSR was for a small Phase 1 clinical trial in a patient population that has no alternative treatments.

This shows how critical it is to have a human in the loop. The AI agent can contribute execution, speed, automation, and scalability, while human intervention is critical for judgment, interpretation, key messaging, and decision-making. You can see that from the examples I just gave, where the interpretation is so critical.

On our project timeline: overall, this project took about 8 months from kickoff to vendor selection. We probably could have gone faster with more dedicated internal resources, but at the end of the day, it was still much faster and much cheaper than developing a custom in-house AI solution.

Finally, I’ll end with a few lessons learned from our experience at 4DMT. First and foremost, the project needs a champion who will lead the due-diligence efforts and drive execution. This is so important. Early engagement with the executive and cross-functional teams is also critical. It’s important to involve key stakeholders from the beginning; having medical writers, clinical sciences, regulatory, and quality assurance all included from the initial assessment was really helpful in our situation. And finally, take a long-term view to ensure there’s a workflow fit, and establish internal governance around the use of AI to enable a smooth integration.

That’s the end of my presentation.

[00:21:12] Anita Modi: Thank you, Catherine. I’ll reflect that all of these lessons learned were so clear to us when we first engaged. Catherine, you said: we know AI will be fast, but how do you really think about quality? How do we think about what this means for our cross-functional team? Bringing that into both the discussions and the evaluation criteria from the start is so important.

With that, I want to reflect a bit. I shared some thoughts on why pilots sometimes fail or stall and don’t move forward, but the implementations that worked had things in common, and this rolls up many of the things Catherine shared. There are four conditions we’ve seen across the board in successful cases of scale-up.

The first is change management. It’s no surprise that AI is a change. Even with the easiest-to-use tools, it’s still a workflow change. What we’ve seen is that change management preceded deployment; it was part of the conversation from day one. What does this mean for our process? What does it mean for our team? It means having writers, and anyone else who’d be part of the process, involved in the design, not just trained after the decision has been made. Conversations grounded in change management are one of the key things that lead to pilots resulting in scale.

The second is that quality validation is built into the pilot. You saw 4DMT’s evaluation framework; there are so many ways to look at quality. It’s not just “is it faster,” but “can we maintain regulatory quality as we progress?” This has been core to our thinking at Peer from day one: How do you measure quality in something that can feel subjective, and can you actually measure it and bring a quantitative framework to it?

The third is someone owning the integration layer: owning not just what this means for our workflow, but how it fits into how our workflow and our team will continue to evolve. In many organizations, we see efforts to train writers on AI in general and to adapt SOPs, but actually having someone who owns the integration layer, and who understands tooling capabilities and how they fit, has been critical for scaling up and deployment.

And the last aspect is writers co-owning the knowledge and the rollout. We talked about institutional knowledge; this means treating it as a team and company asset, and co-designing what deployment looks like as an organizational change project.

All of this points to something. We at Peer, as technology builders, know that technology selection is important. But if we step back, the transition from pilot to production depends more on change management, and on ensuring that technology selection fits into that model of organizational change.

One thing we’ve talked a lot about, socialized, and helped our customers with is a framework for assessing maturity. It’s not a score so much as a language, or a way to assess AI readiness. We look at four dimensions of readiness and maturity, and we think it’s important to have these conversations even at the pilot stage.

The first is workflow integration depth. Is AI sitting at the edges of the workflow, or deeply embedded within it? It’s fine to start in one place and evolve, but what does that look like, crawl, walk, run, in terms of depth?

The second, and maybe the most critical to me, is whether your writers and team are using these tools because they want to and see the value, or because it’s being mandated. Trust and engagement at every level are critical for AI readiness and adoption, and it’s important to bring that voice into the conversation even at the pilot phase.

The third is what maturity looks like in terms of quality validation. Is there explicit criteria for AI-assisted output that can be defended within a company, today or a year from now, across a team, even as you grow across use cases and across the organization? We’ve thought a lot about this at Peer and have our own framework. We actually just released a paper in the AMWA Journal last week on our view of quality and how to start measuring it. We think this is one of the most critical things for AI readiness. More than anything, it gives a common language that lets everyone in the organization talk about quality hand-in-hand with speed.

And then, again, change-management investment. A lot of this can be assessed by who’s involved, and at what point. Are you treating the deployment as a tech rollout, similar to other technology solutions you’ve had before, or as organizational change, in which case you’re talking not just about technology, but about people and process, and a journey to get to that end state? We’ve found this framework helpful even at the pilot phase, as we talk about AI readiness and maturing into production.

So, our guidance, as many of you look at both pilots and scaling, is to do a few things within your organization next week. The first is to have a conversation with your implementation team and your AI vendor, and really everyone involved in any deployment, about this question: Are you changing your workflow, or fitting into existing workflows? It’s fine to change workflows, as long as it’s a very intentional discussion about how things fit together.

The second is the internal conversation on quality. Ask your QA lead and your cross-functional partners: What does acceptable AI-assisted output look like, and how will we continuously measure it, not just in a pilot, but as we continue to bring in AI?

And third, we think this is a helpful exercise, ask your writers. We’ve seen organizations get on a whiteboard, look at old submissions, and ask: What parts of this process would you trust with AI, and what would you not? Looking at previous projects and submissions and breaking this down into columns on a whiteboard has been a great exercise. It gets everyone aligned around what AI can and can’t do, and it reframes the conversation around where you can start to see the most value with AI in your workflow over time.

As a reminder: the pilot isn’t the destination. We often talk about it as one piece, but it really is the start. Over the last three years especially, we’ve recognized that the pilot phase is a comfortable place. It’s lower stakes, it’s easier to walk back, and it feels like progress without having to make hard commitments. But given how quickly our industry is evolving, the window for using that pilot phase is closing, and we’re seeing that the organizations moving past it and scaling intentionally are starting to see a compounding advantage. We’ve now worked with customers seeing document-over-document value, in both quality and time, because they were able to start and very intentionally scale quickly, across both technology and change management.

I’ll leave you with this: the question isn’t whether AI will work, it’s whether your organization is building the conditions for it to work. Even at the pilot phase, we think that’s really critical to evaluate, to ensure you scale from there.

With that, I want to thank everyone for joining. If you have any questions, please continue to put them in the chat or jump in.

I’ll kick us off with one question while others come in:

How do you evaluate the ability of an AI technology to scale to meet different program needs?

Catherine, do you want to share your thoughts before I do?

[00:30:18] Catherine Campbell: Sure. AI really isn’t the gating factor for scalability; that’s not an issue. Can AI scale? Yes, absolutely. What we’re working through right now is the optimization process on the front end: making sure the output we want is what comes out, the best quality possible, with the best messaging aligned to what we’re looking for. So we’re spending a little time up front optimizing, so that every subsequent CSR or document generated is essentially just click-and-play. That’s our goal. But scalability isn’t a problem with AI; that’s what it’s built for.

[00:31:11] Anita Modi: I agree. From our seat as a technology partner, a lot of what we do where we’ve supported organizations is sharing what we have today, but also sharing our roadmap, and ensuring it’s aligned with how they’re thinking about scale at the enterprise level. I completely agree that technology is one piece, and it may not be the gate, but based on roadmap, team, and track record, we’ve been able to share what scaling looks like across multiple time horizons. Great question.

Next question:

What have you seen work best for getting writers to trust and adopt AI tools?

Catherine, do you want to share your perspective, and then I’ll jump in with some ideas?

[00:32:03] Catherine Campbell: Sure. From my perspective, it’s simple. We actually didn’t have medical writers in-house, but bringing people on board from the beginning was critical in our project. We brought on the clinical sciences team, which traditionally did the medical writing at my company, and having them in the project from the beginning was critical, so they felt a sense of ownership.

[00:32:31] Anita Modi: For me, it comes down to how you always build trust around something new. Someone once told me it just has to work; it has to work consistently and repeatedly. What works best for getting writers to trust AI is to demonstrate that. That’s why we believe pilots are a great tool: they give exposure to the reality, demystify what AI can and can’t do, and build trust from a place of quality. It really comes down to using it and building that experience and AI fluency. Great question.

Another question:

If a team wants to move from pilot to production, what are the earliest signs that the workflow and change-management pieces are actually in place?

[00:33:36] Catherine Campbell: Good question. We did the same thing we did with the medical writers: we brought in our IT group from the very beginning, so they were there to evaluate the vendors. They understood the process and how this would fit in. We didn’t start writing our SOPs before we implemented a solution, obviously; we did that afterward. But we had IT and our systems people with us the whole way, so we could start thinking about how this was going to work.

[00:34:16] Anita Modi: I agree with all of that. Some of the earliest signs we see are an openness to questions, almost sitting back down and redefining roles and responsibilities. What does my role actually look like after this? Where can I start to take things off my plate? Where do I shift into more strategic parts of the job? Even an openness to have that conversation, or to do that exercise, shows us this is a good fit for scaling AI more widely, and that you’re open to some of the change-management aspects.

The other sign we see is companies, across the board, whether they’re our use case or not, investing in AI literacy. Even bringing in tools like Copilot, ChatGPT, or Claude, just to get the team comfortable with what AI can do, is often a way to start bringing in change management and a shared language. Is that something 4DMT has done as well?

[00:35:34] Catherine Campbell: Yes, we’re doing that as well.

[00:35:39] Anita Modi: Next question:

How easy was it to align stakeholders around sharing data and protocols with external vendors for AI training?

[00:35:51] Catherine Campbell: That wasn’t much of an uphill battle for us, because most of the vendors we evaluated had secure systems, so we weren’t worried about data leaking or integrity. The other thing I’ll say is that most AI vendors use a closed-loop system, where the agent doesn’t have access to external sources of data, only your data. So hallucinations don’t happen the way you’d worry about with using, say, Google. It’s different; that’s not going to happen in these AI systems. From that perspective, we felt really comfortable with the vendors we shared our data with.

[00:36:41] Anita Modi: I think that’s right. From our perspective at Peer, we’ve invested a lot in security and in ensuring we’re SOC 2 compliant. But one note: the language in this question is “AI training,” and we’re very strict, we don’t actually train on customer data. We learn from the relationships between data and content, but we’re not training on the data itself. That’s a really important distinction when you’re talking about sharing data and information. It’s worth digging in with every vendor: How deep do your security practices go? How does your architecture actually use our information? Do you learn from it? Do you train on it? It’s a good place to bring in your IT experts to help with those conversations. Many vendors like us will at least be very transparent about how we’ve built our architecture.

[00:37:45] Catherine Campbell: That’s a really good point, Anita. It’s important to make the distinction between AI training and optimization.

[00:37:53] Anita Modi: Yes.

[00:37:53] Catherine Campbell: They’re not the same.

[00:37:56] Anita Modi: Exactly. One more question:

You talked about how critical it is to have a human in the loop. How do you decide which parts should stay human versus AI-led?

Catherine, you brought this into your evaluation, so maybe you can start.

[00:38:15] Catherine Campbell: Sure. The agent is good at generating a first-draft CSR, but that’s where we take the output and bring in the human factor: the reviews, the adjudication, the alignment on key messaging, the small intricacies. Messaging is so important at the end of the day, and refinement is where humans are really good, versus where AI is maybe less good. One other point: at the beginning of the process, we’re doing 100% QC on the data. But once we get comfortable that the data is always 100% accurate, we may reduce that QC step, maybe doing only spot checks, or removing the step altogether to compress the timelines even further.

[00:39:22] Anita Modi: Absolutely, I agree with all of that. A couple of notes: AI is only as good as the data it has, and going back to that point about accumulated judgment, some of that can be captured in source data, and in our platform, we capture it over continued usage over time. But there’s a need to have human experts in the loop, because for every document and every use case, there’s a whole set of accumulated judgment that has to be applied. AI can help with initial mapping of data, initial content generation, and initial QC, but it’s really important to have that strategic lens, which will only come from an expert team.

We’ve thought a lot about that, and it’s why we built the company with a whole team of experts to weigh in on where we can trust AI reliably and consistently from a quality perspective, and where and how you have to have an expert in the loop. There’s a lot of discussion about human-in-the-loop in this industry, and our view is that not all loops are created equal. It’s really important to be intentional about when an expert is involved, and how.

Catherine, you talked about human QC, and I think that’s spot on. When we started the company, we did 100% QC of all the content we were generating, until we got to a place where we felt comfortable. It goes back to that point about trust: once you see it work over and over, you feel comfortable. It’s very analogous to hiring someone new on your team and thinking about when you QC what, and getting comfortable with that person. AI is a peer, that’s why we named the company the way we did, and I think it’s the same mental model.

[00:41:20] Catherine Campbell: That’s a good point. And nothing is free from human error, right? It happens, it’s normal; we’re all human, we make errors. This is one of the benefits of AI: the accuracy of the data is going to improve versus human-written content.

[00:41:39] Anita Modi: All right, let’s see if there are more questions. Okay:

Were any of the training data and documents in non-digital or handwritten formats? And did you face any challenges when handwritten documents were used?

[00:41:58] Catherine Campbell: Maybe you should take that one.

[00:42:00] Anita Modi: Happy to. In the case where we were working with 4D Molecular Therapeutics, it was all in digital format. But stepping back to our broader experience at Peer, we’ve seen the whole range: scanned PDFs, some handwritten documents, the full range. Overall, we’ve done a pretty good job taking in the full range of data sources. PDFs, scanned PDFs, we’ve seen it all, and that’s been pretty successful. With handwritten documents, there’s a range, and it depends. We’ve been able to advance quite a bit on taking those in with a high level of fidelity. From our perspective, a lot of what we do when we set up a deployment with a customer is to ensure we can consistently hit a level of quality in data ingestion and processing, because the reality is that many documents have been handwritten.

I’ll take this question as an opportunity to add some fun source types we’ve used. We’ve done things like meeting recordings and voice notes, in cases where we’ve written documents like protocols, where a lot of the discussion and intention behind them comes out of team meetings. That shows the balance of how you can think about what source data looks like for AI to apply, and how you can be a bit more creative about how you plug into workflows as they exist.

[00:43:39] Catherine Campbell: That’s really cool.

[00:43:43] Anita Modi: I’ll pause to see if there are any other questions. I think we’ve hit the ones in the chat.

All right. First and foremost, I want to thank Catherine again for joining me here at Peer and for sharing your perspective, which I think is really mature given what we’ve seen in the industry. Thank you for sharing that.

[00:44:09] Catherine Campbell: Thank you for inviting me.

[00:44:10] Anita Modi: And thank you, everyone, for joining. We’ll make this recording available as well, and we appreciate the continued discussion.

[00:44:19] Catherine Campbell: Thank you.

[00:44:19] Anita Modi: All right, thank you.