Personal AI assistant
A personal AI assistant handles the routine: you dictate a task on the go, it adds it to a shared list, and twice a day it sends a digest telling you where to start in the morning and how the day went.
Published Aug 24, 2026 · figures checked Sep 1, 2026
How to set up a personal AI assistant: eight steps
- One routine. Decide exactly what it takes over: tasks, email or notes. An assistant "for everything" becomes one more task to manage.
- Where tasks live. Pick one place: a file in your notes, a spreadsheet or a tracker. Both you and the assistant must be able to edit it.
- Input through a messenger. Set up a bot where you already chat. A voice message on the go is the fastest way to capture a task.
- Voice to text. Let the bot transcribe the voice message and put the task into the file word for word, without rewording it.
- The model only for meaning. Keep anything that can be checked by exact match away from the model. That way a task cannot get lost or invented.
- Two digests a day. In the morning: where to start. In the evening: what is done and what is left. More often adds nothing; less often, the habit slips.
- Digest rules. Write down how many tasks to show, in what order, and what never to show. Otherwise the digest will look different every day.
- Completeness check. Compare the number of tasks in the file and in the digest. In our case only ten of thirteen tasks reached the digest, and the list still looked flawless.
Which setup fits which case
- Few tasks, all in your head: a reminder bot is enough, an assistant is overkill.
- Tasks already in your notes: choose an assistant that edits your file rather than keeping a second list of its own.
- Sensitive data: the model can run on your own computer, with nothing sent outside.
Below is how our assistant works: three runs a day and a guard against dropped tasks.
Where the project is now
What was needed
The requirement: a task dictated on the go must reach the file on its own and come back in the morning in a to-do list that explains the priorities. The file remains plain markdown in the vault. A person edits it by hand all day, so it must never be rewritten as a whole.
The constraint that shaped the whole design: a model returns what looks plausible, not what is complete. On August 24 the "Today" section held thirteen tasks, and only ten of them reached the morning digest. There was no error and no warning; the list looked flawless. The same property breaks counting. A digest you have to double-check by eye every morning is not worth receiving.
| Method | What we took from it | Canonical name · source |
|---|---|---|
| Split by verifiability seam principle | Everything that can be checked mechanically (moving lines, counting, writing to the file) is done by code. The model gets what cannot be checked mechanically: choosing what matters and wording it. The model does two of the eight pipeline steps | Deterministic code wherever a mechanical check is possiblethe lab's own rule, no external source |
| The Clarify step GTD | The first question about an incoming item is not "which folder" but "does this need action". Hence four outcomes instead of a list of folders. Without this step an inbox turns into a dump | Getting Things Done, the Clarify stepAllen, "Getting Things Done", 2001 |
| Tests at the seams seam testing | 301 tests at twelve boundaries, including: parsing the messenger response, file operations, compression, intake, digest assembly, the model adapter, memory. Every boundary can be stubbed, and no test touches the network | Contract tests at module boundariesFowler, "IntegrationContractTest", 2011 |
| Measure before explaining reproduce the failure | No fixes until there is a command that reproduces the failure. Before moving from the server back to the laptop, four candidate causes were tested this way and ruled out | Reproduce the failure before the fixZeller, "Why Programs Fail", 2005 |
| One owner per data store single writer | The task file and the memory each have one owner. Conflicts are ruled out by design rather than resolved after the fact | Single writer: one writer per resourcethe lab's own rule, no external source |
| Loud failure fail loudly | The intake log is written before the file write, every step runs behind a guard, and any failure triggers an alert in the messenger. Silence counts as loss, not as success | Write-ahead log; fail fastMohan et al., "ARIES", ACM TODS, 1992 · Shore, IEEE Software, 2004 |
| Exact match exact match instead of trust | Code finds each line in the file and moves it word for word. A line that is not in the file is dropped, so an invented task never reaches the file | Exact-match grounding as a guard against hallucinationsJi et al., ACM Computing Surveys, 2023 |
Off-the-shelf planners did not fit for the same reason they are convenient: they want you to keep tasks inside them. Here the source of truth is a file in the vault that already holds notes, projects and materials, and the assistant has to adapt to it, not the other way round.
How it is built
The seam follows verifiability: code does everything that can be checked mechanically, and the model gets what cannot. In the pipeline of a single digest, control passes between code and model four times in eight steps.
The assistant cannot invent a task: lines are moved by exact match, and a line that is not in the file is dropped.
Three runs a day
A midday run was written and then switched off: clearing checked items at lunchtime hides the full picture of the day's progress, and the extra digest led to no new decisions.
Four outcomes for incoming materials
The first question about an incoming item is not "which folder" but "does this need action". Without this step an inbox turns into a dump.
| Outcome | Action on check | Filed automatically |
|---|---|---|
| save | puts it into the inbox file at its destination | yes, if unambiguous |
| act on | files it and creates a task "Review material" | no |
| read | files it and creates a task "Read" | no |
| skip | removes it from the queue, no destination needed | no |
Inbox files are a closed list, and the assistant never creates new ones. The fallback destination comes last: when it came first, the model chose it without looking. A material that has sat for two weeks is marked "skip" in the evening and shown as a list. It is marked, not deleted.
What holds the design together
Decisions and their grounds
Five decisions. Each was made after a measurement or a failure, not on general grounds.
| Decision | Grounds |
|---|---|
| The assistant runs on the laptop, not on a server | Connection test: two or three successful sessions out of six over VPN. Tasks reached the file tens of minutes late. Fast delivery matters more than running while the machine is off |
| The midday run is switched off | Written and removed: clearing checked items at lunchtime hides the full picture of the day's progress, and a third digest led to no new decisions |
| A removed task is erased completely | Three options were on the table: a one-month retention period, a counter without the texts, full erasure. The third was chosen, knowingly at the cost of losing a "Dropped" line in the report |
| Inbox files are a closed list | The assistant never creates new files. The fallback destination comes last: when it came first, the model chose it without looking |
| The model version is pinned by exact name | The automation runs unattended, and the model must not change on its own. Switching models is a config change, not a code change |
What the design costs
On August 21 the assistant moved from the server back to the laptop. By the textbook this is a step back, but it followed a measurement. The vault lives on the laptop, the connection to the server went through a VPN, and only two or three of six connection attempts got through. Tasks reached the file tens of minutes late.
| Hypothesis tested | What we did | Result |
|---|---|---|
| Limit on concurrent logins | raised to 100 | no change |
| Packet size | three MTU values | worse with the smaller one |
| Port number | 443 vs 22 | 1 of 6 vs 3 of 6 |
| Out of memory | measured at the moment of failure | 541 MB free |
None of the hypotheses held, so the trade-off was set like this: it matters more that a task reaches the file right away than that the assistant runs while the laptop is off. While the laptop sleeps, the assistant is silent. Tasks are not lost, because the messenger keeps unread messages for a day. The server is stopped but intact.
The assistant notices on its own when a task is deleted by hand: a snapshot of the list is uploaded every five minutes, and an open task that has disappeared is erased from memory completely. There are three safeguards. Completed tasks are never touched; more than five tasks disappearing at once counts as a sync failure; and the evening digest lists removed tasks by name, because erasure cannot be undone.
What came out
The tests do not touch the network: page fetching is tested on saved samples, and everything can be stubbed, including the task file, memory, the messenger response and the model itself. So a digest can be run on a copy of the file without sending or writing anything.
Two figures in the monthly report are deliberately conservative: open tasks are not counted at all, and the average task lifetime covers only tasks whose creation the assistant saw itself.
- Sample
- One user, one task file, live operation since August 2026. The numbers in the strip describe the setup: three runs a day, 5–10 model calls against a cap of 50, 301 tests.
- Checks
- The tests do not touch the network and run on a copy of the file without sending or writing. Four candidate causes of the delays on the server were tested by measurement and ruled out (see the table above); the choice followed the measurement, not the textbook.
- Does not generalize
- The comparison with a virtual assistant covers only part of the job: taking tasks and writing digests, not negotiations or decisions. 8,500 characters a day is the volume of the digests, not a measure of value.
- Not measured
- Digest completeness as a number: the share of "Today" tasks that reach the morning digest has not been measured since the check was added. The only known case is 13 → 10, from before it. Open tasks are deliberately left out of the monthly report.
Runs on real tasks: two digests a day, intake every five minutes, 8,500 characters a day and zero model spend. The design is covered by 301 tests at twelve boundaries.
Kaufman Lab is an AI architecture lab. We design processes and methods. Code goes stale with every new generation of models; the method does not, so each project breaks down the method. Any current AI model can build a system from this diagram.
What went wrong
Deleting tasks is a separate mechanism. The owner removes a task in the simplest way: by deleting its line from the file. The assistant compares snapshots and erases the task from memory completely. There are three safeguards: completed tasks are never touched; more than five tasks disappearing at once counts as a sync failure and leaves memory alone; the evening digest lists removed tasks by name. Erasure cannot be undone, and the last safeguard is the only chance to catch an accidental deletion.
What else can be added to the code
Messenger intake, SQLite memory and the model behind an adapter are the same for any new feature, and the rule "code counts, the model words" carries over unchanged. Below is what would strengthen the assistant next, including paid services, and what it would give the owner.
What people usually ask
What is a personal AI assistant?
A personal AI assistant is a program that keeps your to-do list and talks to you about it in a messenger. It suits a business owner who keeps putting off planning and does not want to move tasks into someone else's system. Kaufman Lab builds the assistant on top of a plain markdown file: it takes tasks by voice, names the main ones in the morning and sums up the day in the evening. A human personal assistant costs about $2,300 a month at Upwork rates; ready-made planners start at $19 per seat. The system does not do the tasks for you.
Can I give an AI model access to my files?
The file is the only copy, and a person edits it all day. A model that rewrites the whole file will sooner or later change an indent, lift a nested subtask or touch the header with the schedule. So the model returns text, and code checks it against the file and moves lines word for word.
Can this assistant run in Slack or Discord instead of Telegram?
The message receiver is the thinnest layer of the design. Nothing below it depends on the messenger: the vault file as the single source of truth, sorting tasks from materials by how they were sent, safeguards at every step, and counting by code, not by the model. Only the intake changes.
Can I trust an AI model to count what I did today?
No, and that is a separate decision. The day bar and the week counter are printed by code, which reads completions from memory, not from the list. Items checked in the evening move to "Done" only the next morning, so a digest based on the list would report an empty day after a full one. The denominator is fixed in the morning; otherwise the bar would jump back with every new dictation.
What happens if the model does not respond: is the task lost?
The task is written in full, without compression. The digest sends a clear failure message. Every step runs behind a guard: a model call has a fifteen-minute limit, a lock is treated as stuck after twenty minutes, so the script has time to finish on its own.
Where should such a bot run: on a laptop or on a server?
The vault is on the laptop, and the connection to the server went through a VPN that dropped about half of the connections: two or three of six attempts got through. Four candidate causes were tested by measurement and ruled out. We chose fast delivery, at the cost of the assistant going silent while the laptop is off.
How much does it cost to run a personal AI assistant?
Zero for the model: it runs on the provider's free tier with a cap of fifty calls a day, and the assistant needs five to ten. The only paid part is fetching pages from submitted links, at one credit per page. Ready-made AI planners charge a subscription: Motion starts at $19 a month per seat.
What routine does a personal AI assistant take over?
Writing a task down, keeping it from getting lost, ranking it by importance and reminding you in the morning. You say the task out loud, the assistant adds it to the shared list word for word and sends a digest twice a day.
What does it do on its own, and what does it leave to a person?
On its own it picks up tasks every five minutes, keeps the list and builds a digest at 9 a.m. and 7 p.m. The person edits the list by hand, decides what to do and checks off what is done.
Why does it do so little when AI can do almost anything?
The set of actions is narrowed on purpose: the more decisions go to the model, the more often it adds things that were never on the list. The assistant does not let an invented task into the list.
- Allen D. Getting Things Done: The Art of Stress-Free Productivity. Viking, 2001 — the Clarify step.
- Fowler M. IntegrationContractTest, 2011. martinfowler.com
- Zeller A. Why Programs Fail: A Guide to Systematic Debugging. Morgan Kaufmann, 2005 — reproducing the failure before the fix.
- Mohan C., Haderle D., Lindsay B., Pirahesh H., Schwarz P. ARIES: A Transaction Recovery Method. ACM Transactions on Database Systems, 17(1), 1992 — write-ahead logging.
- Shore J. Fail Fast. IEEE Software, 21(5), 2004. doi:10.1109/MS.2004.1331296
- Ji Z. et al. Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12), 2023. doi:10.1145/3571730