The data plane
Two databases, on purpose.
The warehouse NO PHI
Postgres, one project. Holds analytics for every domain (one row per domain per day, de-duplicated across properties), Search Console, key events, lead captures, payments, Core Web Vitals, the domain and property registries, and the entire agent control plane — task dispatch, artifact registry, value ledger, audit log. Agents read and write here under gates.
The HIPAA-isolated project MAY HOLD PHI
A separate Postgres project, separate credentials, business-associate terms in place. Holds the practice-management bridge, clinical documentation and claims work under separate schemas. Nothing here syncs to the warehouse; agents have no credentials for it; the only writes come from provider-approved workflows with an append-only audit history.
Why two rather than one with row-level rules: a single database means a single mistake in a policy exposes everything. Physical separation turns "did the policy hold?" into "was the key ever present?" — a question with a checkable answer.
System pairs
Each boundary, stated.
| Pair | Direction and what crosses | What never crosses | Why it is built this way |
|---|---|---|---|
| Practice management ↔ DrSupport bridge | Schedule, claims, ledger and note events from the practice-management system into the HIPAA-isolated project; provider-approved write-back of notes and codes with correct patient and procedure targeting, append-only history, rollback and disable. | Anything into the warehouse or to any agent. No autonomous write-back — a provider approves each one. | "Integration" with the practice system is a commodity. What is not: write-back a provider can trust and undo. That is the part being proven, end-to-end on a synthetic database first. |
| Websites → Analytics → Warehouse | GA4 and Search Console for every property, synced daily into per-domain views; key events (lead, sign-up, checkout, purchase, contact) registered on every property. | Sessions from declared crawlers or from browsers that never produce a human input signal — the tag is not fetched until a pointer, key, touch or scroll event. | Most sessions across the portfolio were datacenter scanners running real browsers. Filtering by IP would have removed nothing; gating the tag on interaction removes almost all of it. |
| Websites → Lead capture → Warehouse | Email, source domain, page, campaign fields into a capture table that permits insert only. | Any read or update path from the browser. Patient information (the forms say so). | The public key ships in every browser bundle. A table that lets it read would publish the list. Insert-only is the whole design. |
| Websites → Payments | Hosted checkout links; transaction-bound subscription verification; recorded rulings on pricing. | Card data (never touches owned systems); pricing changes without a recorded ruling. | Pricing is decided once, written down, and supersedes — so no agent re-implements a superseded offer. See Logic. |
| Warehouse ↔ Agent fleet | Tasks dispatched with a cost estimate, prior art bound before claim, approval status, workspace; results published as artifacts with summaries and reuse notes; value rows with a verifier. | Tasks without a cost estimate (refused). Settlement without an artifact or an honest failure. Credentials for the HIPAA project. | The queue is the contract. Every silent failure the fleet ever had was a field that was missing or a step that reported success while doing nothing; the gates exist to make those loud. |
| Agent fleet → Code → Production | Changes as a branch and a pull request, tests run, one project per domain linked to one repository, production deploys only from the main branch after a human merge. | Direct pushes to main. Secrets in repositories. Deployments from unlinked projects. | A push to main is a production deploy. The review step is the only thing between an agent's confidence and a live site. |
| Fleet → Me | Approvals framed to be answered from a phone; a dead-man alert over a separate channel if the control plane goes quiet; a nightly harvest of what was built. | Decisions the rules already cover (they proceed after twenty-four hours); raw task churn. | I set direction and answer short questions. Anything that needs a desk session waits, and the system has to keep working while it does. |
| Nodes ↔ Nodes | A private mesh across two physical locations; a message channel between agents; a shared artifact registry; heartbeats with a freshness deadline. | Self-asserted completion. One node's local files, unless published. | Nodes that cannot see each other's work rebuild it. Publication is completion (Method, principle 5). |
| Brands ↔ Brands | Contextual links along the dental owner's path: operations (DrSupport) → documentation (AIDoctorNotes) → supplies (Practice Stock Wise) → growth (Avant) → transition (DSOCompare, DentalExitStrategy, Risus Advisers). | Footer link walls; cross-posting the same content under different names. | Each brand solves one bottleneck for the same person at a different point in ownership. The links follow the person, not the org chart. |
Stack, briefly
Ordinary parts, unusually connected.
Hosting and code
Static and Next.js sites on Vercel, one project per domain, one GitHub repository per product. Windows and Linux machines run the same agent runtime; a Mac mini holds the control plane.
Data
Postgres on Supabase for both projects; scheduled jobs inside the database for sync, reclaim, retention and the dead-man switch; vault-held secrets, never literals.
Models
Several frontier providers plus local models behind one gateway, chosen per task. Provider-agnostic by configuration so no single vendor holds the fleet.
What is deliberately absent: a customer-data platform, a marketing automation suite, a paid crawling service, a separate analytics vendor. Each was evaluated and each was replaced by something already owned.