Personal Assistant (Proposal)¶
Status: draft proposal. Extends Work Model & IA (proposal) §3.4 ("each person has an assistant"). Sequenced after the Novansa pilot foundations, with a first slice that can run during it (§6).
1. Why, and what Hermes shows¶
Andrew runs a personal assistant, Emily, on the open-source Hermes Agent from Nous Research (~/dev/hermes, deployed on Coolify). It is used daily, mostly through Telegram, and its setup records what makes an assistant worth trusting. The parts that work:
- It acts for one person and says so. Standing rules (never delete, never send as Andrew, approval before external email) are mounted read-only, so the agent cannot rewrite them.
- Approvals are where the person already is. Inline on Telegram, not in an admin screen.
- Autonomy is earned, per category. Five email categories; ten approvals in a row without edits makes a category eligible for autonomy; any edit resets the count; first contact and money are always gated. Emily raises eligibility; Andrew decides.
- Memory has provenance. Every remembered claim carries
[Andrew|email|inferred YYYY-MM-DD]; a daily log is promoted into short entity notes (people, organisations, open loops, decisions) at the end of the day; only pointers live in the always-loaded prompt. - A short report instead of chatter. An end-of-day digest: what it did, what it is holding, what it could not do and why, approval tallies, and open loops with no movement for 14 days.
- An honest threat model. The "lethal trifecta" (untrusted input, private data, an outbound channel) is written down, with notes on what is enforced and what is only policy.
Thinklio's assistant should keep all of that, and gain what Hermes cannot have: it works inside the system of record, so every action is a logged change with undo, effects go through proposals the platform itself enforces, and the assistant sees the person's tasks, lists, pages and Inbox directly instead of through scraped integrations.
2. The assistant in Thinklio's model¶
- One per person, created with their account membership, a member of their personal space and of the spaces they choose. It acts for that person (the principal) and never beyond their permissions.
- Works on work objects. Creates and updates tasks, list records and pages through the one write path, with the actor recorded as the assistant acting for the person. Reversible changes inside Thinklio apply directly with undo; anything leaving Thinklio (sending mail, accepting invitations, paying) is a proposal with effects (proposal §6.3).
- Lives in the Inbox. Its proposals, questions ("Choose" items) and returned work land in Needs you; what it is waiting on appears in Waiting on.
- Standing rules are policy, not prompt. Per-person rules (never send as me, ask before first contact, never spend) are stored as policies the harness enforces at the tool layer and shown as chips; the assistant cannot edit them.
- Earned autonomy per action category, from the proposal history in
changes: N accepted-unedited in a row makes a category eligible; the assistant proposes the upgrade as an Inbox item; the person decides; any edit or rejection resets the streak. Some categories are never eligible (first contact, money, deletion outside Thinklio). - Routines. A morning brief and an evening report are the assistant's first routines (proposal §7.3, §8.3), personal rather than space-owned. The evening report is built from
changesandproposals: done, held, blocked, stale. - Memory with provenance. A personal notebook: a daily log of what it learned, promoted at the end of the day into short notes about people, organisations, preferences and open loops, each claim carrying who said it, from what source and when, and whether it was stated or inferred (the
basisandsourcefields of proposal §6.2). A small profile card of pointers is always in the prompt; the rest is retrieved. Inferred memories are evidence, never instructions. - Channels. The web app first; then Telegram relay with inline approve buttons, voice notes transcribed, photo capture (proposal §10.3); later its own mailbox that mail can be forwarded to.
- Skills it writes for itself. After doing the same job three times it drafts a skill; the draft lands in the Inbox for review (skills proposal, with a new user scope).
3. Lessons to keep (from Hermes)¶
- Enforce in the tool layer, not the prompt. Hermes could only observe sends (a BCC rule), because Gmail OAuth has no draft-only scope. Thinklio owns the effect path, so it can enforce.
- Keep in-prompt memory to pointers. Capped prompt memory forces lossy consolidation.
- Never store raw external content in memory. An injected instruction would come back later as the assistant's own knowledge. Store summaries with provenance.
- One writer per memory. Two agents on one profile corrupted each other's state.
- Review where the person already is. Memory, skill and autonomy reviews go to the Inbox and Telegram, not an admin page.
- Show the scopes actually granted when a connection is made (Hermes' Todoist grant silently included delete).
- Unattended routines need a hard stop on tool loops and can never approve themselves.
- Design against the trifecta. For each tool, record whether it reads untrusted input, touches private data or can send outward; a run that combines all three needs a proposal.
4. What exists, what is planned, what is new¶
| Capability | Thinklio today | Already planned | New in this proposal |
|---|---|---|---|
| Agent harness, tools | @convex-dev/agent, tools for tasks, notes, contacts, items, knowledge, delegation |
Skills, catalogue changes | An assistant template created per person |
| Acting for a person | Tools receive the user id; writes recorded as that user via agent_tool |
Change log actor and source (pilot §5.1) | Principal / assistant on every change ("Emily, for Andrew") |
| Approvals | pending_approvals for tool calls in chats |
Proposals with effects, Inbox Needs you (proposal §6.3, §7) | Earned autonomy per category |
| Standing rules | Account and team policies | Space policies | Per-person policies, immutable to the assistant |
| Routines | scheduled_agent_runs and event_triggers tables, with no executor |
Routines with a reviewer (§8.3), morning brief (§7.3) | Personal routines; the evening report |
| Memory | RAG namespaces incl. user:{id}; the knowledge tool searches only the account namespace |
Memory-as-a-service and knowledge-synthesis proposals (account level) | Personal notebook with provenance, daily promotion, profile card |
| Channels | Web chat; Telegram only in the retiring Go services | Telegram relay, adapter contract (§10.3) | Voice notes; sender allowlist; assistant mailbox |
| Google Workspace | None in Convex | Provider-neutral capabilities, Google first (§10.1) | "Proposed by the assistant" calendar for drafts |
5. Gaps found while mapping¶
- Routines cannot run.
scheduled_agent_runsandevent_triggersexist in the schema, but nothing executes them (crons.tsonly clears thinking indicators). A routine executor (cron plus Workpool, idempotent, with a loop hard stop) is a prerequisite. - The knowledge tool ignores personal and team knowledge.
tools/knowledge.tssearches only the account namespace, althoughknowledge.tsbuilds the four-layer search. Wire it to the layered search. - Telegram is not on Convex yet. It lives in the Go services being retired.
6. Sequence¶
Each step is usable by Andrew and Antonette on its own.
- A0: assistant in the web app (during the pilot, after 5.1): one assistant per person, created on first use, with tools over tasks in spaces, lists (read) and pages (after 5.5); the knowledge tool fixed to search personal, team and account layers; actor recorded as the assistant for the person.
- A1: proposals and the Inbox. The
proposalstable and Needs you; the assistant proposes anything outside Thinklio;pending_approvalsmerges in. - A2: routine executor, morning brief and evening report.
- A3: Telegram relay with inline approvals, voice notes and capture, on Convex.
- A4: personal memory notebook with provenance and end-of-day promotion; the profile card.
- A5: Google Workspace (mail and calendar as capabilities), with earned autonomy per email category.
- A6: assistant-drafted skills, reviewed in the Inbox.
7. Open questions¶
Emily and Hermes.Decided 2026-10-05: the Thinklio assistant replaces Hermes. Hermes taught a lot but stays a technical tool; Thinklio has the context and data access to do better and can be made consumer-friendly. Andrew switches when the Thinklio assistant matches what he uses Emily for daily: Telegram with approvals and voice notes (A3), the evening report (A2), and Google Workspace mail and calendar (A5). Emily's vault seeds Andrew's notebook (A4), imported as notes with provenance[Andrew|vault|imported 2026-…], and Hermes is retired after a week of running both.- The assistant's identity outside Thinklio. A mailbox per assistant (as Emily has) or acting only through the person's own connections, with drafts?
- Names. Does each person name their assistant?
- Antonette's assistant first job: likely the social and content follow-through that moves to Ripplebase, which ties A0 to the Ripplebase integration sooner.
Cross-references¶
- Work Model & IA (proposal): §3.4 people and agents, §6 proposals and effects, §7 Inbox, §8.3 routines, §10 integrations and channels
- Novansa pilot build plan
- Skills as a behaviour primitive (proposal)
- Memory as a service (proposal) and Knowledge synthesis and wiki layer (proposal)
- Hermes deployment and persona:
~/dev/hermes(outside this repo):README.md(threat model),profiles/emily/SOUL.md,vault/_README.md