How it works
The planned design of zonask, from reading channels to the timeline.
Last verified 2026-10-05
This page describes the planned design; the overview has the current status.
Reading channels without storing content
zonask will connect only through official access, and each channel will be a connector that produces normalised items.
Gmail, Google Calendar and Google Tasks are planned as the first channels, for Release 1.
Messages and comments will follow release by release and will feed the same item pipeline.
Item text will be held in memory only, and triage, routing, learning and the screens will treat all channels the same.
Content will never be stored, subjects will be deleted after 30 days, and items that are switched off will never be read.
Checking accounts on a schedule
zonask will check connected accounts by polling; nothing will be pushed to it.
Accounts will be checked every five minutes inside a member's office hours on working days, and every fifteen to thirty minutes otherwise.
Before the MCP server answers, and when the app opens, zonask will check the member's accounts again.
Email content will never be stored; when the MCP server needs it, zonask will fetch it live from the provider.
Decisions per item and role
For every incoming item, zonask will decide per role whether it needs the user, and will turn it into a task, a calendar proposal, an update or nothing.
The decision will run in three layers: the user's own rules in code, the Jev decision model for categories, yes or no answers and scores, and Claude for language such as free instructions, dates and drafts.
Each role will have a matrix that says, per category, whether an item becomes a task, an update, a digest entry or nothing.
The chat model will never decide the category of an item; it will only propose rule changes that the user confirms.
Nothing will be fine-tuned: no model will be trained on the user's data, and tuning will mean changing configuration that the user can see and revert.
Every Done, Snooze, Not for me and answer will count as a label, Always will create a rule, and everything will be visible and undoable.
Once a week, zonask will show per role how it sorted the week before and talk about changes to the role matrix with the chat model, which will see counts and patterns only, never subjects, senders or content.
Nothing from the weekly session will change until the member applies it, and every applied change will show where it came from and can be undone.
The timeline
The main view will be one timeline in which tasks and events appear together, with one reason per item.
Updates will come on a schedule inside the member's office hours instead of in real time, and only when something changed.
Each member will set office hours, working days and one to six updates per working day: a morning plan, change-only updates and an end-of-day wrap.
Nothing will happen without the user's confirmation unless a standing order allows it.
The urgent channel
The urgent channel will stay off until the member turns it on, so zonask will stay quiet between scheduled updates by default.
When it is on, it will send at most three urgent messages a day, and outside office hours only if the member allows it.
The MCP server
Claude and other MCP clients will be able to use zonask through the zonask MCP server.
Every change requested through Claude will need the user's confirmation.
The MCP page describes the planned connection and tools.
Planned drafts from the assistant
When you ask the assistant for an email, Claude writes it as a draft.
The draft is created in your mailbox and never sent.
Where it will run
zonask will run as one Next.js application on Vercel, with Supabase in Frankfurt for sign-in, the database and background queues.
Every database query will be scoped to one tenant, with row-level security as a second line.