← All speakers

Bio, Work & Ideas

Christopher Lovejoy

Conference affiliation: Notius Labs · 2026

Christopher Lovejoy is a medical doctor, AI engineer, and member of technical staff at Anthropic, where he helps enterprises deploy AI agents as a forward-deployed engineer. Previously Anterior’s first technical employee and head of clinical AI, he builds systems that translate professional judgment into reliable software for medicine and other demanding industries.

Lovejoy studied medicine at the University of Cambridge and worked in Britain’s National Health Service before moving into data science and machine learning. His early healthcare-technology work included Cera Care and research on AI in mental healthcare, addressing diagnosis, monitoring, privacy, and clinical governance.

After his final medical shift in 2020, he pursued a master’s in data science and machine learning at University College London, worked as a data scientist, and taught healthcare AI, including guest lectures at UCL and Imperial College London. Through Entrepreneur First, he founded Billions Health, subsequently consulted for healthcare-AI companies, and joined the founding team of what became Anterior. His account of leaving medicine traces that transition from clinical practice to entrepreneurship and applied machine learning.

At Anterior, Lovejoy built the initial product and developed Florence, an AI assistant supporting medical prior authorization. He wrote early code and prompts, reviewed decisions as a clinician, and later led clinical AI. His work centered on situations where neither medical records nor insurance guidelines resolve the practical question alone: whether treatment qualifies as conservative, whether an intervention failed, or whether documentation satisfies a particular policy.

  • The clinical last-mile problem: General-purpose models can understand medicine yet fail on customer-specific terminology, clinical workflows, and insurance rules. Lovejoy’s approach to domain-native systems treats expert feedback and production context as essential infrastructure for closing that gap.
  • Adaptive Domain Intelligence Engine: At Anterior, Lovejoy developed an improvement loop that classifies failures in medical-record extraction, clinical reasoning, and rules interpretation. Clinicians identify errors and missing domain knowledge; engineers test targeted fixes against representative cases and monitor for regressions.
  • Reference-free clinical evaluation: Lovejoy built Scalpel, an internal dashboard combining medical records, guidelines, model outputs, and clinician critiques. His evaluation architecture uses expert-reviewed examples, model-based judgments, and confidence estimates to prioritize difficult cases and escalate uncertain decisions to stronger models or clinicians. His writing on evaluation mistakes emphasizes production-derived datasets and metrics tied to actual customer outcomes.
  • Oracle, Evaluator, and Architect: Lovejoy’s framework for incorporating domain expertise distinguishes experts who directly improve outputs, define quality and review processes, or design systems that learn from expert feedback. He argues that a principal domain expert needs meaningful ownership of product quality and consequential decisions.

His public projects include CodingForMedicine, which applies programming exercises to healthcare problems, and evidence-based-medicine-mcp, which connects language models to referenced medical information.

Read the topics behind these talks

4 conference talks

Key ideas

Scroll to read ↓

Domain expertise improves an AI product only when someone can turn judgment into changes. Oracle, Evaluator, and Architect roles offer three ways to organize that work.

  • How does clinical expertise become a better product?
    0:31 ↗
  • The opportunity depends on operational judgment
    2:24 ↗
  • Who assesses quality, and who improves it?
    4:43 ↗
  • Choose the role from the bottleneck
    8:48 ↗
  • Granola: one Oracle can remain central
    10:51 ↗
  • Tandem: distribute ownership across clinical contexts
    12:19 ↗
  • Anterior: scale assessment, then improvement
    14:14 ↗
  • Hire for the actual task and the adjacent work
    17:00 ↗
  • Give the expert authority and room to grow
    19:35 ↗

Key ideas

Scroll to read ↓

A clinical eligibility question shows how expert review, failure datasets and measured knowledge changes turn customer context into better LLM decisions.

  • Can the model understand this customer's workflow?
    0:15 ↗
  • The last mile inside a clinical question
    2:17 ↗
  • From a strong baseline to contextual refinement
    5:06 ↗
  • Measure consequential errors, then explain them
    7:10 ↗
  • Turn production failures into evaluation datasets
    10:35 ↗
  • Let clinicians propose knowledge changes
    12:02 ↗
  • Who reviews, and what tooling do they need?
    14:40 ↗
  • Give engineering a target and the PM a release decision
    16:43 ↗

Key ideas

Scroll to read ↓

A plausible MRI answer can miss the clinical distinction that matters. Anterior’s evaluation loop connects expert review, live confidence estimates, and routing before answers reach customers.

  • When a plausible medical answer is wrong
    0:00 ↗
  • Turn expert critiques into reusable reference answers
    2:16 ↗
  • Why reviewing a fixed fraction stops working
    3:18 ↗
  • Offline datasets preserve lessons after failures occur
    4:38 ↗
  • Evaluate before a human label exists
    5:38 ↗
  • Estimate performance, prioritize cases, validate the judge
    7:28 ↗
  • Put a validated evaluator in the delivery path
    9:01 ↗
  • Reported operational results
    9:45 ↗
  • Make expert review improve the evaluation system
    11:02 ↗

Key ideas

Scroll to read ↓

A successful healthcare AI demo still needs an architecture for audit trails, sensitive data, human approval and evaluation before it can become a dependable production system.

  • What happens after the POC succeeds?
    0:16 ↗
  • The questions accuracy cannot answer
    4:01 ↗
  • Make the audit trail the source of truth
    5:23 ↗
  • Keep sensitive objects separate from orchestration
    8:46 ↗
  • Give humans and LLMs the same action contract
    12:58 ↗
  • Evaluate from recorded state and real tasks
    14:47 ↗
  • Build back toward accuracy from production constraints
    16:48 ↗

References