A tool-chooser front door → specialist workers (each with its own harness + verifiers) → one shared, provider-diverse gateway, sitting on a cross-cutting deterministic drift layer. Resilience · cost · best-tool-for-the-job.
2 · Multi-specialist orchestration — worked example: a healthcare SS publication
One artifact can need several specialists. The planner emits a plan, fans out independent lenses in parallel on the same text (sequential instead if a specialist edits rather than flags), then reconciles conflicts and applies an aggregate gate over the blocking verdicts. And before anything public ships, it clears a cross-cutting DLP / PII guard — a blocking check for secrets, internal identifiers, and PII on every public-facing artifact (deterministic first, LLM for context). This is why specialists want to be separate, independently-callable workers.
no
yes
⚕️ Medical worker + verifier clinical accuracy · claim support
PLAN · topic → required specialists medical review + legal review · both BLOCKING
Reconcile do the lenses conflict? synthesizer model · escalate to Jesse if unresolved
Aggregate gate all BLOCKING verifiers pass?
Back to author with combined findings
Publish
3 · Infrastructure worker — the "act on infra" specialist (the audited chokepoint)
Infra changes (CF, Supabase, DNS, Stripe, GoDaddy, Hostinger) are where most of the pain has lived — schema drift, wiped crons, a committed token, wrong-repo deploys, webhook misconfig. So they get one worker that's the audited chokepoint. Unlike the content specialists it acts rather than produces, so every change runs propose → verify-before → (approval gate on destructive ops) → execute → verify-after → log — making rule #26 (verify-before AND verify-after) code, not something the operator must remember. Its verifier is largely the deterministic drift layer ⑤ (already built); its corpus is the operational KB (runbooks, constants, incident history, drift contracts) — the most mature corpus we have. Likely a rebuild of the existing jarvis-infra on the new scaffold, and a strong candidate for the first specialist to build.
4 · The specialist template — one reusable pattern
Legal, marketing, research… are configurations of this shape. Both the generate step and the verify step ground against the specialist's corpus (authoritative RAG) and, when currency matters, Sonar. Verify is two-stage: cheap deterministic domain checks fail fast first, then the independent LLM verifier does judgment — retrieving the controlling authority from the corpus so its verdict is citeable. "Model B ≠ Model A" because a verifier must run a different model than the generator, or it grades its own paper. Each specialist is a worker scaffolded from workers/_kit + _template (shared plumbing, no copy-paste) — that scaffold is built and live (2026-07-16); the model/verifier internals below are the design still in flight.
5 · Where each kind of verifier lives — deterministic × scope
The two axes are independent. "Repo drift from live is the same no matter the domain" → top-left. A domain gets its own deterministic verifier only when it has an invariant (bottom-left); otherwise it's LLM-only (bottom-right).
Deterministic — fact-diff, no reasoning
Judgment — needs an LLM
Cross- cutting
SHARED drift layer (jarvis-watchdog) repo↔live parity · schema drift · infra/cron drift · secret presence. Same mechanism everywhere — never duplicated per domain. Runs continuously, out of band.
Thin / rare e.g. a global "does this output leak PII or a secret" scan on anything published. Mostly N/A.
The specialist's independent LLM verifier legal: is this language legally risky / unqualified advice? marketing: misleading / off-brand? research: does the answer follow from the cited sources?
Decision rule: does the domain have an invariant — a fact that must always hold, expressible as a hash / presence / lookup with zero reasoning? Yes → give it a domain deterministic check (cheap, runs first). Needs reasoning → LLM verifier. Invariant is domain-agnostic (code == deployed, schema == expected) → push it to the shared layer, don't rebuild it per domain.
Build the whole thing brand new and move JARVIS functions onto it one domain at a time — never a flag-day cutover. The legacy monolith + stale workers are migrated off and retired; the data (Supabase) stays put — only compute is rebuilt. Each function is parity-verified (before/after) on the new stack before the old handler is retired.
Legend & the three principles
Cheap edge modelWorkers AI (Mistral/Llama). Classification, routing, extraction. Fast, cheap, and can't be capped by an external provider.
Specialist workerSmall domain worker: owns its model policy, tools, and verifiers. Replaces the monolith + one giant verifier.
AI GatewayOne door in front of all providers. Ordered fallback, caching, unified cost/analytics, rate-limiting.
LLM verifier (judgment)Runs a different model than the generator, so blind spots don't overlap. Domain rules on top.
Deterministic checkFact-diff, pass/fail, no reasoning. Cross-cutting (drift layer) or domain-specific (fast-fail inside a specialist).
Corpus / grounded searchEach specialist's authoritative knowledge base (RAG) + Sonar for current facts. Grounds both generate and verify → citeable verdicts. It's also where domain invariants live.
Resilience
No single provider can take JARVIS fully dark again (JARVISJARV-84). The gateway fails over Claude → Mistral → an edge model with no external cap; routing itself runs on the edge, so even the front door survives. The drift layer catches infra/schema/deploy regressions before they bite.
Cost
The bulk of calls — classify, route, extract, summarize — run on cheap edge models. Frontier models are reserved for real reasoning and the independent verify step. Deterministic checks run first and fail cheap before any LLM spend.
Best tool for the job
Each specialist picks the model that fits its domain and verifies with a different one. Web-grounded questions go to Sonar. Deterministic where an invariant exists, judgment where it doesn't.
Cloudflare-first
Keep everything on CF we can — R2 (docs) → AI Search / AutoRAG → Vectorize for corpora, Workers AI for edge models + embeddings, D1 / KV for metadata + state, all behind the AI Gateway. One bill, one auth model, edge latency, less glue. Move off only when forced (frontier model quality, Vectorize / D1 ceilings, compliance) — and external providers are still reached through the gateway, so it stays one door. Existing Supabase pgvector RAG stays until a migration earns itself.
7 · Boundaries — the architecture is a conformance contract
Now in the corpus (KB "JARVIS Multi-Model AI Architecture — canonical reference + conformance boundaries", and orientation rule #27). Any proposed change — new worker, model call, corpus, verifier, infra edit — is checked against these invariants.
New workers scaffold from workers/_kit + _template — no copy-paste; bundle-deploy; register in inventory + drift contract. ● active
Infra changes go through the infra worker's guarded pipeline — verify-before + after, gate on destructive ops, audit log. ● discipline active · worker pending
Cloudflare-first — move off only when forced, and through the gateway. ● active
No hardcoded credentials — getSecret / vault at runtime. ● active
Drift continuously verified — repo↔live, schema, infra/cron, secrets; extend the contract per new worker/table. ● active (layer ⑤)
All LLM calls route through the shared model layer (callModel → AI Gateway) — no scattered direct-to-provider calls. ● activates with the gateway
Verifiers use an independent model (Model B ≠ Model A). ● activates with the model layer
Corpora are CF-native, per-domain, with source+date provenance; "cite or don't claim" for legal/medical. ● activates with the first corpus
Deterministic before judgment where a domain invariant exists. ● principle
Enforced at three points: design-time (this doc / KB is the reference — check new work against it) · change-time (the infrastructure worker's verify-before is the conformance gate) · continuously (the machine-checkable boundaries become deterministic checks in layer ⑤).