I Gave an AI Agent the Keys to My Life (Here's What Happened)

What does it mean to give an agent access to your life? For OpenClaw maintainer Radek Sienkiewicz, it means access to email, notes, files, calendars, tools and the operating system, with memory of his computer activity supporting further automation. That is a substantial amount of authority to hand over. Installing the software and immediately expecting it to manage everything would be reckless.

His starting point was much smaller: one WhatsApp channel, with the ability to chat. He later moved to Telegram, then Discord. From that initial conversation interface, he added one simple task or workflow, made it useful, and added the next. Because no individual change felt large, he continued to think of the result as a simple setup. Comparing it with other people’s systems eventually revealed how much those small additions had accumulated.

The same progression took him from user to maintainer. Errors in a workflow led to a first pull request, then a second, then participation in Discord and deeper involvement. Maintaining OpenClaw is not a prerequisite for using this approach; the relevant habit is making each problem small enough to understand.

Trust grows through recoverable changes. Radek’s operating loop is to identify a need, solve it simply, and extend it only after it works. When something breaks, he steps back, diagnoses the failure, fixes it and adds a measure intended to prevent recurrence before proceeding. He credits that process with avoiding the major disruptions he hears about from other users.

The system became substantially more helpful when Radek gave it access to his existing knowledge base. Radek reports that his Obsidian vault contains about 3,000 Markdown notes accumulated over years. It holds work and personal material, tasks, projects, research, articles and an inbox of saved links. That collection supplies the background needed to connect a new request with work already underway.

Retrieval is not a single undifferentiated memory store. His setup combines ordinary search, QMD search for Obsidian, and separate memory for his workspace. These parts are interconnected. When he encountered Andrej Karpathy’s viral discussion of LLM knowledge bases, he recognized the pattern as something he had already built through incremental changes. The realization was less that he needed a new architecture than that his existing system had become worth explaining.

The vault graph shown in the recording is Radek’s actual graph. It contains dense clusters and more isolated nodes; he tentatively identifies the larger clusters with projects and some isolated entries with one-off bookmarks. The useful operation is adding connections to that existing structure when a new link arrives.

His inbox accepts tweets, threads, articles and YouTube videos. Processing a link follows a concrete sequence:

1. Inspect and analyze the linked content.
2. Add tags and contextual information.
3. Find material already in the vault on the same subject.
4. Consider where else the new material could be useful.
5. Add connections to those existing notes.

The output is therefore more than a saved URL: it is material situated within a personal knowledge base.

That changes the value of bookmarking. A conventional bookmark is easy to save and never revisit. Here, saving something can surface older notes on the same subject and explain how they connect. Radek often discovers that he has forgotten precisely the material that would help him think through the new link. Ingestion also becomes retrieval: adding knowledge brings relevant existing knowledge back into view.

The overnight routine prepares that system for another day. The slide uses 4 AM as shorthand; Radek says the jobs actually run roughly between 3 and 6 AM. They index content and make backups. Radek estimates that a loss would cost him perhaps a couple of hours of work or content. That is his stated expectation for the setup, rather than a demonstrated restore result.

The routine refreshes indexes for QMD, memory and the Obsidian vault. Morning output can also include email and calendar summaries. Updating OpenClaw is part of this preparation, but it took its own sequence of incremental improvements: scripts encode what an update should and should not do, known causes of breakage, and checks to perform before updating or restarting the gateway. The operational requirement is that the gateway can come back online. By morning, the updated system is ready for use.

Copying this exact configuration would miss why it works for Radek. It reflects his current needs, anticipated needs and the particular errors he has encountered. He introduces his activities as five job areas, beginning with ambient operations: updates and routine plumbing that need to happen but should not require his attention.

Attention filtering uses the same knowledge base to decide what deserves interruption. An incoming email can be evaluated against the project background stored in Obsidian, giving the agent context for importance and urgency. Radek reports that a Netflix payment failure was fixed within five minutes of occurring. In another case, the system caught an upcoming domain renewal in an email he might otherwise have missed, notified him through Discord, and the domain was renewed.

Project context also makes it possible to prepare a reply. The agent reads an email, considers what has already been completed in the project, and leaves a response in the draft folder. Radek can accept it, delete it or edit it. This is execution support with a visible handoff: the prepared reply is still a draft. He connects synthesis back to the inbox workflow, where new sources are interpreted and joined to existing knowledge.

Discord provides a practical interface for these different activities. Conversations begin in General. When a type of conversation recurs often enough, Radek gives it a dedicated channel. The channel screenshot in the recording, which he describes as taken that morning, shows the organization that emerged from actual use.

The Playground gives experiments a place alongside the established workflows. Its purpose changes with current needs: a different model, a different workspace, or a different arrangement of important files. If an experiment works, Radek promotes it into the working setup; otherwise, he discards it.

The system works through a division of responsibilities. LLMs supply judgment: understanding an email, interpreting context and making connections. Files, tools and scripts supply the surrounding machinery. When a task is simply a known condition followed by a known action, a script can execute it and skip the LLM entirely.

Instructions and memory also need deliberate maintenance. Radek works on his memory files, SOUL.md and AGENTS.md. After finding that instructions in the latter two could still be missed, he added a separate critical-rules Markdown document and referenced it near the top of AGENTS.md. He reports that this helped.

For a workflow such as the email drafting described earlier, a compact Markdown rule can make the intended handoff explicit:

# Critical rules

## Email replies
- Use relevant project notes when preparing a reply.
- Save the reply as a draft for review.
- Leave acceptance, editing or deletion to the user.

This illustrates the kind of durable instruction involved, not Radek’s exact file. Written rules guide behavior; they do not enforce permissions. His memory guide makes that distinction explicit, and current OpenClaw security guidance places operational controls in permissions, tool restrictions and sandboxing.

His memory arrangement evolved from one file to a whole folder. He also describes dreaming, which promotes memories. The implementation remains inspectable: these are Markdown files that he can open, read, understand and edit. That visibility gives him a way to improve what the system remembers instead of treating memory as an inaccessible internal state.

More memory and more automation create their own maintenance work:

• Bad memory compounds. A poorly organized memory system becomes more troublesome as notes and memories grow into the thousands. It needs active attention.
• Long automations become brittle. Radek uses a ten-step workflow as an example of something likely to break eventually. Split it into simpler automations or add more effective guardrails.
• Noisy nodes accumulate. He regularly cleans the knowledge base and removes entries that add noise.
• Weak boundaries need correction. He revisits SOUL.md and related files to make the intended behavior fit his needs.

Growth therefore includes pruning and simplification, not just adding another capability.

The starting point is one recurring pain. Solve it, grow trust incrementally, build the knowledge base, and move as much material as you want into Markdown so that connections can develop. Keep the system inspectable. These habits make it possible to build something useful without needing to reproduce someone else’s entire environment.

The purpose becomes clearer through Radek’s closing comparison of past, present and future selves. The past self seems lazy: it left today’s work undone. The present self carries the burden. Meanwhile, the future self gets imagined as an all-powerful creature that will somehow handle anything postponed today. That asymmetry makes deferring work feel easy.

His alternative is to treat the future self as a friend worth helping. The agent’s job is to do the delegable work that will make tomorrow easier, so that when he wakes up, as much as possible is already prepared. For Radek, that is the purpose of giving the system more access: less unfinished work waiting for the person he will be tomorrow.