DRAFT
HandMade {data} · Private Chief of Staff
Preliminary concept · from your briefing · Confidential · July 2026

A private assistant appliance for the life behind the calendar.

A discreet, client-controlled assistant appliance that reads approved sources, prepares concise briefs, keeps a reviewable memory, and asks before anything meaningful is done.

Prepared by Marcelo Thiesen · HandMade {data} · private proposal
core idea

One private place for context, memory, and decisions.

The client keeps using email, calendar, files, notes, staff messages, travel confirmations, and household routines. The system connects to approved sources, builds a private memory from them, and presents briefs, search, corrections, and approvals in one private console. Messages provide context; the console is where decisions happen.

design decisions

Three boundaries keep the system clear.

The design separates context, memory, and action. This makes each source useful without giving it more power than it should have.

boundary 01

Messaging is context

iMessage, WhatsApp, and notifications feed context or alerts. Approval, durable memory, and system state stay inside the private console.

boundary 02

The console holds decisions

The private PWA, a secure web app, handles approvals, memory corrections, source health, audit review, and account-level controls.

boundary 03

Connectors are scoped

Each connector has an allowlist, credential scope, read/write rule, freshness signal, audit trail, and off switch.

boundary 04

Memory is compiled, then reviewed

Raw sources remain immutable. The assistant compiles candidate facts into a personal wiki, then sensitive or durable changes go through review.

how it works

Observe, compile, brief, approve, record.

The system turns daily context into a maintained memory layer and a short decision surface.

Real-life appsEmail, calendar, files, contacts, notes, travel, staff workflows, and optional message context. The client keeps using what they already use.
Approved connectorsOfficial APIs first; carefully scoped local adapters only where the value justifies the lower-assurance source.
Local assistant coreThe Mac Mini assembles context, maintains memory, routes model calls, and prepares drafts.
Private consoleThe private PWA is the trusted surface for briefings, approvals, corrections, search, and audit.
Human decisionExternal actions wait for client approval. The system records what happened and why.
system map

How the pieces connect.

The private Mac Mini hosts the appliance. Sources feed a local archive. A Karpathy-style compiled wiki turns repeated context into durable memory. The console governs approval, correction, and review.

context sources
Official APIsEmail, calendar, contacts, files, tasks, meetings, transcripts.
Optional WhatsApp contextIn-house, read-only, allowlisted chats, lower-assurance.
Manual importsExports, files, screenshots, voice notes, pasted context.
NotificationsOnly alert that a brief or decision is ready.
client-owned Mac Mini appliance
Connector runnerPulls from approved sources under explicit source policy, freshness checks, and audit logging.
compiled memory spine
Raw archiveSource text, timestamps, provenance, and permission scope.
Wiki compilerPeople, places, routines, preferences, trips, decisions, open loops.
Reviewed memoryDurable facts with evidence, confidence, last-seen date, and status.
ingest extract compile review lint
Core services
Orchestratorbriefs + proposals
Policy enginepermissions + data classes
Schedulerbriefs + lint + health
Model gatewayzero-retention / local
Local store + audit logEncrypted disk, SQLite/files, append-only record of reads, memory updates, proposals, approvals, and support access.
client surfaces
Phone / iPad / laptopTrusted devices on the private network.
Private web consoleBriefings, approvals, search, memory review, source health, audit.
Approved actionsDrafts, scheduling proposals, reminders, and local memory updates.
Approved LLMsZero-retention provider and optional local model behind the gateway.
context enters as evidence · memory compiles under review · actions require approval

The memory wiki is maintained by the assistant, reviewed by the client, and rebuildable from raw sources. Raw messages, emails, and model outputs stay as evidence; reviewed wiki entries become durable memory.

behind the scenes

Reliable integrations run as small, governed workers.

Behind the private console, small scheduled programs connect to approved sources, keep local records, and report when something needs attention. The AI works from prepared context; it does not hold credentials or freely operate external apps.

Scheduled workersSmall Python or TypeScript jobs run on schedule or event. They authenticate, pull approved changes, checkpoint progress, and report health.
Local evidence archiveRaw payloads, source references, timestamps, provenance, permissions, and deduplication state are written locally before interpretation.
Bounded AI tasksThe model extracts commitments, people, dates, preferences, contradictions, summaries, and draft proposals from controlled context packs.
Approval executorExternal actions are separate from reading. Drafts and changes wait in the console, then execute only after explicit approval.
What the workers doMove data, normalize formats, keep sync state, detect failures, preserve raw evidence, and make every source auditable.
Where Claude Code fitsClaude Code is a developer and operator tool for building, debugging, and maintaining the appliance. It is not the client-facing assistant and does not replace the approval console.
client experience

A calm console for decisions and memory review.

The private PWA presents the daily brief, approval queue, search, memory corrections, source health, and audit trail. The technical machinery stays behind the interface.

Morning brief

Today has 5 commitments. One conflict needs a decision. Three emails need attention. Paris has two unresolved items.

Approval queue

Draft reply to attorney. Proposed calendar move. Passport appointment options. Nothing has been sent.

Ask with context

"What am I forgetting before the trip?" The answer cites calendar, email, and saved preferences.

Memory review

"I learned these four facts this week. Keep, edit, or discard."

what the client sees

Clear decisions, short summaries, source links, and a record of what the assistant did.

human surface
what stays behind the scenes

Connectors, model routing, file search, scheduled jobs, source health, logs, and usage tracking.

system layer
what never becomes hidden

Permissions, external actions, memory changes, support access, and data leaving the device.

trust layer
compiled memory

A private wiki maintained by the assistant, reviewed by the client.

The memory layer follows the Karpathy LLM Wiki pattern: raw sources remain preserved, the assistant compiles them into linked pages, and periodic reviews find drift, contradictions, duplicates, and stale facts.

1Raw sources

Email, calendar items, files, transcripts, imports, and optional message context are stored or referenced with provenance. This layer is the evidence base.

2Compiled wiki

The assistant maintains pages for people, places, routines, preferences, trips, decisions, and open loops. Each page links back to the sources that justify it.

3Review and lint

Sensitive or durable facts wait for review. Weekly lint checks flag stale claims, contradictions, duplicate entities, orphan notes, and memories with weak evidence.

Memory compounds under controls

  • Query answers can be saved back into the wiki when they represent a useful synthesis.
  • Every durable memory carries provenance, confidence, last-seen date, and review status.
  • The wiki can be rebuilt from raw sources if compilation quality degrades.
  • The assistant reads the compiled wiki first, then raw sources when it needs evidence or freshness.
optional context layer

Optional WhatsApp context.

For a personal assistant, WhatsApp history may contain the richest everyday context: family logistics, staff coordination, travel details, informal decisions. But because there is no official personal WhatsApp history API, it should be offered as an optional local context source, clearly separated from the reliable core.

1Initial history import

Where the client explicitly allows it, selected WhatsApp exports or the local WhatsApp Desktop store can seed a private message index on the Mac Mini. This creates a starting corpus while keeping the unofficial nature of the source clear.

2Read-only local mirror

An in-house connector can use a client-approved linked-device session to mirror selected chats locally as new messages arrive. It is built for context only: no send, no reply, no reactions, no group changes.

3Review before memory

Messages enter as raw context requiring review. The assistant extracts candidate facts, decisions, dates, people, and open loops; the client reviews what becomes durable memory inside the private console.

Trust boundaries for this layer

  • Built in-house; no third-party hosted service, no external repository imported as a product dependency, and no raw third-party MCP tool exposed directly to the assistant.
  • Read-only by design: the connector contains no enabled send/reply/delete/react capabilities.
  • Allowlisted chats only, with excluded chats and a visible kill switch in the console.
  • Local encrypted storage, freshness indicator, and clear failure state when the mirror stops updating.
  • Labeled lower-assurance than official API sources; the core product must remain useful if this layer is disabled.
privacy and control

The privacy promise should be specific and visible.

For this client, privacy is part of the product. The system should make clear where data lives, which services are connected, who can access support, and what is logged.

Promises we can honestly make

  • Durable data, memory, audit logs, credentials, and application state live on hardware the client owns.
  • The private console is reachable only through the client's private network, approved devices, and app authentication.
  • AI model calls use approved zero-retention terms; sensitive information can be kept local or redacted.
  • Optional message-context connectors are local, read-only, explicitly enabled, and separate from the approval surface.
  • Support access is not permanent by default. Maintenance is time-bound, approved, and logged.
  • Every external action is proposed first, approved inside the console, then recorded.

Limits to state clearly

  • Some approved external APIs and AI model calls exist; the goal is controlled, visible, minimized transfer.
  • Private network access limits where the app can be reached. App authentication, authorization, and audit remain required.
  • Tool access is scoped. Permissions, allowlists, and logs provide the safety model.
  • WhatsApp context is an optional local source, without an official Meta-backed personal-history API.
  • External actions are added one narrow capability at a time, after review and approval design.
  • Support access uses a break-glass procedure: approved, time-bound, recorded, and revocable.
security as product

Simple language, strong controls.

1

Private network, private app

The console is available through the client's private network and only to devices explicitly allowed into that network.

2

App authentication

The console requires its own login, ideally passkey-based, with short-lived sessions and approval-specific confirmation.

3

Read first, act later

The first release should observe and summarize. Writing email, changing calendar events, or contacting people comes later, one permission at a time.

4

Tool boundaries

Each connector defines what it may read, what it may prepare, and which actions are unavailable by design.

5

Support access is exceptional

Support should follow a break-glass procedure: requested, approved, time-limited, recorded, and easy to revoke.

phasing

Build less first. Prove more.

The first release proves privacy, source reliability, daily briefing quality, and memory review before any external action capability is added.

Phase 0 setup

Set the trust foundation

Client-owned hardware, encrypted disk, private network, app authentication, credential storage, zero-retention provider terms, backup policy, and break-glass support procedure. No accounts connected before this is done.

Phase 1 read-only

Daily reality brief

Calendar, email, contacts, selected files, and tasks feed one concise morning brief inside the private console. Notifications can say only that a brief is ready.

Phase 2 memory

Private knowledge that stays clean

Meeting summaries, preferences, people, places, routines, open loops, and optionally selected WhatsApp context become reviewable memory candidates. The client corrects what the assistant thinks it learned.

Phase 3 approved actions

Drafts and changes, never surprise execution

Email drafts, calendar proposals, scheduling options, and travel prep appear as approval tickets. The console records the source, the proposed action, the approval, and the result.

Phase 4 expansion

Household, staff, travel, and special workflows

Only after the core loop works for several weeks do we expand into the more personal operational layer: school logistics, household maintenance, travel orchestration, and staff coordination.

positioning

Positioning.

A private assistant appliance with reviewable memory.

It runs in the client's environment, connects to approved sources, builds a Karpathy-style personal memory wiki, summarizes what matters, keeps decisions inside a private PWA, and records its work. The value is simple: reliable context, reviewable memory, and explicit approval before consequences.