Chris Lovejoy · 02:37 Winning in vertical AI is fundamentally an organizational problem. It's not about chasing the best model — it's about how you embed domain expertise into the organization.
Chris Lovejoy's AI Engineer Europe 2026 talk is an organizational prescription for the uncomfortable reality that, even as vertical AI investment heats up, 95% of projects never reach production and are abandoned (Gartner 2025). Frontier models are already strong enough, RAG is everywhere — and yet "AI products that genuinely automate real-world workflows" still can't be built. The gap, he argues, lies not in technology but in organization.
Chris's career itself supports the thesis: former doctor → Tandem (UK's largest clinical AI, on a hiring basis) → Anterior (prior authorization automation startup, first technical employee) → Notius Labs. Three companies' worth of trial and error around "where to place the domain expert inside the organization," now distilled into the methodology presented here.
From the MEMEX editorial perspective, what matters is that this is a single unified theory describing the common pattern — "the domain expert sitting at the center of the organization" — that has been observed individually in Pedro Rodrigues' (Supabase) skill design, Mehedi Hassan's (Granola) feedback loop, and Brian Scanlan's (Intercom) 2x in nine months.
Three organizational models — Oracle / Evaluator / Architect
Chris's frame:
| Model | Role | Applicable when |
|---|---|---|
| Oracle | The expert edits the product directly — prompts, doc additions, tool configuration | Small scale, no objective metric, taste-driven |
| Evaluator | Designs the quality measurement system — metric definitions, review pipeline, engineer collaboration | Objective metrics exist, manual iteration still keeps up with the scale |
| Architect | Designs the automated improvement system — turns the evaluate-and-improve loop into an agent | Manual iteration can't keep up with the velocity and variation |
Case 1: Granola — the permanent Oracle pattern
At Granola (an AI meeting-notes product that crossed a $1B valuation in 2026), the first employee, Joe (a former writer and journalist), wrote every prompt himself, spoke to thousands of users, and read hundreds of papers to extract what "a good meeting note" actually is. Five years later he still actively holds the same role.
Chris's reading: "There is no objectively perfect note," "the domain is dominated by human taste," "note generation is the core output of the product — direct human review scales well enough." So a permanent Oracle is rational. This is the organizational implementation of the same idea behind the "tennis-rally feedback loop with the LLM" in Mehedi Hassan (Granola) — Cannot one-shot it.
Case 2: Tandem — scaling into a Decentralized Oracle
Tandem (the UK's largest clinical AI scribe — it listens to doctor-patient conversations and generates clinical notes) started with Roy (a former doctor and McKinsey alum) as the Oracle. Review → prompt fix → iterate. But at scale, with many specialties, many countries, many use cases, one person isn't enough.
The response: a Decentralized Oracle. Small specialist Oracles placed in each specialty, each country, each use case. The platform was rewritten to handle "long-tail prompt customization," running thousands of prompt variations across a divided workforce. The domain has the same "no objectively perfect note" character as Granola, but at a larger scale that demands distribution.
Case 3: Anterior — Oracle → Evaluator → Architect evolution
Chris was the first technical employee at Anterior (US prior authorization — automating whether an insurer approves a doctor's prescription). He lived through the evolution in three phases:
- Phase 1 (Oracle): Chris writes the prompts and the code, reviews output in his clinical hat, iterates on fixes
- Phase 2 (Evaluator): at scale a single Oracle is impossible; metrics and failure modes are defined, a review dashboard is built, clinicians are hired to review, the engineering team gets the feedback
- Phase 3 (Architect): customer variation outpaces manual iteration, so an automated improvement loop is designed at the architect level
Why Anterior's Oracle → Evaluator → Architect progression was necessary:
- AI quality is objectively measurable (approve / deny, match against medical evidence)
- Clinical reasoning is required (= domain expertise is mandatory)
- There is enormous variation in prior-auth rule interpretation (= manual iteration can't keep up)
Who to hire — decomposing the required skills
Chris's hiring frame:
- Oracle: relevant domain expertise (direct hands-on experience with the use case) + a feel for prompting / context engineering + attention to detail + ability to talk to customers
- Evaluator: the above + data science intuition (metric definition, aggregation, analysis) + statistical sense + leadership / PM experience + industry connections (when you need to hire a review team)
- Architect: the above + experience building LLM-powered products + engineering skills
Failure pattern: hiring a "pure domain expert" leaves the organization unable to evolve from Oracle to Evaluator to Architect, and you end up bringing in a different person later. That creates organizational discontinuity — when the domain knowledge is in someone's head and that person leaves, you start over.
Three principles of organizational design
Chris's recommendations:
- Define a single principal domain expert — avoid consensus by committee; assign clear responsibility for AI quality
- Give them ownership — don't treat them as a consultant; put them in the room for real decisions, or you won't build a differentiated product
- Hire for breadth — choose people with domain expertise plus adjacent skills, and pair them with a statistician or similar where needed
A failure example (a company Chris previously worked at): "two senior clinicians, with no clarity on who held the final decision, treated as advisors rather than owners" → both left within 12–18 months, and the loss of domain knowledge was a serious blow to the organization.
Editorial reading — a unified theory that applies directly to MEMEX
Three angles for taking this talk into MEMEX:
(1) A unified organizational framework for vertical AI. The figures MEMEX has covered so far — Pedro (Supabase), Mehedi (Granola), Brian (Intercom), Mike Spitz (PFF) — all map cleanly onto Chris's frame as Oracle (Pedro, Joe at Granola), Evaluator (Brian's Team 2x), or Architect (Mike Spitz's autonomous flow). That's a basis for adding an "organizational model" axis to the MEMEX network graph.
(2) "Domain experts at the center" as the 2026 differentiator. Now that frontier models have commoditized, the contest for verticalized products turns on how a company hands its own domain knowledge to the agent. Chris's three models cover the available options for that handoff. That is the organizational counterpart to the "production agents for enterprise" discussions around Anthropic Glasswing and Japan's three megabanks adopting Claude.
(3) Application to AI journalism itself. To the extent MEMEX itself functions as "a context graph of the AI domain," this is self-referentially relevant. The MEMEX editor (= domain expert) is currently in the Oracle phase; the next steps are Evaluator (building an article-quality measurement system) and Architect (an automated article-improvement loop). Chris's frame doubles as a roadmap for the publication itself.
Video outline
- (00:00) Self-introduction, career (Cambridge medicine → NHS → Tandem → Anterior → Notius Labs)
- (02:37) "Vertical AI is an organizational problem"
- (03:30) Gartner's 95% of projects abandoned
- (05:00) Presenting the three models — Oracle / Evaluator / Architect
- (09:00) How to pick a model — the decision flow chart
- (10:30) Case 1: Joe at Granola = the permanent Oracle pattern
- (12:00) Case 2: Tandem = scaling into a Decentralized Oracle
- (13:30) Case 3: Anterior = Oracle → Evaluator → Architect evolution
- (17:00) Decomposing the required skills (Oracle / Evaluator / Architect)
- (20:00) Three principles of organizational design (Principal / Ownership / Breadth)
- (22:30) Failure example — two senior clinicians who left
- (24:00) Closing, Q&A