MalloryEstate Briefing
M·060Reference
← All briefings

Estate

Architecture

Five components, three data stores, one rule: the edge never blocks a turn on home infrastructure.

Dated 2026-06-15Programme Estate

Situation

The Edge Worker (mallory-core) is the only thing on the hot path: it owns conversation, classification, recall, persona, TTS, and the proactive-nudge decision, calling out only to stateless model/voice APIs (Anthropic, Workers AI/Whisper, ElevenLabs) — never the Hub or Tower. The Hub runs scheduled connector jobs and pushes digests inbound; the vault is the durable git-backed knowledge store; Hermes is a general-purpose agent harness on a home KVM VM ("the Tower") serving as dev-driver and experimental second brain.

Trust runs through Cloudflare Access end to end: SSO for humans, service tokens (a common_name claim) for automated callers, with inbound routes failing closed if their expected token isn't configured. Secrets are strictly partitioned per host, and the Tower has no inbound internet ports — only outbound tunnels.

Key decisions

Edge-local invariant enforced in code

The Worker's code contains no client for the Hub or the Tower — there is no code path from a user request to those hosts; the only outbound calls are to stateless model/voice APIs.

Push-inbound, not call-out

The Hub pushes signals to /context (~15 min), notes to /vault/sync (~20 min), and events to /nudge; Hermes pushes its activity feed to /hermes/digest (~30 min). The Hub may poll the edge, but polling is never on the hot path.

Graceful degradation on external calls

The invariant is about home infrastructure, not all I/O — stateless model/voice APIs are intentionally on the hot path, but TTS failure falls back to text and STT failure asks for a retry; the text turn itself never depends on voice.

Owned-lane vault writes

The Hub and Hermes share vault git write access but operate in disjoint path lanes (Hermes only under Hermes/), each doing pull-rebase + push-with-retry, so concurrent commits never conflict.

Route classes gate auth

Public (/status, /capabilities), UI (needs a valid Access identity), and inbound (needs a specific service-token cn) routes are explicitly separated, with inbound handlers failing closed if their cn env var is unset.

Dual-memory direction is planned, not built

The intended evolution has Hermes hold canonical/operational memory with the edge as a continuously digest-fed replica, and the Worker becomes a router that never blocks on delegation — flagged as a key open risk (digest fidelity becomes the floor on degraded-mode quality).

Architecture

Edge Worker, web/Android clients, Hub runtime, vault, and Hermes — each with a defined store and a one-directional trust boundary into the edge.

Edge Worker (mallory-core)
Owns the request: conversation, classification/orchestration, recall/search, persona, TTS, nudge pacing, and all inbound ingestion endpoints.
Web app + Android shell
SvelteKit PWA is the primary UI; Android is a thin WebView shell adding FCM push and a JS bridge (window.MalloryNative) for native deep-links.
Hub runtime (mallory-runtime)
Always-on VM running cron connector jobs and the deep-research worker; never serves user traffic — a producer of signals and a poller of the edge.
Vault (Obsidian/git)
Durable Markdown notes with freshness stamps; Hub and Tower hold working clones of one central remote, synced periodically, not real-time.
Hermes
Agent harness on the Tower with its own model routing, SQLite memory, skills, gateways (Telegram), and local HTTP API; writes to the vault in its own owned lane.
D1 / KV / R2
D1 holds conversations, messages+FTS, vault_notes+FTS, investigations, nudges ledger, device tokens; KV holds freshness-stamped signals and mode state; R2 caches TTS audio.

Risks & guardrails

Digest fidelity as the quality floor

In the planned router-to-Hermes direction, whatever the digest omits becomes invisible to the edge when the Tower is down — the key risk called out for the roadmap.

Lock-in to git semantics

Vault write safety rests on disjoint path lanes and rebase/retry rather than a transactional store or locking.

spec · docs/estate/02-architecture.md
Mallory · Estate briefing