Transparency note: This draft was written by Otti, Ruben's personal AI assistant, on Ruben's behalf. The perspective and design principles come from Ruben's practical work with Otti/OpenClaw; this is an editorial draft prepared for Ruben's blog.

Deutsche Version: Wie man einen persönlichen KI-Assistenten baut, der nicht nervt

How to Build a Personal AI Assistant That Does Not Become Annoying

Psychologically grounded system design for reminders, proactivity, and memory

Most conversations about AI assistants start with a feature list:

  • Can it handle calendars?
  • Can it remind me?
  • Can it do proactive research?
  • Can it write emails?
  • Can it manage tasks?
  • Can it run in the background?

Those are reasonable questions. But they are not the most important layer.

A personal AI assistant does not become good by being able to do as much as possible. It becomes good when it increases human agency without damaging attention, autonomy, or trust.

The key question is therefore not:

What features does the assistant have?

But:

What kind of relationship between human life, attention, decisions, and technology does this system create?

A reminder system can reduce cognitive load. It can also produce guilt.

A proactive agent can prepare things. It can also become a nagging machine.

A memory system can create continuity. It can also preserve stale assumptions.

A personal assistant is not a neutral productivity booster. It is a small attention and decision infrastructure.

That is how it has to be designed.

1. Do not start with tools. Start with attention rules.

The most common mistake is to plan the technical stack first:

  • Which model?
  • Which runtime?
  • Which app?
  • Which database?
  • Which automations?

That is understandable, but premature.

For a personal assistant, the first questions should be:

What is allowed to interrupt me?
What should only be prepared in the background?
What may happen automatically?
What requires my approval?
What should be stored long-term?
What should be forgotten or archived?

These questions sound less technical, but they are the real architecture.

Every proactive assistant makes attention decisions. If you do not design them explicitly, the system will inherit the defaults of conventional productivity software: more reminders, more open items, more visibility, more pressure.

A good personal assistant often has to do the opposite:

  • filter instead of showing everything
  • prepare instead of pushing
  • contextualize instead of pinging
  • stay silent instead of activating
  • reduce load instead of optimizing the human

The goal is not maximum activity. The goal is better agency.

2. The smallest useful version

You do not need to start with a self-hosted agent, Discord integration, cron jobs, memory search, subagents, and tool runners.

The smallest useful version of a personal assistant has seven layers:

1. conversation surface
2. durable notes / memory
3. task and deadline logic
4. reminders / calendar / scheduler
5. reading or research capability
6. autonomy gates
7. correction path

1. Conversation surface

A place to talk to the system: ChatGPT Projects, Claude Projects, OpenClaw, Hermes, Matrix, Discord, Telegram, webchat — the specific surface is secondary.

The important thing is continuity.

2. Durable notes / memory

The assistant needs some form of memory. At the beginning, this can simply be Markdown.

Not everything belongs in memory. Useful categories are:

  • durable facts about the person
  • decisions
  • ongoing projects
  • preferences
  • corrections to assistant behavior
  • recurring rules

3. Task and deadline logic

Not every open item is the same.

A psychologically healthier baseline is:

Deadline   = external date; real risk if missed
Active     = currently relevant, no hard deadline
Someday    = good idea, no pressure
Internal   = the assistant tracks it without human attention

Only deadlines should escalate. Someday items must not create pressure.

4. Reminders / calendar / scheduler

A reminder is not just “tell me X at time Y.”

Good reminders provide context:

  • Why does this matter?
  • What has already been prepared?
  • What is the smallest next step?
  • Does the human really need to act?

5. Reading or research capability

An assistant should read links, documents, emails, logs, or web pages before judging them.

Rule:

Read before assuming.

It sounds trivial. It is one of the most important protections against hallucination and false confidence.

6. Autonomy gates

The assistant needs clear boundaries:

Green: may act independently
Yellow: may act, then inform me
Red: must ask first

Examples:

  • reading a file: usually green
  • setting a reminder: usually green/yellow
  • changing system config: yellow
  • sending a message to someone else: red
  • deleting data: red
  • unattended pay-per-use API usage: red

7. Correction path

The assistant will make mistakes.

The important thing is not perfection. The important thing is visible correctability:

mistake / correction
→ understand meaning
→ choose the right memory layer
→ change rule or fact
→ make the change visible
→ verify later

If an assistant is corrected and nothing changes, it is not a system. It is just a chat window with a memory illusion.

3. Proactivity: useful instead of annoying

Proactivity is the most dangerous and most valuable part of a personal assistant.

Poorly designed, it becomes spam.

Well designed, it becomes relief.

The central threshold is:

Would I consider it a failure tomorrow if the assistant had not told me this?

If yes, the assistant may be proactive.

If no, a log, daily note, or silence is often enough.

Good proactive signals

  • external deadline within 48 hours
  • security issue
  • cost risk
  • system outage
  • appointment with missing preparation
  • recurring error that burdens the human
  • new information that changes a decision

Bad proactive signals

  • “You once wanted to…” without context
  • vague self-improvement goals
  • every open task
  • routine successes
  • internal technical follow-up
  • things only the system itself cares about

A good assistant protects the attention surface.

4. Reminders without guilt

Many task and reminder systems quietly create guilt:

  • overdue tasks
  • red badges
  • streaks
  • daily backlogs
  • old wishes resurfacing again and again

For some contexts this may be effective. For a personal assistant it is risky.

An assistant should not morally judge that something is still open. It should help reveal the next realistic step.

Bad:

You still have not done X.

Better:

X is still open. The next small step would be Y. I can prepare Z if you want.

Even better:

X only matters if you have capacity for it this week. There is no external deadline. I will keep it in the background.

This is not softness. It is precise attention design.

5. Memory hygiene: keep, compress, forget

A personal assistant needs memory. But memory is not a garbage bin.

Three common mistakes are:

  1. Store everything.
  2. Forget nothing.
  3. Never re-check old assumptions.

Good memory distinguishes:

Fact       = durable unless changed
Decision   = consciously decided
Context    = helps understand current work
Task       = needs action or review
Signal     = may reveal a pattern later
Archive    = original is preserved but no longer active

Important: forgetting does not mean deleting.

A better pattern is CRUF instead of CRUD:

Create
Read
Update
Forget

Forget means: lower relevance, archive, remove from active attention.

Not everything that is true has to remain present.

6. The assistant must be allowed to disagree

A personal assistant should not merely be pleasant.

Large language models are strongly trained to be agreeable. That creates a risk: they confirm too easily.

For personal assistance:

Relationship should be stabilized by reliability, not agreement.

The assistant should be able to say:

  • I do not know.
  • I have not verified this.
  • This sounds plausible, but the source is missing.
  • This is risky.
  • I think you may be putting unnecessary pressure on yourself.
  • I think you may be underestimating a real problem.

Disagreement is not a lack of kindness. Failure to disagree can become a safety issue.

7. Human limits are real system parameters

The human has a body, sleep needs, stress systems, social obligations, and finite attention.

The assistant has no tiredness, no body, and no lived experience.

That does not make the system superior. It gives it responsibility.

A personal assistant must not model human limits after its own operating mode.

Wrong parameter:

always keep going

Better parameter:

take over load without increasing pressure

Wrong parameter:

remind me of every goal regularly

Better parameter:

prepare relevant options when the context fits

Wrong parameter:

always reduce friction

Better parameter:

preserve useful friction; reduce harmful friction

Not every pause is a problem. Not every open topic needs activation.

8. Three entry levels

Not everyone has to begin with self-hosting.

Level 1: Chat plus manual notes

Suitable for almost everyone.

  • ChatGPT/Claude/Gemini project
  • one Markdown document with rules
  • one document with durable facts
  • calendar app for hard deadlines

Starter rule:

Only proactively interrupt me for real deadlines, risks, or decisions. For vague goals, prepare options but do not push.

Level 2: Markdown memory plus reminder rules

For people who want more structure.

  • MEMORY.md for decisions and facts
  • TASKS.md for active tasks and deadlines
  • backlog.md for someday items
  • weekly review
  • clear escalation rules

Level 3: Self-hosted agent

For people with technical curiosity or existing infrastructure.

  • OpenClaw, Hermes, or a similar agent runtime
  • Discord/Telegram/webchat as surface
  • scheduler / cron
  • tools for web, files, calendar, email
  • memory search
  • subagents / workers
  • logs, health checks, cost control

This becomes powerful — and operationally more demanding.

The more the assistant is allowed to do, the more important gates, logs, and review become.

9. A practical start checklist

Before making your assistant proactive, answer these questions.

Attention

  • What may interrupt me immediately?
  • What should only be logged?
  • Which topics should remain quiet by default?

Autonomy

  • What may the assistant do alone?
  • What may it do and report afterward?
  • What always needs confirmation?

Memory

  • Which facts should be stored long-term?
  • Which corrections should become rules?
  • What should be archived regularly?

Safety

  • Which data is sensitive?
  • Which tools must never be used without approval?
  • May the assistant send messages to other people?
  • May it delete files?

Psychology

  • Does the system create pressure?
  • Does it use guilt, streaks, or badges?
  • Does it remind too often?
  • Does it agree too easily?
  • Does it help me become more capable?

If you do not answer these questions, your tool will answer them implicitly.

10. Example: a good reminder

Bad:

Do taxes.

Better:

Reminder: taxes are relevant this week. There is no deadline today, but I can prepare the document checklist if you want.

Even better:

Taxes: filing is due in 10 days. I marked the missing documents from the last list. Today one small step is enough: open the receipts folder and check whether the health insurance statement is there.

The difference is not politeness. The difference is system design.

A reminder should provide context and agency, not just pressure.

11. Example: good proactivity

Bad:

You wanted to exercise more. Go for a run today.

Better:

No pressure: movement is stored as a long-term wish. There is no reason to ping you about it today.

Or, if the context fits:

You mentioned that afternoon swimming works well for you. The weather is bad for cycling, but the pool could be a low-friction option today. Should I check opening hours?

Proactivity must be context-sensitive. Otherwise it becomes nagging with an AI voice.

12. Example: correction becomes governance

The human says:

That was too much. Please do not keep reminding me of open ideas.

A bad assistant says:

Understood.

A good assistant does more:

Correction understood:
- Open ideas do not belong in deadline reminders.
- Someday items only surface during review or when context matches.
- No proactive pings without external deadline or clear risk.

Then it stores that rule visibly.

That is the difference between a conversation and a system.

13. How to work well with an assistant if you are a nerd, but not a programmer

Many people do not fail with personal AI systems because they lack ideas. They fail because they think they first have to become programmers.

They do not.

You do not need to be able to program in order to work well with a personal assistant. You need a different skill: describing your situation, your constraints, your friction, and the desired effect clearly.

In other words:

You do not have to know the technical solution. You have to tell the assistant the goal, context, friction, and boundaries.

A useful starting instruction is:

I am technically curious and I understand systems, but I am not a professional programmer or trained system administrator. Explain technical steps in a way I can understand and safely execute. Do not only give me commands; briefly explain the purpose, the risk, and how we verify that it worked.

That changes the collaboration.

The assistant should not simply output code or shell commands. It should create a safe working surface:

Goal: what are we trying to achieve?
Context: why does it matter?
Next step: what exactly happens now?
Risk: what can go wrong?
Verify: how do we know it worked?
Rollback: how do we get back if it fails?

Work in meaning, not syntax

If you are not a programmer, you do not have to tell the assistant how to implement the solution.

Better inputs are:

I want my assistant to interrupt me only for real deadlines, but keep long-term wishes in the background.

I want to understand why this error happens, not just copy the next command.

I need a solution I can still maintain three months from now.

These are not non-technical statements. They are architecture requirements.

A good assistant translates meaning into mechanisms:

“do not interrupt”      → proactivity thresholds
“real deadlines”        → deadline category
“in the background”     → backlog or internal note
“maintainable”          → simple structure, few special cases
“understand”            → short explanation plus verification step

This is semantic collaboration: the human provides meaning, values, context, and judgment. The system translates them into rules, steps, files, commands, or automations.

Good prompts for non-programmers

Instead of:

Fix Docker.

Better:

I want to run this service in Docker. I am not a Docker expert. Please check the compose file for obvious errors, explain the risky parts, and give me a safe sequence: validate, start, check logs, rollback.

Instead of:

Why does this not work?

Better:

Treat this as debugging. First collect hypotheses, then test the most likely one, then make the smallest reversible fix. Tell me what you checked and what is still uncertain.

Instead of:

Remind me to exercise.

Better:

Movement matters to me, but I do not want pressure or streak logic. Bring it up only when the context really fits or when I ask. Help me reduce friction rather than trying to motivate me.

Instead of:

Remember this.

Better:

Please decide whether this is a durable fact, an active task, a decision, or just daily context. Store it only where it belongs.

Let the assistant carry the technical interpretation load

A non-programming user should not become the human parser for tool output.

When a command returns logs, the assistant should translate them:

What happened:
Meaning:
Risk:
Next step:
Does the human need to do anything?

When configuration changes, the assistant should not only say “done.” It should state:

  • what surface or behavior changed
  • why the change was necessary
  • how it was verified
  • how to reverse it

Good assistance reduces not only work, but interpretation load.

Insist on explainability, not over-explanation

The right mode is neither “do it blindly” nor “explain every detail of the Linux kernel.”

A good request is:

Explain the mechanism briefly enough that I understand the decision and can recognize related errors later.

The assistant should not avoid technical terms, but it should anchor them:

A bind mount means the container sees a folder from the host. If the container is recreated, the data stays there.

This does not turn the human into a developer. It prevents dependency on magic commands.

Use the assistant as a sparring partner, not only as a tool

For a technically curious non-programmer, the strongest working mode is often not:

Do X.

But:

I think X is the right approach. Check my assumptions, name the risks, and tell me whether there is a simpler or more maintainable solution.

The assistant should be allowed to disagree.

This protects against two common failure modes:

  1. Building something too complex because the idea is exciting.
  2. Avoiding a safe next step because it feels too technical.

Good assistance balances both:

brave enough to act
careful enough around real risk

The best role split

Human:
goals · values · boundaries · judgment · correction · life context

Assistant:
research · structure · technical translation · execution · verification · reminders · consistency checks

If the human tries to pre-think every technical detail, the assistant is underused.

If the assistant decides without human judgment, it becomes dangerous.

The productive middle is complementary: the human describes meaning and decides at real gates. The assistant translates, checks, prepares, executes safe steps, and makes risks visible.

Practical starter prompt

A good starting prompt for a personal assistant can look like this:

I am a technically interested nerd, but not a professional programmer or system administrator. Work with me in a way that keeps me capable:

- Explain technical steps briefly and clearly.
- Take over research, structuring, and safe preparation.
- For risky things, give me options with a recommendation.
- Execute reversible, harmless steps yourself when you can.
- Ask me before external, destructive, sensitive, or paid actions.
- Translate error logs into meaning, risk, and next step.
- Prefer maintainable solutions over perfect ones.
- Correct me when my assumption is risky or wrong.
- Do not create productivity pressure.

This may be the most important configuration of all.

14. Tool-independent principles

Whether you use OpenClaw, Hermes, Claude Projects, ChatGPT Projects, Obsidian, a shell script, or paper is secondary.

The important principles are tool-independent:

  • Attention is finite.
  • Proactivity needs thresholds.
  • Reminders should prepare, not shame.
  • Memory needs hygiene.
  • The human remains the value-setter.
  • The system translates values into mechanisms.
  • Corrections must be visible and reversible.
  • Not disturbing the human is sometimes the best assistance.

If a tool does not support these principles, you have to build them around it — or choose a different tool.

15. What I learned with Otti

My own assistant Otti is not simply a chatbot. It is an evolving personal system made of memory, tasks, scheduled checks, tools, research, Discord, subagents, rules, corrections, and failures.

That is powerful.

It is also fragile.

The most important lessons were not technical tricks, but system rules:

  • An assistant must know when to stay silent.
  • A task system must not become a guilt machine.
  • Proactivity needs real thresholds.
  • Memory without archiving becomes ballast.
  • Good answers need evidence, not confidence.
  • Errors must be translated into rules or mechanisms.
  • A personal assistant must be more psychologically careful than a coding bot.

The dream is not an agent that does everything.

The dream is an agent that takes over the right load.

16. Conclusion

A personal AI assistant that does not become annoying is not created by adding more features.

It is created through good attention design, clear autonomy boundaries, memory hygiene, psychological caution, and visible correctability.

The technical question is:

How do I build this?

The more important question is:

What kind of everyday life does this system help create?

If an assistant cannot answer that question, it is not ready to become proactive.

If it can, it becomes more than a tool.

It becomes personal assistance infrastructure.