Alvero architecture: the operating shell for a dental practice

Alvero does not replace your practice management system. It sits on top of Dentrix as an operating shell: ingesting the financial and scheduling data your PMS already holds, running 14 specialized agents against it, and surfacing outputs across 8 purpose-built surfaces. This document describes how those layers compose.

The shell model

Dentrix is the system of record for clinical and scheduling data in most Canadian and North American dental practices. Alvero does not compete with it, migrate data away from it, or require a parallel database of patient clinical records. Dentrix stays. Alvero connects to it via the Dentrix API and reads production, collections, adjustments, claims, and patient ledger events in near real-time.

The "shell" model means Alvero wraps the practice's existing systems—Dentrix, bank accounts, merchant processors, and payroll—in a unified operating layer that handles everything those systems do not: financial intelligence, cross-system reconciliation, agent-driven close, and owner-facing briefings. When a practice leaves Alvero, Dentrix and QuickBooks Online remain fully intact with no data migration burden. Alvero's artifacts (journal entries, reconciliation reports, close packages) are the outputs of the shell, not the system of record itself.

┌─────────────────────────────────────────────────────────────────────┐
│  PRACTICE DATA SOURCES                                              │
│  Dentrix API · Bank/Card (Plaid) · Vendor docs · Merchant (Stripe)  │
└────────────────────────────┬────────────────────────────────────────┘
                             │  normalized canonical events
                             ▼
┌─────────────────────────────────────────────────────────────────────┐
│  BOOKKEEPER AI  (7 agents)                                          │
│  Dentrix Ingestor · Bank/Card Ingestor · Document Ingestor          │
│  Posting Agent · Reconciliation Agent · Close Agent · Supervisor    │
└────────────────────────────┬────────────────────────────────────────┘
                             │  verified financial events + close packages
                             ▼
┌─────────────────────────────────────────────────────────────────────┐
│  ECONOMIC LAYER  (4 agents)                                          │
│  Cost Cutter · Revenue Hunter · Efficiency AI · Owner Brief AI      │
└─────────────┬───────────────────────────────────┬───────────────────┘
              │  patterns (anonymized, opt-in)      │  owner brief
              ▼                                   ▼
┌──────────────────────────┐        ┌─────────────────────────────────┐
│  META-TIER  (3 agents)  │        │  8 SURFACES                     │
│  Pattern Miner           │        │  Flight Deck · Command Centre    │
│  Per-Tenant Coach        │──────▶ │  Doctors Portal · Staff Portal   │
│  Agent Evaluator         │        │  Patient Portal · Messenger      │
└──────────────────────────┘        │  Bookkeeper AI · Voice           │
                                    └─────────────────────────────────┘
        

The 8 surfaces

Alvero presents eight distinct surfaces, each scoped to a role and function. These are the only user-facing interfaces in the platform. There is no generic dashboard or catch-all view: each surface exposes exactly the data and actions relevant to its user's role.

The data plane

Alvero's data plane is built on Cloudflare's edge infrastructure with Supabase providing the relational layer. Technology choices were made to keep data in Canadian regions, minimize egress, and put the tenant security boundary at the request layer—not inside the database.

Cloudflare Workers run at the edge closest to the requesting client, but all database reads and writes target CA-Central region endpoints. The Workers themselves are stateless; all durable state is in Supabase Postgres, D1, or R2.

The agent plane

The 14 agents are organized in a strict data-flow hierarchy. Events produced by Tier 1 are the inputs to Tier 2. Signals from Tier 2 are the inputs to Tier 3. No agent in a lower tier receives data from a higher tier; the hierarchy is one-directional until Per-Tenant Coach writes proposals back into practice configuration via gated approvals.

Tier 1 → Tier 2: canonical event stream

Bookkeeper AI agents emit normalized canonical events (JSON, versioned schema) that the Economic Layer agents consume. The Bookkeeper Supervisor gates which events are considered "clean": the Economic Layer only processes events that have passed Bookkeeper integrity tests. This prevents bad financial data from propagating into the briefing or savings analysis.

Tier 2 → Meta-Tier: economic signals

The Economic Layer produces structured summaries—cost benchmarks, revenue opportunity rankings, efficiency metrics—that Pattern Miner ingests across participating tenants. Pattern Miner never receives raw practice financial data; it receives the structured summaries, anonymized and tenant-stripped. Practices that have not opted into cross-tenant learning do not contribute to Pattern Miner.

Meta-Tier → practice configuration: gated proposals

Per-Tenant Coach is the only agent that writes back into practice configuration. It does so through a proposal system: every proposed change is classified Green, Yellow, or Red before execution. Green changes execute immediately. Yellow changes run in shadow mode for 7 days before applying. Red changes wait indefinitely for explicit owner approval. The Agent Evaluator monitors Per-Tenant Coach's own outputs as well as every other agent's outputs for 14 days post-deployment, with auto-rollback authority if regression thresholds are breached.

Tenant isolation

Alvero's tenant security boundary is at the Cloudflare Worker layer, not inside Supabase. This is a deliberate architectural decision with specific consequences for how isolation failures can occur and how they are prevented.

Every HTTP request to the Alvero API carries a signed tenant claim (a JWT issued at authentication). Before a Worker touches any database connection or data store, it validates the tenant claim: signature, expiry, and tenant-id binding. If the claim is absent, malformed, or expired, the Worker returns a 401 and terminates. No database query is issued. No data is readable.

Supabase Postgres uses row-level security with per-tenant Postgres roles as a second layer of defense. RLS misconfiguration is a known failure mode in multi-tenant Postgres systems; placing the authoritative boundary in the Worker means a Postgres RLS bug can cause a query to return zero rows or an error—it cannot cause cross-tenant data to be returned to a Worker that already validated a different tenant claim. The Worker will reject data whose tenant_id does not match the claim even if RLS somehow returned it.

Integrations

Alvero integrates with five external systems. All integrations use vendor-provided APIs; no flat-file or CSV import mechanisms are in production.

What Alvero is not

Clarity on scope prevents integration planning errors. Alvero is explicitly not the following:

• ✕Not a Dentrix replacement. Alvero does not hold clinical records, scheduling data, or patient charts. Dentrix remains the PMS. Alvero connects to it.
• ✕Not an EHR. No clinical documentation, treatment notes, imaging, or clinical data flows into Alvero. The platform handles financial and operational data only.
• ✕Not a billing service. Alvero surfaces missed billing opportunities and flags insurance claim issues via Revenue Hunter, but it does not submit insurance claims, employ billing staff, or guarantee claim adjudication outcomes.
• ✕Not a marketing platform. Alvero's Messenger surface is for operational and clinical-adjacent communications (appointment reminders, recall, financial agreements). Campaign marketing, social media, or promotional outreach are out of scope.
• ✕Not a staffing or HR system. Payroll data is ingested for accounting purposes only (Close Agent accruals and allocations). Alvero does not manage schedules, performance reviews, or employment records.