I have a Quick Notes topic in Telegram. It is the nearest thing my personal system has to an input box: send a sentence from my phone and let the machinery put it somewhere useful.
The first version was efficient in the way a paper shredder is efficient. It could turn a message into a calendar entry or task, but it did not understand that a thought, a reference, a question, and a commitment are different things.
That creates a predictable failure mode. If every interesting sentence becomes a task, the task list fills with ideas I never promised to pursue. If the system waits for perfectly structured commands, capture stops being quick.
The useful improvement was not a better command syntax. It was teaching the inbox to decide whether anything should be filed at all.
Conversation must be allowed to remain conversation
Quick Notes now begins with a deliberately boring question: is this a capture, or is the person simply talking?
An ordinary question gets an ordinary answer. It is not stored as an action merely because it appeared in the notes topic. A remark can remain a remark. The assistant does not need to convert every sentence into productivity theatre.
When a message is a genuine capture, it is routed into one of six types:
- Action — something with a real next step.
- Event — something that belongs on the calendar.
- Reference — information worth retaining, but not doing.
- Idea — a possibility that should survive without becoming an obligation.
- Person follow-up — a future contact or conversation.
- Discard — transient text that needs no durable object.
That classification is more valuable than extracting a date. It preserves the difference between “write the report on Friday” and “perhaps there is a report in this idea”. The words may look similar; the commitment is not.
The safe path has five stages
A natural-language capture can create or change an external object. That means the system needs a transaction boundary even though Telegram, Google Tasks, and Google Calendar do not share a transaction.
The flow is:
message → classify → stage locally → create or update → read back → confirm
Before an external write, the capture enters a small SQLite ledger as pending. The row retains the originating Telegram message, its topic and message ID, the intended destination, and any reply or attachment context.
After the write, the system fetches the resulting task or event again. Only when that read-back matches the intention does the capture become acted. The ledger then stores the external object ID and a rollback descriptor.
If the process stops between stages, the pending row is still there. Recovery can inspect what exists rather than blindly repeating the write. Exact-message idempotency and bounded content de-duplication protect against a retry creating a second copy.
This is a modest implementation of a useful rule: conversational input may be vague, but mutation history should not be.
Different information deserves different storage
Earlier versions of personal assistants often use the task list as a universal database. It is convenient because the API is available. It is also how reading notes, project ideas, and useful links become overdue chores.
The new router chooses a destination based on meaning:
- actions go to the shared task queue;
- explicit appointments and time blocks go to the calendar;
- ideas and references stay in the local capture ledger;
- book acquisition, progress, grades, and feedback go to the reading tracker;
- ambiguous person follow-ups become dated tasks unless I explicitly request a calendar block.
The book case is particularly useful. “I finished this” is not a task to tick off, and “I disliked the pacing” is not a note that should disappear into a generic archive. Both are evidence for later recommendations, so they belong beside the reading history.
Likewise, capturing a person follow-up does not authorise the assistant to send a message. It can prepare the reminder; communication still requires approval. Routing information correctly does not enlarge the assistant’s authority.
Confirmation should describe the effect
The reply after a capture now names what actually happened: the destination, date, and owner where relevant. It can add one useful connection or constraint, but it does not recite a fixed template.
That sounds cosmetic until something goes wrong. “Done” tells me nothing. “Added to This Week, owned by Closp, due Friday” gives me an object I can inspect. If the system stored an idea locally rather than manufacturing a task, the response should say that too.
The same principle applies to reversal. Undoing a capture does not delete its history. The ledger records the compensating action and retains the original provenance, so recovery does not require pretending the first event never occurred.
Testing meaning, not just syntax
Natural-language routing can look excellent in a handful of demonstrations and fail as soon as someone changes tone or language.
The acceptance set therefore used 40 labelled English and Russian examples covering all six capture types plus normal conversation. The implementation matched all 40. Separate tests exercised repeated messages, near-duplicate content, generic attachment captions, interrupted pending writes, source metadata, rollback evidence, and audit-preserving reversals.
The live topic policy was then read back and compared with its source configuration. Its enabled state and sender allowlist stayed unchanged, the OpenClaw configuration validated, and the first organic capture resolved to a verified external effect rather than merely a plausible reply.
None of this means the classifier will never misunderstand me. It means a mistake has provenance, bounded side effects, and a route back.
Frictionless does not mean indiscriminate
The best capture interface is one I can use before I have decided what a thought is. That does not mean the system should make the decision irreversible on my behalf.
Quick Notes is now useful because it combines a loose human input with a strict machine process: talk naturally, classify conservatively, stage before writing, verify the effect, and keep enough history to recover.
The result is a smaller task list, a better memory, and an assistant that can occasionally accept that I was only asking a question.
This is part of a short series on recent improvements to my personal AI system. Previous: turning Google Tasks into a shared operating queue. Next: replacing a link digest with a research desk that remembers.