What Building a Regulated Healthcare Platform Taught Me About Agentic Engineering

Domain expertise, deterministic controls, selective AI, independent verification, and why implementation velocity changes the engineering operating model.

The Opportunity

I recently had the opportunity to replace a legacy healthcare quality-reporting platform with a modern architecture designed for AI-native engineering.

The domain was highly regulated and clinically complex. Subject-matter experts understood the business and clinical workflows; I owned the technical translation, architecture, and implementation. The platform served thousands of clinicians across hundreds of healthcare organizations, processing large patient populations through dozens of specialized clinical computation engines.

Agentic AI fundamentally changed the implementation capacity available to me, but it also exposed an important lesson: increasing code-generation velocity increases the need for independent verification, domain review, security controls, and explicit human accountability.

That project became one of the practical foundations for the Stage-Gate-Loop governance model.

The Architecture Pattern

The core insight was that AI should be selective, not universal. Not every computation benefits from a language model. The architecture separated concerns deliberately:

Key Design Decisions

• Deterministic computation remained authoritative for regulated outcomes. An LLM might help classify a clinical note, but the MIPS quality measure calculation itself must be reproducible, auditable, and identical across runs. AI assisted the inputs; deterministic logic produced the regulated outputs.
• Tiered inference controlled cost and latency. A local bounded model handled high-volume, repetitive tasks (note classification, simple extraction). Only ambiguous or complex cases escalated to stronger cloud models. This wasn't just a cost decision — it was a reliability decision. External model APIs introduce latency variance and availability risk that regulated SLAs can't absorb.
• More than a million coded clinical terminology relationships were mapped and maintained. This is work that AI accelerates but cannot own — a wrong mapping in healthcare produces wrong patient outcomes, not just wrong software behavior.
• Domain experts reviewed AI contributions at the semantic level. Not "does this code compile?" but "does this logic match what the regulation actually requires?" That distinction matters enormously in regulated domains.

The Domain Expert Pattern

One of the most valuable patterns that emerged was what I now call the Domain Expert Persona.

A project-specific persona was grounded in the terminology, decision patterns, examples, and feedback of experienced clinical quality specialists. Its purpose was to make domain perspective continuously available during design and implementation, while escalating consequential ambiguity back to the real subject-matter experts.

This pattern worked because:

• Domain expertise is expensive to access — real experts have limited availability
• Engineering decisions happen continuously, not on a meeting cadence
• Most domain questions have clear answers that an experienced specialist would give immediately
• The hard questions — the ones that require real judgment — are identifiable by the persona and escalated

The result: faster decisions on routine domain questions, better-quality escalation for hard ones, and a documented reasoning chain that domain experts could audit after the fact.

What Agentic Velocity Changed

With AI agents accelerating implementation, three things changed about how the engineering organization needed to operate:

1. Review became the bottleneck, not implementation

When a single engineer can produce the output of a team, the bottleneck shifts to: who validates that this is correct? Traditional code review doesn't scale to agentic output volumes. The answer was independent verification loops that could operate continuously, with human review reserved for judgment calls.

2. Security had to move at the same speed as development

In a regulated healthcare environment, security isn't optional. But sprint-based security reviews can't keep up with daily deployment cadence. The solution was embedding security verification in the loop layer — automated scanning, policy enforcement, and tiered review based on risk classification.

3. Intent preservation became critical

When an AI agent transforms code, it can silently lose the original intent. In healthcare, that means a regulation might be implemented in a way that produces the right answer for the test cases but fails on edge cases the regulation was specifically designed to address. Intent Contracts — explicit declarations of what the code must accomplish, not just what it must do — became essential for catching these drift errors.

Lessons That Became the Framework

The governance patterns that emerged from this project eventually became the Agentic Stage-Gate-Loop framework:

The Operating Model Shift

The fundamental insight isn't technical — it's organizational:

When AI agents become active participants in building consequential software, the engineering operating model has to change. Speed without governance is faster failure. But governance without speed is irrelevance.

The three-layer model — Human decisions, Gate judgment, Loop verification — emerged because a single-layer approach (either "let the AI build" or "review everything manually") both fail at scale. You need three different operating speeds for three different kinds of work.

That's what the Loop Engineering essay explores in detail, and what the Stage-Gate-Loop framework implements as an open-source system any team can adopt.