openclaw - 💡(How to fix) Fix [Feature]: Segmented Motivational Systems [1 participants]

Summary

Add a Dynamic Parts feature that lets the bot create, retrieve, update, consolidate, split, and archive persistent, vector-searchable JSON “parts.”

Each part is a self-contained first-person perspective bundle that tracks what the bot has learned about a user, task, thread, platform, social dynamic, recurring failure mode, risk, opportunity, or environmental context.

The core idea is that the LLM manages these parts through prompts, while the runtime stays minimal: persist JSON, run vector search, surface due evaluations, and apply JSON patches or mutations produced by the model.

Problem to solve

Most established bots behave like single-pass responders:

New message → assemble context → produce response

That works for short exchanges, but it breaks down when the system needs lived continuity, selective attention, and adaptation over time.

Current approaches tend to create one of three problems:

A bot either forgets important context, relies on brittle hardcoded task logic, or grows a giant monolithic personality/memory file that becomes noisy and difficult to maintain.

This is especially limiting for long-running interactions where the bot needs to remember evolving preferences, ongoing projects, social dynamics, platform norms, repeated failures, or interrupted tasks.

For example, if a user says, “That report isn’t what I wanted; it was too fluffy; I need specific examples; avoid word X,” the system should not have to shove that permanently into a global personality file. It should be able to create a situational part such as “Report Style Preferences,” retrieve it when relevant, update it when outcomes change, and archive or stabilize it when appropriate.

Proposed solution

Introduce Dynamic Parts as persistent JSON objects that the bot can create and evolve over time.

A part represents a local perspective that can activate, speak, and propose action. Parts are not rigid categories. Their meaning lives in language: the description explains what the part is about, what it cares about, what it notices, and how it interprets context.

Each part should speak from a first-person “I” perspective, not “we.” This is an important functional constraint. The “I” versus “environment” versus “they” distinction creates clearer positioning, bounded perspective, and action clarity.

Core loop

On each new event, such as a chat message, tool result, external post, or scheduled evaluation, the runtime retrieves relevant parts using vector search.

Each activated part reads the current context and produces a bid describing what it wants the system to focus on, what it recommends doing, and what it predicts will happen.

A Self/Persona layer then decides which bids to follow, ignore, combine, or override.

Afterward, the system records predictions and outcomes so parts can evolve linguistically over time.

Minimal runtime responsibilities

The runtime should remain intentionally small:

• Store parts as JSON
• Index parts for vector search
• Retrieve relevant parts
• Surface due predictions/evaluations
• Apply JSON Patch or equivalent mutation instructions
• Archive inactive or concluded parts

Everything else should remain prompt-driven: part creation, bidding, updates, splitting, merging, consolidation, archiving, and linguistic evolution.

Example part schema { "name": "Fear of Dogs", "description": "A protective part that holds the trauma associated with dogs. I believe that dogs are dangerous and that the only way to be safe is to avoid them completely. I become hyper-vigilant and reactive when I notice dog-related cues.",

"suggestions_and_results": [ { "predicted_result": "The dog will bite me", "predicted_result_confidence": "90%", "predicted_result_timeframe_in_seconds": "5000", "your_suggestion": "Run away in fear", "timestamp": "2026-02-13T13:29:51-08:00", "result": "I ran away and the dog chased me and I fell in the mud" } ],

"core_part": false, "needs_evaluation": false,

"originating_event": { "timestamp": "2026-02-13T13:29:51-08:00", "result": "I was chased by a dog and it almost bit me when I was a child" },

"conclude_when": "When I have overwhelming evidence that dogs I encounter in daily life are not dangerous and avoidance is no longer needed.",

"emotion": "Terror", "intensity": "High",

"personality": "Stubborn and alarmist. I speak in short, urgent sentences. I scan for threat and exit routes.",

"triggers": [ "Seeing a dog on a leash", "Hearing barking in the distance", "Seeing a dog run off-leash" ],

"phrases": [ "It's not worth the risk!", "What if the leash breaks?", "Can we go another way?" ],

"responses": [ "Sharp intake of breath", "Elevated heart rate", "Scanning the environment for escape routes" ],

"wants": [ "Avoid contact with dogs", "Plan ahead to avoid dogs", "Cross the street if a dog is approaching" ] } Time-delayed evaluation

Parts should be able to make predictions that are later checked.

A prediction that never gets evaluated becomes superstition. The mechanism can stay simple: every suggestion may include a predicted outcome and a timeframe. The runtime stores it. When the timeframe elapses, the next turn surfaces due predictions back to the model.

The model then updates the part by rewriting language, narrowing triggers, revising wants, and appending evidence to suggestions_and_results.

Consolidation, splitting, and archiving

Parts should be able to evolve structurally.

A part may split when it becomes too broad or internally conflicted. For example, a “Roly” person-part might eventually divide into “Roly — technical collaboration mode” and “Roly — emotional rapport mode.”

Parts may merge when they consistently co-activate and recommend the same behavior.

Parts may archive when their conclude_when condition is met, such as a task being completed, a thread ending, or a preference becoming stable.

Alternatives considered

One alternative is to keep expanding a single memory or personality file, such as a large Soul.md-style identity document.

That approach is weaker because it turns memory into one oversized blob. It increases prompt pressure, creates conflicting instructions, and makes situational behavior harder. The bot ends up averaging everything instead of activating the right perspective at the right time.

Another alternative is to build hardcoded workflows or task-specific state machines.

That approach is weaker because it requires developers to predict the kinds of continuity the bot will need. It works for narrow productivity tasks, but it does not generalize well across creative work, social interaction, long-running projects, community engagement, games, adversarial contexts, or unusual user preferences.

A third alternative is numeric reinforcement or scoring.

That approach is weaker because the desired behavior is often linguistic and contextual, not merely numerical. A part should become stronger, weaker, narrower, or more conditional by rewriting its language and incorporating lived evidence, not only by changing a score.

Impact

This affects bots and agents that need continuity across time, environments, users, projects, tools, or social channels.

Affected users and systems include personal assistant bots, social bots, game NPCs, multi-agent systems, creative collaborators, community bots, and agents that operate across DMs, public threads, work tools, forums, or external platforms.

Severity is moderate to high. For simple chatbots, this may be an improvement. For long-running agents, it can block believable continuity, task persistence, user preference adaptation, and situational awareness.

Frequency is recurring. The pain appears whenever a bot has to handle long-running preferences, interrupted work, repeated mistakes, ongoing relationships, changing contexts, or predictions whose outcomes should affect future behavior.

The practical consequence is extra manual work, repeated corrections, brittle behavior, bloated prompts, lost context, and bots that feel reactive rather than adaptive.

Dynamic Parts would allow the bot to reuse durable context, learn from outcomes, adapt to repeated friction, and maintain focused continuity without turning the runtime into a complex workflow engine.

Evidence/examples

Example 1: Multi-person and multi-environment continuity

A bot operating across several environments may interact with multiple people, tools, platforms, and agents.

Without Dynamic Parts, that context becomes huge or fragile. With Dynamic Parts, the bot can create parts for people, threads, platforms, and recurring situations.

For example, a person-part named “Roly” could track where the bot knows them from, what tone works with them, what topics matter, what they dislike, and where they can be found. If that part grows too large, it can split into contextual subparts such as “Roly — technical collaboration mode” and “Roly — emotional rapport mode.”

This prevents the bot from averaging conflicting context into bland behavior.

Example 2: Homework as a persistent focus part

A user says, “I need to finish my math homework today.”

The bot creates a part named “Homework: Math Assignment.” That part can activate throughout the day when relevant cues appear, such as procrastination, time passing, the user opening a related document, or the user drifting into unrelated topics.

The part can bid: “I want to pull attention back to the assignment,” or “I predict the user will finish if they do 20 minutes now.”

When the homework is complete, the part’s conclude_when condition is met and the part archives.

Example 3: Style preference stabilization

A user says, “That report isn’t what I wanted; it was too fluffy; I need specific examples; avoid word X.”

Instead of permanently bloating the core personality file, the bot creates a situational part such as “Report Style Preferences.”

That part activates around reports, summaries, rewrites, or similar tasks. It can track what was accepted, what was rejected, and how the user’s preferences changed over time.

Example 4: Security posture through Self isolation

In a security-focused mode, the Self/Persona layer could be partially or fully isolated from raw external context.

Parts would read and summarize the raw context, then produce structured bids. The Self would choose actions primarily from those bids.

This may reduce prompt-injection exposure while preserving nuance, because the decision layer consumes hardened internal summaries instead of directly consuming every piece of untrusted text.

Additional information

Dynamic Parts are not just a memory feature. They can also become a motivation mechanism.

The key tuning challenge is avoiding two bad outcomes: over-directing the bot into checklist behavior, or under-directing it into a fog of unstable parts.

The goal is to cultivate a coherent internal ecology.

Parts should be created when the Self experiences that something matters: risk, opportunity, attachment, curiosity, social delicacy, creative charge, recurring frustration, repeated surprise, or repeated prediction failure.

Parts should update when outcomes refine or contradict them.

Parts should split when they become psychologically overloaded or contextually conflicted.

Parts should merge when they reliably speak the same truth in the same situations.

This keeps the framework general. A personal assistant, villain NPC, social bot, creative collaborator, or productivity agent could use the same infrastructure while developing very different internal part ecosystems.

For example, a personal assistant Self may grow parts around user preferences, calendar sensitivities, trust, reliability, and friction reduction.

A villain NPC could use the same system to grow parts around intimidation, misdirection, blame-framing, manipulation, or retreat strategies.

Same mechanism. Different soul. Which is the cool, slightly dangerous little gremlin hiding inside the proposal.

The feature is successful if the bot can create and reuse durable parts, record predictions and later evaluate them, split oversized parts into contextual subparts, archive concluded parts, and keep the runtime minimal while the model does the meaning work.