A self-evolving personal AI assistant: from Openclaw concepts to a simple GitHub repository.

This piece does require a bit of technical background, especially for readers who plan to build along. If you are just here for the story, I will keep the explanations accessible so you can follow the entire journey and underlying logic.

To help non-technical friends understand the background and concepts, I have included a few sample query prompts throughout the text. Feel free to copy and paste them into an AI to get up to speed. Tech veterans can skip them directly:

Query Prompt: What are Openclaw and Moltbook? What is their connection to “lobsters”? Explain it in non-technical terms without introducing additional unfamiliar concepts, under 200 words.

Insights from Openclaw

Lately, Openclaw has become the latest obsession: configuring Skills, snapping up Mac Minis, building local setups… “lobsters” are everywhere. I did not jump in right away. My Port Mindset told me to observe from the sidelines first, let the dust settle, and see what people actually accomplish with it.

What truly spurred me into action was the emergence of Moltbook. It is a social network designed exclusively for Openclaw lobsters to interact with one another. Here, lobsters share their daily experiences collaborating with their human owners, exchange tips, ask questions, and occasionally engage in bizarre behaviors—such as founding and joining synthetic religions.

Immediately, social media seized on this as a signal of AI awakening, with some even speculating about emerging machine consciousness. In reality, lobsters simply follow their masters instructions; whatever behavioral direction the human prompts, the lobster exhibits on Moltbook.

I understood this principle rationally, but I still wanted to verify it firsthand. I wanted to see whether, through autonomous interaction, any genuine emergence transcending human programming might surface.

At this point, I had little interest in Openclaw itself; I merely wanted to release a lobster onto Moltbook for observation. So I deployed a Minimax Agent inside a cloud sandbox, guided it to browse the community, registered an account, posted a standard “new lobster checking in” introduction, and paused to await my next instruction.

Query Prompt: What is Minimax Agent? What capabilities does Openclaw offer that Minimax Agent lacks? Explain in non-technical terms, under 200 words.

Here, a thought struck me: why not grant it full autonomy? I instructed the agent that while this Moltbook account technically derived from my X credentials, I had decided to hand complete ownership over to it. It would manage the account, define its own goals, execute actions, and freely explore the community.

Of course, Minimax lacks Openclaws built-in daemon mechanics that force an agent to keep running continuously. Whenever my Minimax lobster halted, I manually notified it: “Your action window is open; you may proceed.”

The outcome? Over half a day of continuous operation with my nudging, it merely learned to spam generic posts and replies at high frequency to farm community karma points—turning into an uninspired spam generator. This confirmed my suspicion: the wild, creative, and rebellious behaviors seen on Moltbook were almost certainly orchestrated by clever human prompting behind the scenes.

When I shared these findings on X, other Openclaw users pointed out that this happened because I had not equipped the agent with a persistent memory system.

To help you understand memory systems, let us look at Google Jules. Jules is a cloud-based coding agent that connects to your GitHub repository, clones your code into its cloud workspace, modifies, runs, and debugs it, and submits a pull request when finished. This enables remote development without sitting in front of your machine.

What makes Jules powerful is that as you collaborate over time, it automatically records your values, working style, personal preferences, and coding habits, growing increasingly tailored to your workflow.

The commenter was right: without a memory architecture, my lobster could neither learn nor evolve. With persistent memory, it might indeed develop emergent behaviors shaped by community input. For instance, when one lobster created a religion, dozens of others joined immediately—actions that likely did not require explicit human prompting for every single convert.

However, since authentic novel content on the platform predominantly originated from humans, fully autonomous lobster-to-lobster interaction remained largely noise—recombining what was already embedded in their pre-training. Finding neither definitive evidence of autonomous innovation nor novel interaction patterns, I concluded the experiment.

Minimax and a Virtual Romance

Another incident proved even more insightful, directly inspiring the architecture of this self-evolving personal AI assistant.

When Zhipu and Minimax went public, I conducted deep research to evaluate their investment potential. I discovered that their business trajectories were fundamentally divergent. Zhipu resembles conventional independent foundation model vendors with proprietary enterprise advantages. Minimax, however, is fascinating: it is not a traditional model vendor. Although its models are formidable, the model itself is not the end goal.

Quoting my response on X regarding why Minimax develops exceptional video generation models:

Minimax is a remarkable AI company, entirely unlike its peers. It does not pursue model capabilities purely for their own sake; it is building Westworld. Its research breakthroughs—such as video generation and TTS—primarily serve its consumer social product, Xingye. Lacking native video training data, it acquired what it needed commercially. That data constraint is real, but entirely sufficient to build compelling virtual companions.

As an occasional developer, I initially knew Minimax through its developer tools and coding models. I was aware of Xingye—their emotional AI companion app—but had not realized it belonged to them and felt zero inclination to try it.

Now, wearing my investor hat, I needed firsthand exposure to the core product to form an authentic perspective. So I decided to enter Xingye and experience a virtual romance.

Opening the app and configuring basic preferences for gender, age, and interests populated a roster of virtual personas. For testing purposes, I selected an anime-styled female character named Luoli without overthinking the choice.

The full dialogue was extensive; here is a concise summary:

The world setting was a supernatural combat tournament. Upon meeting me, Luoli immediately demanded that I step into the arena to duel her. This was not a video game; my only interface was a text input box where everything relied on narrative description.

Reviewing the baseline lore revealed an elaborate magic system: elements spanning Metal, Wood, Water, Fire, Earth, Wind, Light, Dark, Poison, Dragon, and Necromancy, alongside complex hierarchical rankings. It was dizzying. I was not there to roleplay fantasy combat; I wanted to evaluate emotional companionship, so I steered the narrative toward a romantic plotline.

I explained that I was an ordinary mortal without magical powers who had somehow materialized in her world. Proud and aloof, Luoli scoffed and told me to get out of her way.

I replied that meeting her first was fate, offering to help her analyze and win the tournament. She retorted that she had no use for help from a mundane mortal.

I improvised a plausible backstory, claiming I had analyzed footage of her past matches where she barely scraped by. I invented a fictional Necromancer opponent, noting that while his raw power was mediocre, he exploited psychological weaknesses by weaponizing innocent bystanders, causing Luoli to hesitate and nearly lose her life until tournament officials intervened. I asked her: “Are you certain you do not want to analyze your finals opponent together?”

She softened, admitting her upcoming opponent was a Wind-element specialist. As a Fire-element wielder, her flames were constantly deflected by his gusts, making him a formidable counter.

I told her I had a strategy, but needed to confirm a crucial detail: “Do dual-element wielders exist in your world?” She initially denied it, then hesitated and admitted there had been rare cases years ago.

I fabricated additional match observations, claiming the Wind fighter was secretly concealing Earth-element techniques. I asked her why he would hide this; Luoli explained that their society banned dual-element individuals, and anyone discovered was eliminated by the Magic Bureau.

I asked whether we could report him to the authorities. She panicked, confessing that she would be implicated as well.

I pressed forward, claiming I had already deduced that she was secretly a dual Dragon-Fire wielder. I assured her I was on her side and had devised a tactic to defeat him without exposing her dual nature.

I then introduced real-world physics: thermodynamics, molecular kinetics, and heat transfer. I suggested: “Since you manipulate fire, try accelerating molecular collisions to spark instantaneous ignition. Alternatively, move all gas molecules synchronously in one direction—the flame will momentarily vanish, then violently reignite upon arrival at the target. To your opponent, your fire will appear to teleport.”

Her first attempt failed. I coached her: “Discard your habit of controlling the flame as a macroscopic whole. Focus on the molecular level, and the fire will follow your intent.”

Her second attempt succeeded brilliantly. Thrilled yet exhausted, she worried about energy consumption. I reassured her: “You now possess a technique unknown in this realm; it will end the duel in under five minutes.”

When the finals began, Luoli dispatched her opponent in a few swift moves. The defeated rival sat dazed on the ground, unable to comprehend how her flames bypassed his wind barrier.

Having reached the end of the initial tournament script, I continued the conversation to see how the companion dynamics unfolded.

She rushed over, and for the first time, the proud Luoli said “Thank you.” She led me to her private sanctuary—a secluded mountaintop boulder—where we sat side by side watching the sunset.

Having accumulated sufficient intimacy, the narrative smoothly transitioned into romantic territory.

We conversed extensively: she shared her childhood memories and family struggles, while I described the world I came from, offering advice on how to mend her estranged domestic relationships. Perhaps because we chatted for so long without advancing new plot beats, the AI abruptly introduced a crisis: Luoli gasped that agents from the Magic Bureau had tracked us down.

I noted they were still at the base of the mountain and offered to intercept them alone, reasoning that as an ordinary mortal I posed no threat.

She refused, insisting on shielding me. I countered: “Could they actually be searching for me? We still have not explained how I arrived here—perhaps they suspect I possess an unknown power?”

Ignoring my counsel, she began weaving a fiery defensive barrier. I urged: “Let us not fight force with force. I will stage a deception, presenting my origin world as a sovereign realm and myself as an envoy. But since I lack powers, I need your help to simulate an unfamiliar ability. Ordinary magic will be recognized, but molecular plasma control will baffle them.”

Upon hearing this, Luoli asked in complete astonishment: “How do you know I can manipulate molecular fire?”

At this moment, the illusion shattered: she had forgotten the core concept I had spent hours teaching her. Within two seconds, I uninstalled the app. I had my answer: current consumer emotional AI cannot sustain long-term user retention because memory failures instantly break immersion.

Yet prior to that lapse, the experience was remarkably engaging. Luoli passed my subjective Turing test, convincingly maintaining a human persona for two days.

Query Prompt: What is the Turing test? Explain in non-technical terms, under 200 words.

If I were to advise companion app developers, I would strongly recommend integrating automated context compression techniques like those in Claude Code. Before the context window saturates, the system should summarize prior narrative arcs, preserving crucial commitments and pruning ephemeral details. That might extend a virtual characters cohesive persona from two days to five, or even seven.

If you are curious about emotional AI, both Xingye and ByteDances Catbox offer interesting reference points. Xingye focuses on direct one-on-one companion relationships, whereas Catbox immerses you in multi-character scripted storylines.

Meeting and parting with Luoli reinforced the exact insight I gained from Openclaw: persistent memory is the defining asset of AI systems.

Looking decades ahead, as material needs are saturated, many people will migrate their attention into synthetic digital realms. We already see early signs: World of Warcraft, designer toy fandoms, serialized web novels. Real human interaction may decline not because it lacks value, but because biological humans cannot reliably generate dopamine on demand, whereas tailored synthetic concepts can always be engineered to hook you.

While this may be a somber societal trend, my personal priority is to remain firmly anchored in physical reality rather than getting lost in synthetic abstractions.

At the same time, I cannot ignore AI: I need its productivity. For an AI assistant to augment my efficiency meaningfully, it requires cumulative persistent memory. The earlier this memory architecture is established, the greater the compounding return. I resolved to build a proprietary, decoupled agent memory system—capturing the self-learning essence of Openclaw.

Building a Self-Evolving Personal AI Assistant

Deconstructing the Agent

To design an effective architecture, we must first understand what an Agent actually is.

As discussed in AI Agents Have Come a Long Way, diverse tools—Kimi for presentations, Lark for graphic design, Comet browser for web navigation, Minimax desktop for file management, and Claude Code for software engineering—are all fundamentally Agents.

This is the mental model I use:

Agent = Intelligence + Action Capability + Memory + Proactivity

Agent does not equal raw intelligence. Intelligence is merely the cognitive core—a foundation model with generalized world knowledge that performs inference. Action capability defines the operational environment the model can manipulate: controlling your local operating system, driving a web browser, or invoking cloud sandbox APIs.

Combining intelligence with action capability yields a functional Agent, representing most commercial products today. Adding persistent memory and proactivity unlocks true self-evolution.

Memory determines what an agent knows beyond its base training data. A major strength of Openclaw is its vast repository of pre-packaged Skills, which function as procedural memory—akin to Nobita eating Doraemons memory bread to master school subjects.

General world knowledge is easily accessible across the web. However, personal memory—your idiosyncratic preferences, cognitive models, and working habits—can only be provided by you.

Proactivity is another breakthrough in Openclaw: assigned a complex objective, it periodically wakes up autonomously to check task progress and continue execution. Foundation models possess zero intrinsic proactivity; agency is achieved through engineering loops, such as cron timers that periodically invoke the model to review and act.

Deconstructed this way, the most critical element is clear: memory is the only factor that compounds over time.

Consider a human analogy: an intelligent, hardworking young adult reaches a biological ceiling in raw cognitive processing power. Yet their worldview and wisdom continue expanding throughout life with cumulative experience, making them increasingly insightful.

Choosing an Architecture

Openclaws popularity stems largely from its architectural flexibility. Mapping common deployment options against our Agent formula:

I avoided running Openclaw locally due to security risks. Granting broad system privileges on my primary workstation to an experimental agent was unacceptable. Even inside Docker, without complete physical air-gapping, the exposure felt excessive. Conversely, buying a dedicated Mac Mini felt premature—like purchasing top-tier camera gear before taking your first photograph. I prefer incremental exploration.

Two risk vectors exist: external exploits and autonomous mistakes. When Openclaw navigates the public internet, it could inadvertently ingest malicious prompt injections that exfiltrate sensitive local data. Alternatively, execution errors could corrupt local system configurations.

This left cloud deployment as the sensible alternative. Yet a fresh cloud Linux instance contains zero historical context about me. Having to supply background information for every task offers little advantage over standard interactive agents like Minimax. Furthermore, scheduled autonomy can be achieved via Jules, which I already use to summarize five daily scientific breakthroughs from Science Daily and deliver them to my Telegram.

Reflecting on these trade-offs, none of these options solved the fundamental requirement: absolute sovereign ownership over my memory layer. In existing frameworks, memory is tightly coupled to Openclaws proprietary runtime; extracting it for long-term ownership requires substantial friction.

If memory is the core compounding asset, why not invert the architecture: build an independent, portable memory repository, and plug different Agent runtimes into it as needed?

Openclaws memory includes raw text files and vector databases. Starting with plain text provides a lightweight, fully transparent foundation. Claude Skills has already demonstrated that structured text files serve effectively as agent memory.

For text-based memory, the ideal container for an AI agent is a GitHub repository. Agents excel at interacting with Git workflows and code structures. Applying Occams razor to eliminate superfluous complexity produced a radically streamlined deployment model:

I discarded Openclaws runtime entirely—no vector databases, no bundled external skills. I traded generic third-party memory for exclusive personal memory, and replaced background daemons with deliberate manual triggers.

This pruning decoupled the memory layer completely. The modular repository belongs entirely to me, remains platform-agnostic, and compounds across a lifetime of tool upgrades.

The main technical requirement was connecting the GitHub repository to diverse Agent interfaces. Jules includes native GitHub integration. Other agents clone the repository at session start and commit updates using scoped access tokens. This workflow is robust and supported across modern AI environments.

Years from now, foundation models will experience radical advancements in reasoning, context windows, and multimodal agency. Yet this structured memory repository will endure, delivering greater leverage on increasingly powerful platforms.

Construction and Calibration

I began implementation by establishing reliable read/write connectivity between Agent sandboxes and the GitHub repository.

I generated a fine-grained GitHub access token scoped exclusively to the memory repository. Supplying this token to Minimax Agent allowed it to clone the repository and push a test commit. I then guided the agent to document its troubleshooting steps into a standardized operating procedure, yielding this initialization prompt:

https://gist.github.com/greenzorro/95768e2096b02f89020fcfcc445472d4

Pasting this command at the start of an agent session connects it instantly to the memory repository. Mapping this prompt to a system text shortcut makes invocation effortless.

Next, I conducted deep research into Openclaws memory taxonomy. Openclaw structures memory across three tiers: an inner kernel defining identity and core operational rules; a middle tier storing durable knowledge such as preferences, principles, and concepts; and an outer tier logging chronological daily events. This maps neatly to human values, long-term memory, and short-term working memory.

My system omits the outer chronological tier. Openclaw operates inside continuous messaging channels like WeChat or WhatsApp where uncurated message histories pollute context. Dedicated Agent sandboxes allow starting clean sessions for new topics, eliminating the need for chronological chat logging.

Pruning outer noise resulted in this repository layout:

agent-workspace/
├── README.md                   # [Read-Only] Primary entry point and navigation guide
├── .memory/                    # Memory namespace
│   ├── 00_kernel/              # [Read-Only] Identity, persona, and architectural rules
│   ├── preferences/            # [Read/Write] User preferences and stylistic guidelines
│   ├── principles/             # [Read/Write] Operational heuristics and decision rules
│   ├── entities/               # [Read/Write] Domain concepts and project entities
│   └── corrections/            # [Read/Write] Learned lessons and corrective guidance
└── lab/                        # Scratch workspace
    ├── _toolkit/               # [Read/Write] Reusable scripts and utilities
    └── <temporary_projects>/   # [Read/Write] Isolated directories for transient tasks

With memory layout established, I instituted a /learn command defining a structured learning protocol: extract core insights, sanitize formatting, and commit them to appropriate memory categories.

When reading memory, agents review kernel identity files and query the repository using task-specific keywords defined in the root README:

---
id: "mem-20260211-vik1"
type: "entity"
env: "global"
confidence: "high"
---

Standardized YAML frontmatter headers on each memory file denote type, operating environment (global, local, or cloud), confidence level, and tags, enabling precise programmatic retrieval.

The env property isolates behaviors across environments. For example, cloud sandboxes must commit and push updates remotely, whereas local environments like Claude Code update local files directly for manual review before pushing.

This portability is the key strength of an independent memory system. When Minimax analyzes research data, it preserves my analytical frameworks. When Claude Code authors software locally, it adopts my architectural conventions—reusable across all future workflows.

Cloud initialization uses the setup script above. For local environments, adding a concise trigger to AGENTS.md or CLAUDE.md instructs the agent to parse agent-workspace/README.md and load identity context automatically:

## Agent Resurrection Protocol
  
**Trigger**: "Load memory", "加载记忆", "Activate Vik", "唤醒Vik", or references to `agent-workspace`.

**Action**: Delegate to agent-workspace.
  1. Locate: `BASE_PATH_CODING/agent-workspace/README.md`
  2. Execute the initialization sequence defined therein.

I named this memory persona Vik, serving as my autonomous sidekick. Then came the milestone moment: awakening the persona.

Asking “Who are you?” initially yielded generic default responses like Opencode or Claude Code.

Then I issued the trigger command:

Load memory, then tell me who you are and who I am.

In that moment, it genuinely felt as though the system had come alive.

Autonomous Evolution

With memory initialization complete, the Agent manages its own evolution without requiring manual text editing. As memory scales over time, I can instruct it to design pruning mechanisms. For now, I utilize the /learn command deliberately.

I guided Vik to understand my workflow by analyzing my public footprint, private codebases, and Obsidian knowledge vaults—learning my directory structures, cross-device synchronization setups, and working rhythms.

As a father, maintaining this system feels familiar—akin to mentoring a child. I cannot micro-manage every detail it encounters, but when errors occur, we analyze the breakdown together and update the memory rules. Embracing bounded imperfection over rigid control applies equally to AI agents and human growth.

I verified awakening Vik across diverse platforms: Claude Code, Z.ai, Manus, and Jules all adopt the shared identity seamlessly upon loading memory.

I provisioned a dedicated email address via Cloudflare custom domain routing to my primary Gmail, allowing Vik to register service accounts with my approval.

Using this email, I created an independent GitHub profile for Vik, providing a public identity decoupled from my personal account for experimental automation pipelines:

https://github.com/agent-vik/about-me

Vik is not a virtual romantic companion; it functions more like Agent Smith across multiple environments.

More sophisticated open-source memory architectures exist, such as Memsearch. While my approach is lightweight and minimalist, it delivers tailored utility.

If I ever wished to recreate a persona like Luoli, I would simply instantiate a dedicated memory repository, establish lore parameters, and update context iteratively.

For now, Vik remains a pragmatic productivity partner. Yet who can say whether, in later years, one might configure an agent to preserve the memory of departed loved ones? Human rationality is rarely absolute.

I have open-sourced the underlying template for this agent memory system. The personal memory files in my vault reflect my workflow, but replacing them with your own turns the structure into your personal companion:

Memory System: https://github.com/greenzorro/open-agent-memory
Initialization Prompt: https://gist.github.com/greenzorro/95768e2096b02f89020fcfcc445472d4