On October 14th, 2026, Meta announced the results of a new project. A team of physicians wrote ten medical research articles using Meta Muse. I was privileged to be one of those physicians. It was an accomplishment for AI, but more than that, it was an accomplishment for humanity. This is what working with a frontier model on medical research looks like.
Full disclosure: I work for Meta as a Domain Knowledge Expert in Medicine, Meta Superintelligence Labs funded the work, and I’m an author on the team’s report. My account from inside the process isn’t meant as an independent evaluation. It’s more a testimony to what's possible with the right mindset, resources, and people.
What we built
First, a little bit about the project. The group was tasked with performing observational research, using Meta’s latest AI model, connected to a third-party database of medical records. Though it was a big ask, we completed 10 papers, prompt to manuscript, in under two weeks each.
I know what you’re thinking… Meta? Like Facebook, Instagram, Meta? That’s the one! After all, we all have access to Muse now… but we can’t all do medical research with it. So how was this different than a mobile app and a personal AI assistant?
What an ideal research team looks like
Typically, research is a lengthy process. A question occurs to a human who then looks for a way to answer it. In medicine, that can mean human studies or observational research using a database of medical records. For the latter, the data has to be obtained, organized, cleaned, and structured. Access has to be granted to researchers. Study data is then collected, and researchers begin the analysis process, often assisted by biostatisticians. It can take weeks to answer the question, then months to develop a manuscript and publish the work. It isn’t an ideal process, far from efficient, and often plagued with stumbling blocks.
What would it look like if that process were changed, completely rebuilt, to be more efficient? What would an ideal scenario for medical research look like? How many researchers would be needed? What kind of data? Would access to patients be necessary or just medical records? Would you need expert statisticians? Would you need software and engineers?
For us, the team of physicians included specialists in cardiology, epidemiology, infectious disease, internal medicine, oncology, radiology, and emergency medicine. In addition, we had a biostatistician to verify that our analyses were sound. Then came the engineers, the part most research teams never get. They built the interface and fixed problems as they arose. Critically, they also reviewed the work. A set of eyes focused on the model’s analyses and documentation of each step.
But then there were the people no organizational chart credits enough. You’ve met them. They are the people at your academic center who are not physicians, but who know the process, know the environment, know who to call for support, help log problems, and help with communication. We all have someone like this, someone whose job it is to keep things running. This team was no different. We had our project managers, working tirelessly, without whom none of this could be possible.
That was the dream team. Physicians, statisticians, engineers, and project managers all working with one goal.
The Data
What we had to work with was not a group of patients. We were performing secondary data analysis: Research using medical records for the purpose of discovering information that is helpful when treating humans. The database of medical records was obtained from a third party (Protege), and you can read more about it in the manuscripts and physician reports. In short, it was a massive database of 4.9 million patients, spanning 24 years and containing hospital, clinical, and pharmacy information. It was professionally de-identified, using numerous steps to protect patient identities, dates, locations, and more, per HIPAA standards. Additionally, an independent ethics review group determined that the study was not human subjects research, so IRB review wasn’t required.
That was the database we had to work with, and it was large. But size isn’t a complete picture. Every database has gaps, and we had to discover what those gaps were for ours. The physicians and engineers set out to define exactly what was in the database, how it was structured, and what was accessible for study. When we encountered gaps, we had to determine if the information was located somewhere else or was truly unavailable. And once all those issues were identified, defined, and catalogued, we needed workarounds, formulas, and cross-linking of records. Then we were finally ready to begin the work of asking clinical questions and looking for answers.
The day-to-day work
Connecting the AI to a large database essentially meant I had a research assistant and data analyzer with whom I could converse and run my study, 24/7. It wasn’t as simple as asking a clinical question and having the model spit out an entire study answering it. Far from it, actually. I would ask a clinical question or start a conversation about a topic of interest. After some back and forth, we would settle on the framing of the question. Then the real work would begin. We would examine the database, begin defining the population we wanted to study, and start framing the protocol, together. Sometimes Muse would educate me on the ideal method to accomplish the goal. More often, I would correct an assumption or an unusual conclusion. It was a long process of back and forth as we made our way through the multiple stages of clinical research. You can read more about it in our physician report.
Often, things progressed as you would expect. Ask an AI a question, and it provides an answer. As I’ve described numerous times in my newsletter, AI doesn’t have context unless you provide it. My conversations with Muse were no different. I provided the topic of interest, but I also needed to provide the environment, like the emergency department. I needed to provide some clinical context, like how the solution to this question was going to improve care. Then I needed to challenge and correct assumptions and decisions the model would make. I found the model to be exceptionally capable and naive. In medicine, we often say “Treat AI like a smart intern”. That would be a fair but incomplete characterization. I often asked the model to explain its answers. I frequently asked it to use less statistical jargon and more medical terminology. And I very often challenged. Not in a rude way, but in a critical way. Those challenges led to a far better analysis and result. Left to its own devices, my best guess is that the model would have been able to do about 60% of the work solo. But validating that work was a large part of the physician’s job. That was a critical step, and it often led to errors that needed correction.
In my study, we examined the risks to patients with behavioral health complaints who left the emergency department before being seen by a physician or provider. It is known that leaving without being seen places patients at increased risk. I was particularly interested in how that risk changed when we focused solely on patients with behavioral health complaints. Together, we found 1.3 million emergency department episodes. As you can imagine, looking through data for that many visits was time-consuming, and token-consuming! But the goal was accuracy, not conservation of compute tokens. Chat sessions would cross days, and span lengths far beyond a typical consumer session. When results were strange, slower than usual, or inaccurate, I would involve the engineers. Debugging sessions would often yield a cause, and we would adjust. Those iterations were key in making sure the model’s results were correct. As a physician, two of my most important tasks were validating the model’s responses and reorienting the model on clinical answers.
The team’s report lists more examples of where Muse helped and where human judgment took over, drawn from other studies.
Complete isn’t the same as trustworthy
You might be surprised to hear that validating the output of an AI model can be challenging. Then again, given how quickly AI advances, perhaps this isn’t surprising. Muse was extremely capable at analyzing data and performing statistical calculations. It was also, at times, extremely difficult to grade. The caliber of statistical analysis medical research requires is extremely high. If you are not accustomed to reading and interrogating it, the learning curve can be steep. Each study passed through author validation, internal peer review, biostatistics review, engineering review, and external peer review. Those layers exist because no single one sees everything. When published, each of our studies had passed through many human brains to confirm what the AI was telling us.
So why did we need a team?
Ultimately, the biggest accomplishment was not the AI model. Our accomplishment was blending the advanced skills of humans seeking to improve the health of humanity, the brains of engineers seeking to improve the skills of artificial intelligence, the capabilities of program managers, and a frontier AI model. The model supplied speed. The people supplied direction, judgment, and accountability. We needed both.
Ten papers at under two weeks each is fast. Independent replication on a second database would be the best test of whether the findings hold.