"Claude-native" is a term that gets thrown around. Most of the time it means a vendor is using Claude somewhere in their stack. That's not what we mean.

For Velyn Dental — the dental AI receptionist product inside Autonomy AI — Claude-native is a binary architectural claim with explicit conditions. This post walks through what those conditions are, the migration that got us there in March 2026, and the safety architecture that sits underneath the model.

The five conditions

Per docs/anthropic-partner-readiness.md, Velyn Dental is Claude-native only when all five of these are true:

Claude Code is the default engineering agent for the repo. Implementation, review, and repo maintenance work for the dental vertical runs through Claude Code on the first-party Anthropic API.
Claude is the default reasoning layer for the dental product's model-backed runtime. Onboarding, IVR speech reasoning, summarization, knowledge answers, reminder drafting, intake triage — all default to Claude.
Claude reaches the repo's real operating tools through MCP. GitHub, Vercel, Datadog, Stripe, and five dental-specific MCP servers are wired into .mcp.json and enabled by default.
GitHub review and implementation workflows treat Claude Code as the normal path, not a side path. Issue templates, PR templates, and workflow YAML expect Claude as the implementing agent.
Repo memory, permissions, and tool access are configured for Claude first. CLAUDE.md is durable project memory, not a brief pointer file.

All five were met on March 16, 2026. Before that date — by the project's own definition — we were a mixed-provider monorepo with a Claude-native dental flagship target, not a Claude-native dental product.

What "claude-native" deliberately does not mean

It does not mean every API call in every app goes through Anthropic. The repo also contains BuckHound (price tracking), InstaSum (article summarization), and several other products with their own provider choices. The Claude-native invariant applies only to the dental flagship — apps/portal and apps/ivr.

It does not mean speech transport is Anthropic. Twilio, Google STT/TTS, OpenAI TTS pools — these remain as supporting infrastructure, not the reasoning layer. The model that decides what the receptionist says is Claude. The audio plumbing that gets the words to and from the caller is whatever works. That distinction is intentional and load-bearing for the architecture.

It does not mean fully replacing deterministic rules. Emergency keyword detection, regex PHI redaction, scheduler slot validation, Stripe revenue-event dedup — these are all deterministic safety floors that run before and under Claude. Claude is the generation and reasoning layer; the safety logic is what catches Claude when Claude is wrong.

The three architectural planes

Per docs/partner/anthropic/architecture.md, the Velyn architecture is organized into three planes:

Plane 1: Claude Runtime Plane

Everything model-backed lives under apps/portal/lib/anthropic/. This is the shared Claude-first runtime — the seam where prompt caching, structured tool-output workflows, governance telemetry, and tracing converge. New dental AI workflows extend this seam; they don't add new provider-specific calls inside route handlers.

The specific workflows on this plane today:

Interaction and voicemail summarization (apps/portal/lib/ivr/inbox/ingest.ts)
Grounded insurance and FAQ replies (apps/portal/lib/dental-knowledge/resolver.ts)
Intake and after-hours triage hints (apps/portal/lib/ivr/dental-intent.ts)
Reminder outreach drafting (apps/portal/lib/ivr/no-show/confirmation-service.ts)
IVR speech routing (apps/portal/app/api/ivr/speech/route.ts)
Live receptionist relay loop (apps/ivr/relay.py, running claude-haiku-4-5-20251001)
Governance telemetry (apps/portal/app/api/practices/[practiceId]/ai-governance/summary/route.ts)

Plane 2: Repo-Scoped MCP Plane

Claude reaches operational tools through MCP. The dental-specific servers — dental_practice, dental_rcm, dental_analytics, dental_support, dental_monitoring — give Claude access to practice scheduling data, revenue cycle context, analytics dashboards, support workflows, and observability. The cross-cutting ops servers — mcp-autonomy (GitHub, Vercel, Stripe, HubSpot, Datadog, Slack), mcp-devops, mcp-monitoring, mcp-payments — give Claude the same operational reach a senior engineer would have.

All of this is wired in .mcp.json at the repo root and enabled by default in .claude/settings.json. A fresh contributor opens the repo in Claude Code and reaches the same toolchain without machine-specific configuration.

Plane 3: GitHub Workflow Plane

.github/workflows/claude.yml carries two relevant jobs: claude (implementation) and claude-pr-review (review). The issue template .github/ISSUE_TEMPLATE/claude-implement.yml and the PR template .github/pull_request_template.md expect Claude as the implementing or reviewing agent. This is the path of least resistance for shipping work — not a separate channel a teammate chooses to invoke.

The migration that mattered: March 16, 2026

For most of the project's life, the IVR speech path was a mixed-provider mess. apps/portal/app/api/ivr/speech/route.ts had an OpenAI LLM compatibility fallback. apps/ivr/relay.py was the live receptionist relay built directly against OpenAI's AsyncOpenAI client and gpt-4o-mini. The speech_routing feature flag defaulted to false, meaning the Claude-based reasoning was opt-in even when it was available.

Three changes on March 16, 2026 resolved this:

apps/ivr/relay.py migrated from AsyncOpenAI / gpt-4o-mini to AsyncAnthropic / claude-haiku-4-5-20251001. All eight dental tools were converted to Anthropic tool format. Guardrails, latency markers, and dental task behavior were preserved through the migration.
apps/portal/lib/ivr/provider-clients.ts had its OpenAI LLM compat fallback removed entirely. SpeechReasoningProvider is now 'anthropic' only. The transport-layer OpenAI TTS pools remain — they're documented as supporting infrastructure, not reasoning.
apps/portal/lib/anthropic/client.ts flipped the speech_routing default to true. Claude speech reasoning is now active without opt-in.

That's the kind of change that sounds simple in a changelog and isn't. The IVR speech path is on a hot patient-call code path with sub-second latency budgets. Migrating the model requires re-validating tool calling, prompt structure, function-result formatting, and the streaming behavior under real call concurrency. We did it because Claude-native required it, not because the existing path was broken.

After March 16, the architecture moved from "Claude-forward" to "Claude-native dental flagship." That terminology change is recorded in docs/partner/anthropic/architecture.md and the README of the partner-evidence pack.

The safety floor under the model

The single most important architectural rule for Velyn is this: deterministic safety logic stays in place, and Claude sits on top of it. Claude is not replacing the rules — Claude is reasoning within the rules.

Concrete examples:

Emergency keyword detection runs before the model gets a turn. A patient who says "I'm in pain" triggers the deterministic emergency-handoff path; Claude is never asked to make that clinical decision.
Scheduler slot validation runs after the model proposes a booking. Claude can suggest "Tuesday at 2:30," but the booking only commits if PracticeSlotPool validates the slot against the practice's actual availability rules.
PHI redaction is regex-based at the post-call archive path. Claude may validate a redaction, but if Claude's validation is unsafe or fails, the regex output wins.
Stripe revenue-event dedup prevents duplicate billing meter events even if Claude (or its tool calls) misfires.

This isn't paranoia — it's how Claude-native production systems should be built when the cost of a model error is a clinical or financial consequence. Claude is the best reasoning layer we can put in the loop today. It's also a model, and models are wrong sometimes. The safety floor is what makes "sometimes" survivable.

What's next

The architecture as it stands today is stable. Future expansion happens through apps/portal/lib/anthropic/ — adding new dental workflows means extending that seam, not adding provider-specific calls in new route handlers. The governance surface (covered in the next post in this series) gates how new workflows ship.

The five-condition definition of Claude-native is durable. We can ship more functionality, add more MCP tools, expand the eval harness — and as long as those five conditions hold, the architectural claim stands. The day any of them no longer holds, the claim has to come down. That's the discipline the term costs to use honestly.

This post is the first in a three-part series on Velyn Dental's Claude-native architecture. The next post covers the five documented governance exceptions and why each one exists. The third covers the 199-case eval baseline we maintain before any model change lands.