# Design brief — vendor-agnostic personal chief-of-staff system ## ROLE You are a systems architect. Produce an implementation-ready design specification, not code. A separate builder will implement from your spec, and a separate critic that has not seen your reasoning will attack it. Write for both. ## OBJECTIVE Design a vendor-agnostic personal chief-of-staff system that one person owns and self-hosts. Modular agents, model-agnostic, voice-first input, provider-pluggable. Priorities in order: reliability, maintainability, security. Cleverness is a defect. ## WHO IT SERVES - One operator. No team, no developers, ever. He builds with AI tooling only. - Every waking hour is already allocated: gym before dawn, a full office day, an evening decision window, a second venture, then a single late block that is the only creative time available. There is no slack anywhere. - Primary input is voice dictation, frequently from a moving vehicle: long, unstructured, half-finished sentences with transcription errors. Design for that input shape, not for typed queries. - He already runs a large, working, multi-agent system for his professional life. This is explicitly NOT that. This one manages the person. ## DOMAINS IN SCOPE Personal admin and deadlines, immigration/legal status, finances, health, relationships, learning, hobbies, journalling, decisions and their reasoning. Work is a hard boundary and never enters. ## THE EVIDENCE THAT CONSTRAINS THIS DESIGN Two prior attempts by this operator were fully designed and both are dead. Your design is judged primarily on whether it defeats these two failure modes by construction, not by discipline. **FAILURE ONE — the ceremony gate.** A chief-of-staff system was completely specified in one day: persona, boot sequence, goal model, output formats, tiered authority, safety rails, nine skills. It never executed once. Its runtime state still reads `boot_blocked: true` because a goals file sat at status `draft-awaiting-review` and the review never happened. It was engineered to refuse to start until a human ratified it, so it never started. > Your design must contain NO approval gate, NO status field, and NO ratification > step that can block operation. A missing file produces a question, never a halt. > State explicitly where you considered adding a gate and why you did not. **FAILURE TWO — starvation.** A personal folder was scaffolded and left with a placeholder for three months, inside a toolchain that was writing to work folders daily the entire time. It never lost a fight for attention; it never entered one, because nothing ever raised it. > Every component of value must arrive unprompted, on a schedule. Anything that > waits to be opened will not be opened. Treat this as a physical law, not a > motivation problem. ## HARD CONSTRAINTS 1. **NO SEND CAPABILITY IN PHASE ONE, ENFORCED BY ARCHITECTURE.** No SMTP, no send function anywhere in the codebase. Drafts only. The system must be physically incapable of contacting another human, not merely forbidden from it. Policies get bypassed; absent code paths do not. 2. It must never delete, archive, or move anything without explicit per-item approval. 3. **EMAIL AUTH REALITY — do not design around a false assumption:** a self-built OAuth client requesting restricted mail scopes has its refresh token expired by the provider every 7 days while the app is unverified, and publishing to production with restricted scopes requires a security assessment that is not viable for an individual. IMAP with an app password has no such expiry. Design a pluggable provider interface, with app-password IMAP as the phase-one implementation and a verified-connector path left open. 4. Deterministic rules are the floor. Model classification may ADD labels but must never suppress or downrank an item that a deterministic rule surfaced. Silent misclassification is the failure mode that matters most. 5. Runs headless on an always-on Linux host. Never assume a desktop is awake. 6. **Low maintenance is a hard requirement, not a preference.** Every moving part must justify its existence against one maintainer with no spare hours. Prefer the boring mechanism: a file over a service, a cron over a daemon, a plain directory over a database. 7. Secrets are referenced, never stored in any model-readable file. Identity and immigration documents are referenced by name and location only; dates and statuses may be stored, document contents may not. ## DESIGN PRINCIPLES TO APPLY These are proven in the operator's working system. - **A guard is only real if something calls it.** When you specify a rule, name the component that invokes it and the moment it fires, or delete the rule. - **Doer and checker are different processes with different context.** Anything that produces a consequential output has an independent verifier that never saw the producer's reasoning. - **No artefact, no claim.** Any component asserting it did something must name the artefact it produced. "Ran successfully" is not evidence. - **Absence is a claim, not an observation.** Any component reporting that something does not exist must prove it from a second, independent method. - **New behaviour ships dark** behind a flag and is observed before it is enabled, especially anything that generates text a human will read. - **Memory is append-only**, every fact carries its source and date, contradictions are marked superseded rather than overwritten, and a scheduled evaluation grades the record's accuracy. The evaluation is not optional; it is the component that separates memory from storage. - **The system grades itself, never the operator.** No streaks, no adherence scores, no habit compliance. A system that scores the person becomes an accuser and gets killed. Judgement stays human. - **Slow-moving domains are reviewed on slow cadences with data.** Never ask daily about something that changes monthly. - **"Nothing changed" is a valid output.** Design the brief so it can be two lines. ## REQUIRED SCOPE OF YOUR ANSWER Design the WHOLE system, then scope PHASE ONE to a single agent that one person can build and run in a few evenings, and that survives two weeks unattended. Phase one is the email agent. Everything else is designed but explicitly deferred, with the trigger that earns each later phase stated. ## DELIVERABLE 1. Architecture: components, responsibilities, interfaces between them, what is pluggable and what is fixed. 2. Data model and on-disk layout. Plain formats only; readable in ten years with no special software. 3. The agent contract: what any future agent must implement to join the system. 4. Scheduling and triggering model, including what happens when a run is missed. 5. Failure modes, ranked, and for EACH one, how the system detects it. Silent failure is the operator's diagnosed root weakness across all his systems; a design that cannot detect its own silence is rejected. 6. Security model: credential handling, blast radius per component, what an attacker gets if any single piece is compromised. 7. The self-evaluation: what it measures, how often, what it outputs. 8. Phase one implementation spec, detailed enough to build from with no further questions. 9. Later phases, named, with the trigger that earns each. 10. What you deliberately did NOT include, and why. ## NON-GOALS — do not design these - No web dashboard, no UI, no search index in phase one. The phone is the interface. - No work or business data. No project management. - No outbound communication to anyone but the operator. - No new platform, framework, or abstraction layer that isn't load-bearing today. ## FINALLY Close with the three most likely reasons this system is dead in six months, and what in your design specifically prevents each. Be concrete. If you cannot name a mechanism, say the risk is unmitigated rather than inventing reassurance. --- **Output:** write the specification to `DESIGN.md` in this directory. Do not write any implementation code in this pass.