More agents. One product.
Pixie Dental is an end-to-end dental practice platform in development. A patient visit has to stay consistent across scheduling, clinical care, and billing, regardless of which agent builds each part. I lead the product, design, and technology decisions that make those workflows one product.
A standard is a contract about meaning
Interactive · record chainShared healthcare data standards define what a record means and how workflows connect. I use those contracts to make architectural decisions explicit before parallel implementation begins.
The visit is recorded once and crosses three domains. Each handoff below is a contract the platform enforces, and each contract is also the boundary between units that different agents can safely build. Select a record to read what it promises and what guards it.
- Scheduling
- Check-in and checkout
- Patient communication
- Multi-location administration
- Charting
- Treatment planning
- Clinical notes and signing
- Fee schedules
- Charges and invoices
- Claims
- Remittances and reconciliation
Contract
Planned treatment is a ServiceRequest; completed treatment is charted as a Procedure with tooth and surface. Marking treatment done and charting it are one action. Notes move from preliminary to final to amended with author and co-signer controls.
Guard
Presenting a plan and charting completion are separate permissions.
Tiers in play
Record names, contracts, and guards follow the platform's documentation and dated decision records as of October 2026.
From unit page to merged main
Interactive · trace a unitFour layers stand between a proposal and the platform. A specification layer settles what a unit means before anyone builds it. An orchestration layer decides what can run at once. An integration gate decides what is real. An owner decides what the gate's findings become.
Pick a unit and follow it through. The graph shows where it sits among its neighbors; each layer lights the mechanisms that handle it. Select a layer name to read its role on its own.
- What enters a wave
- What merges
- Findings register · owner-triaged
- Next wave drafted after the last gate
- Scope boundary
- Main green end to end
- Shared environment clean
- Documents in step
- Rebase damage measured
- Security scans
- Owner session for anything blocked
- Replayable fixtures
- Dependency graph decides order
- Task agents · one unit each, isolated copies
- Shared-file ownership per wave
- Coordinating agent
- Cross-cutting change lands alone
- Unit page · one per unit of work
- Dated decision records
- Standards audit findings → decisions
- Architecture reviews of the set
- FHIR R4 profiles and terminologies
Six units and one cross-cutting change. Read the layers from the bottom: every unit is specified before it is orchestrated.
Owner decisions. What enters a wave, what merges, and what a finding becomes. Agent-proposed tasks would diverge the architecture, so findings go to a register and I decide what the next wave contains.
Integration gate. Agents implement bounded assignments in isolated copies. Before work is accepted, I review the integrated product with the coordinating agent: end-to-end checks, shared-environment consistency, current documentation, and issues that need an owner decision.
Orchestration. The dependency graph decides what can run at once. Task agents take one unit each in isolated copies; shared-file ownership per wave keeps one owner on each contract.
Specification. Work arrives as a page: phase, lane, dependencies, the decisions it applies, the files it owns this wave, acceptance criteria, and a dated status line. Beneath the pages sit dated decisions and the standards they protect.
Integration evidence writes the next wave
Feedback-driven replanningFindings go to a shared register, and I decide what enters the next wave; agent-proposed tasks would diverge the architecture. Each plan is rewritten from what the last gate showed.
Standards review shaped the specifications before execution. Across an 88-report proposal, it established the resource model for planned treatment, coordination-of-benefits rules, and applicable profiles. Those architectural decisions became shared context for every agent building on them.
- Adaptation 01Plan from the last integration.
The program moved from creating every assignment up front to drafting one wave after the preceding gate, so each new unit inherited the latest decisions.
- Adaptation 02Change the merge contract.
When parallel work exposed shared-file collisions, ownership and merge conventions changed, and the fix became part of how later units were specified.
- Adaptation 03Consolidate, then decide.
Retrospective findings entered a shared register. I decided what mattered now, what belonged later, and what stayed outside scope.
Evidence, with counting rules
Delivery record · October 2026Two records substantiate the delivery story: one documented program week inside the reporting workstream, and the platform's whole-codebase counts as of October 2026.
Delivery record · engineering measures
One documented program week
Platform scale
Planning record. The delivery history holds 4,312 work items across 275 backlogs: the distributed backlog from which every wave was drawn.
Standards footprint. FHIR R4 resources; US Core, HL7 Dental Data Exchange, CARIN, and Da Vinci profiles; CDT, SNODENT, SNO-DDS, and LOINC terminologies; X12 claim and remittance formats at the edges. Each is present in code and in dated decision records as of October 2026.
Division of labor
AttributionThe leverage is in the delivery system, and the delivery system has an owner.
I set priorities, architectural direction, and acceptance criteria. Distributed specifications make the work explicit; dependencies determine what can run in parallel; integration findings inform what happens next.
Task agents implement one unit each from its page, in isolated copies, and hand back to the gate. A coordinating agent runs the gate with me.
Human engineering and design contributions land alongside the agents' units, through the same integration gate.
What transfers to your build
Portable judgmentDentistry is the instance. Any platform built on an external standard by more than one agent faces the same three problems.
Settle meaning before parallelism.
Audit the proposal against the standard, turn each disagreement into a dated decision, and put the decisions on the unit page. Agents apply the decisions; the owner makes them.
Sequence by dependency, own by file.
The dependency graph decides what can run together; shared-file ownership per wave decides what cannot. Cross-cutting changes land alone.
Let the gate write the plan.
Merge behind one checklist, send findings to a register, and draft the next wave from what integration showed. Evidence from the shared environment outranks the original intention.
If your platform sits on a standard someone else wrote, the work that matters is settling the shared decisions, sequencing the units, and running the gate. That is the role I take, whether you are hiring a product leader or scoping a complex build.
Revisit the stackNeed a leader who can
build with AI?
Let's talk about the product challenge, the team, and the outcomes you need—whether you're improving how your business runs or building something new.