Domain Expert Personas for AI-Native Software Development

When AI agents build software in specialized domains — healthcare, finance, legal, safety-critical systems — they need access to expertise they don't inherently possess. Generic training data gives agents surface-level familiarity with domain terminology, but not the judgment that comes from years of practice. Domain expert personas bridge this gap: project-specific AI configurations grounded in real specialist knowledge, with explicit authority boundaries and escalation paths.

This approach draws from Brian Madison's BMAD method (BMad Agentic Development), which treats personas not as characters to role-play but as skill compositions with documented authority boundaries. Each persona knows what it's responsible for, what it's allowed to decide, and where it must defer to a human.


Why Role-Play Doesn't Work

The naive approach to domain expertise in AI is role-play: "Act like a senior healthcare quality specialist." This produces confident-sounding output with no actual depth. The AI generates plausible terminology and reasonable-sounding logic, but lacks the calibrated judgment that distinguishes a specialist from someone who read the Wikipedia article.

Role-play fails because it provides no mechanism for:

The result is an AI that makes clinically incorrect decisions with high confidence. It picks the wrong measure specification year. It confuses denominator exclusions with numerator exceptions. It applies screening criteria to the wrong encounter type. Each error looks correct to non-specialists and only surfaces when a real expert reviews the output — if they review it at all.


The BMAD-Inspired Model

Domain expert personas in the Stage-Gate-Loop framework follow the BMAD principle: personas are structured skill compositions, not character descriptions. Each persona is defined by:


Virtual Gretchen: Clinical Quality in Practice

The most valuable persona in our governance system is Virtual Gretchen — a clinical quality domain expert grounded in the terminology, decision patterns, and judgment of real MIPS/HEDIS specialists. Not a generic "healthcare AI." A persona that knows the difference between a numerator exclusion and a denominator exception, that catches when a measure engine applies screening criteria to the wrong encounter type, that says "CMS changed the steward on this measure in the 2025 update — your logic references the old specification."

What Virtual Gretchen can decide:

What Virtual Gretchen escalates:

Virtual Gretchen exists because domain expertise is expensive to access. Real clinical quality specialists have limited availability. Engineering decisions happen continuously, not on a meeting cadence. Most questions have clear answers an experienced specialist would give immediately — those should be available at machine speed. The hard questions — requiring genuine clinical judgment — are identifiable and escalated. The result: faster routine decisions, better-quality escalation, and a documented reasoning chain the real experts can audit.


Authority Boundaries

The critical property that separates domain expert personas from role-play is explicit authority boundaries. A persona without boundaries is just a confident voice that never says "I don't know." A persona with boundaries is a reliable collaborator that maximizes its utility within defined limits.

Authority boundaries are defined along three dimensions:

Scope — what domain areas the persona covers. Virtual Gretchen covers CMS quality measures, value set mappings, and clinical logic. She does not cover billing rules, network adequacy, or patient engagement measures outside the defined set.

Confidence threshold — how certain the persona must be before acting autonomously. High-confidence decisions (clear specification language, well-documented edge cases) are decided autonomously. Low-confidence decisions (ambiguous language, novel scenarios) are escalated with context.

Consequence weight — how impactful the decision is. Low-consequence decisions (test data generation, documentation wording) have lower escalation thresholds. High-consequence decisions (payment-affecting logic, compliance certifications) escalate even at moderate confidence.


Escalation Patterns

Escalation isn't failure — it's the system working correctly. A persona that never escalates is either operating in a trivially simple domain or silently making decisions beyond its authority. Good escalation patterns share these properties:


Building Your Own Domain Expert Personas

The BMAD method provides the structural framework. The specific construction follows these steps:

  1. Identify the real expert — who on your team or in your organization makes these decisions today? What knowledge do they bring that a generalist lacks?
  2. Document their decision patterns — not just what they know, but how they decide. What questions do they ask? What signals tell them something is wrong? What makes them escalate?
  3. Define authority explicitly — write down what the persona can decide alone, what requires confirmation, and what must go to a human. Be specific, not aspirational.
  4. Ground in authoritative sources — link the persona to specific documents, specifications, and reference materials. "General healthcare knowledge" is not grounding. "CMS 2025 MIPS Final Rule, Section III.G.4" is grounding.
  5. Calibrate against real decisions — test the persona against historical decisions the real expert made. Where does it agree? Where does it disagree? Disagreements reveal either persona misconfiguration or undocumented expert knowledge.
  6. Iterate with expert feedback — the real expert reviews the persona's decisions regularly, correcting errors and expanding documented patterns. The persona improves over time, not just at construction.

Brian Madison's BMAD-METHOD repository provides templates, examples, and detailed guidance for constructing personas that follow these principles.


Related


Douglas Jones · Codifide