ADR 0002 — The appliance model: local-primary, cloud-shadowed, edge-degraded

In short

This decides where a client’s system physically lives: on a Mac we configure and install in their own office, not in our cloud. That machine is the brain — it holds the files, runs the coordination and keeps the connections; the heavy thinking is still done by the model providers over the internet. We chose it because agents work on files at the speed of a local disk, and because sitting in the client’s office is itself a capability a shared cloud service cannot copy. Everything is copied continuously to offsite storage in a form only the client can unlock, so a dead machine means a new machine and a restore, not lost work. If the machine is down, the web address still answers with a read-only view and holds anything typed into it until the machine returns. We will never run many clients together on one shared system.

Context

Qren engagements need an answer to where a client instance runs, where its data lives, how it scales, and what happens when the machine is down. Cloud-primary was seriously considered (elastic compute, no hardware logistics, client never thinks about a machine) and rejected.

Decisive facts:

The heavy compute (LLM inference) is already cloud-elastic via Anthropic; the local machine is orchestration, storage, connectors, and light inference — a conductor, not the orchestra.
Agents work on files at filesystem speed; a cloud-primary drive turns microsecond file ops into rate-limited 100ms+ API calls and cripples the harness that is the product.
Local presence is itself capability: client-IP egress for portal logins, and iMessage/Apple-native integrations that structurally require a Mac — capabilities no multi-tenant cloud competitor can offer.
Hardware cost is noise at deal size (~1–2% of a $50–200k engagement).

Decision

Appliance, client premises, by default. Each engagement includes a Qren-configured Mac (Mini / Mini Pro / Studio, tier-matched, 32–64GB RAM) bundled into the deployment fee. Single-tenant Qren-hosted hardware is the exception for hardware-averse clients. Multi-tenant SaaS: never. Linux: not a product — the appliance OS is an implementation detail; avoid gratuitous new macOS coupling so a port stays possible.
Scaling doctrine — “the brain is sovereign; muscles are rented.” Scale-up = bigger appliance; scale-out = additional mesh nodes; heavy ephemeral workloads (builds, media, simulators, Docker) burst to rented compute that holds no persistent data. The appliance runs calm.
Admission control is core harness scope. Concurrent agent sessions are capped and queued (never fork-bombed); a memory watchdog defers and reports load instead of crashing. An OOM-crashed brain is a product defect, not an ops incident.
Drive: local-primary, cloud-shadowed. The Drive is a governed, workspace-scoped view over the appliance filesystem. Durability comes from continuous incremental client-side-encrypted snapshots (restic pattern) to R2 (~$15/mo per TB, zero egress). The shadow is ciphertext — sovereignty survives backup. Restore = new appliance + shadow. No multi-master sync engine will be built; one machine is the home.
Availability: the edge degrades, it never pretends to be the brain. Prevention first (UPS bundled, auto-restart, watchdog). The portal (edge) always answers: it serves a deliberately chosen replicated set (workspace directory, roster, briefs, health) read-only, and accepts writes into a queue drained on reconnect. True HA (warm-standby second node) is a paid tier via mesh.

Consequences

The sales story is physical and coherent: the brain sits in the client’s office, serviced remotely, backed up as ciphertext, and reachable through one portal.
The edge (Cloudflare) remains routing + cache + queue only — building agent compute into it is off-limits without revisiting this ADR.
Appliance specs, UPS, and burst-node tooling become deliverables of the deployment playbook.
Admission control and the backup pipeline are core framework roadmap items, not per-client customizations.