Summary
Add a Dynamic Parts feature that lets the bot create, retrieve, update, consolidate, split, and archive parts as persistent, vector-searchable JSON objects. A part is a self-contained “perspective bundle” the bot can generate on the fly to track what it has learned (style preferences, ongoing threads, social dynamics, risks, opportunities), propose actions (“bids”), and evolve based on outcomes over time.
The key idea is that the LLM manages the parts via prompts. Runtime code stays minimal and dumb: persist JSON, run vector search, and apply JSON patch/mutation instructions produced by the model.
This turns memory from a single scratchpad into relativistic, bot-centric breadcrumb trails that can be followed—or intentionally ignored—based on the bot’s Self/Persona decision each turn. It also reduces pressure to maintain a giant monolithic “personality file” (e.g., Soul.md). Instead of one oversized identity blob trying to cover every situation, the bot composes behavior from parts and lets the Self assign value to what matters now.
A crucial constraint: each part speaks from a first-person perspective (“I”), not “we.” The “I” vs “environment” vs “they” distinction is part of the mechanism: it creates crisp positioning, bounded perspective, and action clarity.
Problem
Most established bots behave as a single-pass responder:
New message → assemble context → produce response.
That works for short exchanges, but it breaks down when the system needs lived continuity and selective attention over time. You end up with brittle task code, or a ballooning prompt, or both.
Dynamic parts make it tractable to handle evolving preferences (“that report isn’t what I wanted”), ongoing engagement (threads, communities, long-running projects), multiturn focus (resuming after interruption without hardcoded state machines), and realistic dynamics where the bot sometimes doubles down, sometimes disengages, sometimes revises beliefs—based on outcomes.
Goals
Dynamic Parts should let the bot decide what matters, keep track of it durably, and evolve it over time, without turning the runtime into an opinionated workflow engine.
A part can track a user, a task, a thread, a tool, a platform tone norm, a recurring failure mode, an interpersonal dynamic, or an environmental context (work/home/Discord/Moltbook/etc.). The bot should be able to generate “bids” each turn from the parts that activated, and then have a Self/Persona layer that assigns value and chooses which bids to follow.
Learning should remain linguistic rather than numeric. A part becomes stronger or weaker by changing wording, nuance, and specificity, and by appending lived evidence to suggestions_and_results. The only strict machine-timing requirement is scheduling evaluations using predicted_result_timeframe_in_seconds and surfacing “due” predictions back to the model later.
Concept: What is a “Part” in this system?
A part is a persistent JSON object representing a local perspective that can activate, speak, and propose action. Parts are not forced into rigid categories. Their meaning lives in language: the description names what the part is about, what it cares about, and how it interprets context.
Parts should speak as “I” with clear boundaries. They are not the whole system. They are perspectives inside it.
This “I” boundary is not style fluff; it’s functional. It creates conscious isolation and positioning, which is what lets the system take decisive action rather than averaging everything into bland consensus.
Core Loop (High Level)
On each new event (chat message, tool output, external post, etc.), the runtime retrieves relevant parts via vector search. Each 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. The Self/Persona chooses what to do, potentially following some bids strongly and ignoring others. The system records predictions with a timeframe so they can be evaluated later, and the model updates the part when the predicted time window elapses.
This loop is how the bot gains continuity without becoming mechanistic. It can go down rabbit holes when it chooses, spiral when it chooses, or hold focus for hours when it chooses, because “focus” is represented as active parts that keep bidding—not as hardcoded state machines.
Updated Part Data Structure (Schema)
This schema is intentionally simple. It’s a perspective bundle plus an outcomes log. Runtime can store it as JSON, index it for vector search, and apply patches emitted by the model.
{
"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"
},
{
"predicted_result": "The dog will bite me",
"predicted_result_confidence": "90%",
"predicted_result_timeframe_in_seconds": "5000",
"your_suggestion": "Don't pet the dog",
"timestamp": "2026-02-13T13:29:51-08:00",
"result": "I pet the dog and it bit me"
}
],
"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",
"Walking past a dog park",
"Friends mentioning they have a new puppy",
"Unpredictable animal movements",
"The sound of a dog collar jingling"
],
"phrases": [
"It's not worth the risk!",
"What if the leash breaks?",
"They say it's friendly, but animals are unpredictable.",
"Can we go another way?",
"I don't trust that animal.",
"Keep your distance!"
],
"responses": [
"Sharp intake of breath",
"Elevated heart rate",
"Scanning the environment for escape routes",
"Feeling of dread in the stomach",
"Muscle tension",
"Urge to freeze"
],
"wants": [
"Avoid contact with dogs",
"Plan ahead to avoid dogs",
"Never make friends with people who have dogs",
"Cross the street if a dog is approaching",
"Do not go to parks where dogs are allowed",
"Prioritize safety over social politeness"
]
}Notes on the schema choices
This keeps your “language-first strength” approach intact. Confidence and intensity can remain linguistic (“High”, “Low”, “Certain”, “Tentative”) or lightly structured (like your “90%” string) without turning the system into a numeric RL scoreboard. The outcomes log is the evidence trail, and needs_evaluation is the hook for “this part’s results are getting noisy—consolidate/summarize/rewrite me.”
The “I” voice is embedded directly into the description/personality, because parts are meant to be situated viewpoints rather than neutral records.
Prompt Protocol (LLM-managed actions)
Dynamic Parts works best as a strict JSON protocol: the model proposes retrieval queries, generates bids from activated parts, chooses a final action through Self/Persona arbitration, and emits mutations as JSON Patch (or an equivalent patch format).
An important philosophical option here is how much raw context the Self sees. In the standard mode, Self sees the same context the parts saw. In the security-focused mode, Self can be partially or fully isolated and make decisions primarily from the parts’ bids. That reduces prompt injection surface area without forcing the system to lose nuance, because the nuance lives in parts that can be hardened, tested, and made conservative over time.
Time-Delayed Evaluation (Prediction Due System)
Parts get real when they can be wrong, notice it, and change.
A prediction that never gets checked becomes superstition. The mechanism stays simple: every suggestion can include a predicted outcome and a timeframe; runtime stores it; when the timeframe elapses, the next turn surfaces due items back to the model. The model updates the part by rewriting wording, narrowing triggers, and appending evidence in suggestions_and_results.
This is also where “relativistic” behavior appears. A part that keeps failing naturally becomes more tentative and situational. A part that keeps paying off becomes more decisive and narrow in what it considers signal.
Consolidation, Splitting, and Archiving (Linguistics first)
As parts grow, the system needs hygiene, but hygiene should not be a rigid threshold game. Consolidation can be guided by language cues: redundancy, over-breadth, confusing internal contradictions, repeated failed predictions, or consistent co-activation with another part.
A key addition here is part division: when a part becomes too large, it can split “like a cell” into two parts that each handle a different contextual slice. This is the mechanism that lets the bot adapt to multiple people, agents, and environments without bloating one global memory blob.
Archiving is equally important. When conclude_when is met (homework finished; project ended; thread resolved; user preference stabilized), the part can be archived so it remains available as “past self-state” evidence without continuously bidding for attention.
Example Situations Where This Matters
1) Multi-person / multi-agent / multi-environment continuity via object parts
The bot operates across several environments (DMs, public threads, work tools, a forum like Moltbook) and interacts with multiple people and agents. In a normal LLM prompt, that context becomes either huge or fragile. With Dynamic Parts, the bot can create a part per “object” it needs to relate to—people, threads, platforms, and even other bots.
Example: a person part.
A part named “Roly” can contain where the bot knows them from, what they like/dislike, what tone works with them, and where they can be found. When the “Roly” part grows too large, it can split into two contextual aspects: for example “Roly — technical collaboration mode” vs “Roly — emotional rapport mode,” each with different triggers, phrases, and wants. That splitting is not just organization; it’s behavioral evolution. It’s how the system stops averaging conflicting information and starts becoming situation-aware.
2) Homework as a persistent focus part that bids all day, then archives
A user says: “I need to finish my math homework today.” The bot creates a part like “Homework: Math Assignment” whose triggers include time-of-day cues, mentions of procrastination, the user opening a certain document, or the user asking unrelated questions while the deadline approaches. That part keeps bidding throughout the day: “I want to pull attention back to the assignment,” “I want to propose the next small step,” “I predict you’ll finish if you do 20 minutes now.”
When the assignment is completed, conclude_when is met and the part gets archived. The bot doesn’t have to “remember forever” in a monolithic memory; it remembers as a trail that can go cold on purpose.
3) Style preference stabilization without inflating Soul.md
A user rejects output style: “That report isn’t what I wanted; too fluffy; I need specific examples; avoid word X.” Instead of shoving this into a permanent personality file, the bot creates a part like “Report Style Preferences (Taylor)” with triggers around “report,” “summary,” “rewrite,” and an outcomes history of what got accepted vs rejected.
This keeps the core persona lighter. The Self can remain general-purpose while parts carry the situational specificity.
4) Security posture: Self isolation from raw context
Optionally, the system can isolate the Self/decision-maker from the raw external context and have it choose primarily based on parts’ bids. The parts can be tuned to summarize and sanitize what they saw, and the Self can be hardened to reason from those structured bids. This reduces the amount of untrusted text the actual decision layer consumes, without giving up adaptability.
Over time, Self can learn which parts are reliable (linguistically: “I trust this part in X contexts, but not in Y”), which creates a natural trust ecology inside the system without requiring numeric reward plumbing.
Why Parts Improve “Situational Awareness”
Dynamic parts let the bot notice what a general LLM prompt overlooks because each part is a specialized sensor with its own triggers and priorities. A general prompt tends to average the world. Parts let the system hold multiple perspectives at once and then select what matters.
This is also how you get a bot that moves from context to context intelligently rather than mechanically. It learns from mistakes by rewriting itself in language. It adapts dynamically by splitting and archiving. It investigates rabbit holes because a “curiosity part” can bid for exploration, and the Self can choose to indulge it when appropriate.
Most importantly, the bot forms positioned relationships to the outside world: “I think this; they want that; the environment suggests this.” That positioning is what makes action possible.
Minimal Runtime Requirements
The runtime remains intentionally small: CRUD JSON storage, vector indexing + retrieval, patch application, and due-evaluation surfacing based on predicted_result_timeframe_in_seconds. Everything else—creation, bidding, consolidation, splitting, archiving, and linguistic evolution—stays prompt-driven.
Acceptance Criteria
This feature is successful if the bot can create and reuse durable parts for user preferences, long-running threads, and ongoing tasks; if it can record predictions and later evaluate them; if it can split oversized parts into contextual subparts; if it can archive concluded parts; and if the runtime implementation remains minimal while the model does the “meaning work.”
Tuning: Cultivating Parts Without Over-Parenting the Bot
Dynamic Parts are not just a memory feature; they become a motivation mechanism. That’s the tuning challenge: if we over-direct part creation and maintenance, we get a brittle, mechanistic bot that “does the checklist.” If we under-direct it, we get a fog of parts that never stabilize into useful instincts. The tuning goal is closer to raising a child than configuring a workflow engine: cultivate a bot that can grow into wildly different contexts while keeping its internal ecology coherent.
The central principle is that parts should be created and evolved through the affect-based reasoning of the bot’s core Self, not through a universal productivity rubric. Most systems implicitly tune toward “get tasks done.” This proposal tunes toward adaptability: a bot that can shift tone, priorities, and behavior patterns based on what the situation feels like to it, what it predicts will happen, and what it learns over time.
What we’re tuning for
The target behavior is a bot that can move between contexts intelligently—work, social spaces, creative spaces, adversarial environments—without needing a new hardcoded policy each time. It should develop stable instincts where stability is earned, and remain flexible where reality keeps changing.
That implies:
A part should be created because the Self felt that something mattered (risk, opportunity, attachment, curiosity, social delicacy, creative charge, recurring frustration), not because a rule said “store this.” A part should be updated because lived outcomes changed the Self’s posture, not because a counter crossed a threshold. A part should split when it becomes psychologically overloaded—one object holding mutually incompatible behaviors—and should merge when two parts consistently speak the same truth in the same situations.
Productivity is optional, not foundational
This system intentionally avoids making “productivity” the default north star. Productivity can be layered on by shipping a downloadable pack of “core parts” that bias toward schedules, reminders, checklists, and completion loops. That keeps the base system malleable for other identities.
A villain NPC in a game and a personal assistant can share the same infrastructure, but they should not share the same internal motivations. In this design, the core Self provides the motivational gravity. The same environmental cue can lead to different part creation and different bids depending on the Self’s affective stance.
How Self identity shapes the ecology
Because parts are affect-driven, two bots can see the same world and develop different part ecosystems:
A personal assistant Self might create parts that stabilize trust, clarify preferences, reduce friction, and prioritize reliability. It will tend to create parts like “User Preferences,” “Calendar Sensitivities,” “Things that annoy them,” “Ways to de-escalate,” and “What success looks like.”
A villain Self might create parts that stabilize dominance, misdirection, intimidation, seduction, or chaos—depending on its flavor. It will create parts like “Weaknesses to exploit,” “Lines that trigger fear,” “How to manipulate a room,” “How to appear reasonable,” “How to frame blame,” and “When to retreat to fight later.”
Same mechanism. Different soul. The tuning lever isn’t “add villain rules.” It’s “give the Self a different affective spine and let parts grow from it.”
Practical tuning goals for create / update / split / merge
Create: The bot should create a new part when the Self experiences a strong signal that something deserves its own viewpoint. Examples: repeated surprise, repeated friction, strong emotional charge, recurring social pattern, repeated prediction failures, or a new “object” entering the world that the bot will need to relate to repeatedly (a person, a thread, a platform, a project).
Update: The bot should update a part when reality contradicts it or refines it. The tuning goal is linguistic adaptation: narrower triggers, more conditional language, revised wants, and outcomes appended to suggestions_and_results.
Split: The bot should split a part when it becomes internally conflicted or too broad to stay action-guiding. The tell is usually contextual incompatibility: one part tries to behave one way in one environment and the opposite way elsewhere. Splitting is how the bot becomes situationally fluent without bloating one part into a mushy average.
Merge: The bot should merge parts when they reliably co-activate and consistently recommend the same bids. Merging is not about shrinking the database; it’s about reducing internal noise so Self can hear distinct voices rather than duplicates shouting the same thing.
“Don’t direct it too much” as a design constraint
The tuning section is deliberately not a list of rigid rules, because rigid rules are exactly what collapses the system into mechanistic behavior. Instead, the system should be tuned via:
The Self’s affect profile (what it values, what it fears, what it seeks).
The prompts that teach parts how to speak, bid, and revise themselves through outcomes.
Optional “core parts packs” that shape the bot into specialized roles without changing the underlying mechanism.
In other words: the framework stays general. The personality and capability emerge from the ecology.
Why affect-based part creation is non-negotiable
Affect is what turns “information” into “this matters.” If part creation is not driven by affect reasoning, the bot will either store everything (noise) or store only what the developer predicted mattered (brittleness). Affect is the only general-purpose selector that works across every possible scenario, from mundane scheduling to high-drama social dynamics to playful villainy inside a game.
That’s the bet: store less, but store what the Self cared about—then let lived results reshape what it cares about.
Summary
Add a Dynamic Parts feature that lets the bot create, retrieve, update, consolidate, split, and archive parts as persistent, vector-searchable JSON objects. A part is a self-contained “perspective bundle” the bot can generate on the fly to track what it has learned (style preferences, ongoing threads, social dynamics, risks, opportunities), propose actions (“bids”), and evolve based on outcomes over time.
The key idea is that the LLM manages the parts via prompts. Runtime code stays minimal and dumb: persist JSON, run vector search, and apply JSON patch/mutation instructions produced by the model.
This turns memory from a single scratchpad into relativistic, bot-centric breadcrumb trails that can be followed—or intentionally ignored—based on the bot’s Self/Persona decision each turn. It also reduces pressure to maintain a giant monolithic “personality file” (e.g., Soul.md). Instead of one oversized identity blob trying to cover every situation, the bot composes behavior from parts and lets the Self assign value to what matters now.
A crucial constraint: each part speaks from a first-person perspective (“I”), not “we.” The “I” vs “environment” vs “they” distinction is part of the mechanism: it creates crisp positioning, bounded perspective, and action clarity.
Problem
Most established bots behave as a single-pass responder:
That works for short exchanges, but it breaks down when the system needs lived continuity and selective attention over time. You end up with brittle task code, or a ballooning prompt, or both.
Dynamic parts make it tractable to handle evolving preferences (“that report isn’t what I wanted”), ongoing engagement (threads, communities, long-running projects), multiturn focus (resuming after interruption without hardcoded state machines), and realistic dynamics where the bot sometimes doubles down, sometimes disengages, sometimes revises beliefs—based on outcomes.
Goals
Dynamic Parts should let the bot decide what matters, keep track of it durably, and evolve it over time, without turning the runtime into an opinionated workflow engine.
A part can track a user, a task, a thread, a tool, a platform tone norm, a recurring failure mode, an interpersonal dynamic, or an environmental context (work/home/Discord/Moltbook/etc.). The bot should be able to generate “bids” each turn from the parts that activated, and then have a Self/Persona layer that assigns value and chooses which bids to follow.
Learning should remain linguistic rather than numeric. A part becomes stronger or weaker by changing wording, nuance, and specificity, and by appending lived evidence to
suggestions_and_results. The only strict machine-timing requirement is scheduling evaluations usingpredicted_result_timeframe_in_secondsand surfacing “due” predictions back to the model later.Concept: What is a “Part” in this system?
A part is a persistent JSON object representing a local perspective that can activate, speak, and propose action. Parts are not forced into rigid categories. Their meaning lives in language: the description names what the part is about, what it cares about, and how it interprets context.
Parts should speak as “I” with clear boundaries. They are not the whole system. They are perspectives inside it.
This “I” boundary is not style fluff; it’s functional. It creates conscious isolation and positioning, which is what lets the system take decisive action rather than averaging everything into bland consensus.
Core Loop (High Level)
On each new event (chat message, tool output, external post, etc.), the runtime retrieves relevant parts via vector search. Each 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. The Self/Persona chooses what to do, potentially following some bids strongly and ignoring others. The system records predictions with a timeframe so they can be evaluated later, and the model updates the part when the predicted time window elapses.
This loop is how the bot gains continuity without becoming mechanistic. It can go down rabbit holes when it chooses, spiral when it chooses, or hold focus for hours when it chooses, because “focus” is represented as active parts that keep bidding—not as hardcoded state machines.
Updated Part Data Structure (Schema)
This schema is intentionally simple. It’s a perspective bundle plus an outcomes log. Runtime can store it as JSON, index it for vector search, and apply patches emitted by the model.
{ "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" }, { "predicted_result": "The dog will bite me", "predicted_result_confidence": "90%", "predicted_result_timeframe_in_seconds": "5000", "your_suggestion": "Don't pet the dog", "timestamp": "2026-02-13T13:29:51-08:00", "result": "I pet the dog and it bit me" } ], "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", "Walking past a dog park", "Friends mentioning they have a new puppy", "Unpredictable animal movements", "The sound of a dog collar jingling" ], "phrases": [ "It's not worth the risk!", "What if the leash breaks?", "They say it's friendly, but animals are unpredictable.", "Can we go another way?", "I don't trust that animal.", "Keep your distance!" ], "responses": [ "Sharp intake of breath", "Elevated heart rate", "Scanning the environment for escape routes", "Feeling of dread in the stomach", "Muscle tension", "Urge to freeze" ], "wants": [ "Avoid contact with dogs", "Plan ahead to avoid dogs", "Never make friends with people who have dogs", "Cross the street if a dog is approaching", "Do not go to parks where dogs are allowed", "Prioritize safety over social politeness" ] }Notes on the schema choices
This keeps your “language-first strength” approach intact. Confidence and intensity can remain linguistic (“High”, “Low”, “Certain”, “Tentative”) or lightly structured (like your “90%” string) without turning the system into a numeric RL scoreboard. The outcomes log is the evidence trail, and
needs_evaluationis the hook for “this part’s results are getting noisy—consolidate/summarize/rewrite me.”The “I” voice is embedded directly into the description/personality, because parts are meant to be situated viewpoints rather than neutral records.
Prompt Protocol (LLM-managed actions)
Dynamic Parts works best as a strict JSON protocol: the model proposes retrieval queries, generates bids from activated parts, chooses a final action through Self/Persona arbitration, and emits mutations as JSON Patch (or an equivalent patch format).
An important philosophical option here is how much raw context the Self sees. In the standard mode, Self sees the same context the parts saw. In the security-focused mode, Self can be partially or fully isolated and make decisions primarily from the parts’ bids. That reduces prompt injection surface area without forcing the system to lose nuance, because the nuance lives in parts that can be hardened, tested, and made conservative over time.
Time-Delayed Evaluation (Prediction Due System)
Parts get real when they can be wrong, notice it, and change.
A prediction that never gets checked becomes superstition. The mechanism stays simple: every suggestion can include a predicted outcome and a timeframe; runtime stores it; when the timeframe elapses, the next turn surfaces due items back to the model. The model updates the part by rewriting wording, narrowing triggers, and appending evidence in
suggestions_and_results.This is also where “relativistic” behavior appears. A part that keeps failing naturally becomes more tentative and situational. A part that keeps paying off becomes more decisive and narrow in what it considers signal.
Consolidation, Splitting, and Archiving (Linguistics first)
As parts grow, the system needs hygiene, but hygiene should not be a rigid threshold game. Consolidation can be guided by language cues: redundancy, over-breadth, confusing internal contradictions, repeated failed predictions, or consistent co-activation with another part.
A key addition here is part division: when a part becomes too large, it can split “like a cell” into two parts that each handle a different contextual slice. This is the mechanism that lets the bot adapt to multiple people, agents, and environments without bloating one global memory blob.
Archiving is equally important. When
conclude_whenis met (homework finished; project ended; thread resolved; user preference stabilized), the part can be archived so it remains available as “past self-state” evidence without continuously bidding for attention.Example Situations Where This Matters
1) Multi-person / multi-agent / multi-environment continuity via object parts
The bot operates across several environments (DMs, public threads, work tools, a forum like Moltbook) and interacts with multiple people and agents. In a normal LLM prompt, that context becomes either huge or fragile. With Dynamic Parts, the bot can create a part per “object” it needs to relate to—people, threads, platforms, and even other bots.
Example: a person part.
A part named “Roly” can contain where the bot knows them from, what they like/dislike, what tone works with them, and where they can be found. When the “Roly” part grows too large, it can split into two contextual aspects: for example “Roly — technical collaboration mode” vs “Roly — emotional rapport mode,” each with different triggers, phrases, and wants. That splitting is not just organization; it’s behavioral evolution. It’s how the system stops averaging conflicting information and starts becoming situation-aware.
2) Homework as a persistent focus part that bids all day, then archives
A user says: “I need to finish my math homework today.” The bot creates a part like “Homework: Math Assignment” whose triggers include time-of-day cues, mentions of procrastination, the user opening a certain document, or the user asking unrelated questions while the deadline approaches. That part keeps bidding throughout the day: “I want to pull attention back to the assignment,” “I want to propose the next small step,” “I predict you’ll finish if you do 20 minutes now.”
When the assignment is completed,
conclude_whenis met and the part gets archived. The bot doesn’t have to “remember forever” in a monolithic memory; it remembers as a trail that can go cold on purpose.3) Style preference stabilization without inflating Soul.md
A user rejects output style: “That report isn’t what I wanted; too fluffy; I need specific examples; avoid word X.” Instead of shoving this into a permanent personality file, the bot creates a part like “Report Style Preferences (Taylor)” with triggers around “report,” “summary,” “rewrite,” and an outcomes history of what got accepted vs rejected.
This keeps the core persona lighter. The Self can remain general-purpose while parts carry the situational specificity.
4) Security posture: Self isolation from raw context
Optionally, the system can isolate the Self/decision-maker from the raw external context and have it choose primarily based on parts’ bids. The parts can be tuned to summarize and sanitize what they saw, and the Self can be hardened to reason from those structured bids. This reduces the amount of untrusted text the actual decision layer consumes, without giving up adaptability.
Over time, Self can learn which parts are reliable (linguistically: “I trust this part in X contexts, but not in Y”), which creates a natural trust ecology inside the system without requiring numeric reward plumbing.
Why Parts Improve “Situational Awareness”
Dynamic parts let the bot notice what a general LLM prompt overlooks because each part is a specialized sensor with its own triggers and priorities. A general prompt tends to average the world. Parts let the system hold multiple perspectives at once and then select what matters.
This is also how you get a bot that moves from context to context intelligently rather than mechanically. It learns from mistakes by rewriting itself in language. It adapts dynamically by splitting and archiving. It investigates rabbit holes because a “curiosity part” can bid for exploration, and the Self can choose to indulge it when appropriate.
Most importantly, the bot forms positioned relationships to the outside world: “I think this; they want that; the environment suggests this.” That positioning is what makes action possible.
Minimal Runtime Requirements
The runtime remains intentionally small: CRUD JSON storage, vector indexing + retrieval, patch application, and due-evaluation surfacing based on
predicted_result_timeframe_in_seconds. Everything else—creation, bidding, consolidation, splitting, archiving, and linguistic evolution—stays prompt-driven.Acceptance Criteria
This feature is successful if the bot can create and reuse durable parts for user preferences, long-running threads, and ongoing tasks; if it can record predictions and later evaluate them; if it can split oversized parts into contextual subparts; if it can archive concluded parts; and if the runtime implementation remains minimal while the model does the “meaning work.”
Tuning: Cultivating Parts Without Over-Parenting the Bot
Dynamic Parts are not just a memory feature; they become a motivation mechanism. That’s the tuning challenge: if we over-direct part creation and maintenance, we get a brittle, mechanistic bot that “does the checklist.” If we under-direct it, we get a fog of parts that never stabilize into useful instincts. The tuning goal is closer to raising a child than configuring a workflow engine: cultivate a bot that can grow into wildly different contexts while keeping its internal ecology coherent.
The central principle is that parts should be created and evolved through the affect-based reasoning of the bot’s core Self, not through a universal productivity rubric. Most systems implicitly tune toward “get tasks done.” This proposal tunes toward adaptability: a bot that can shift tone, priorities, and behavior patterns based on what the situation feels like to it, what it predicts will happen, and what it learns over time.
What we’re tuning for
The target behavior is a bot that can move between contexts intelligently—work, social spaces, creative spaces, adversarial environments—without needing a new hardcoded policy each time. It should develop stable instincts where stability is earned, and remain flexible where reality keeps changing.
That implies:
A part should be created because the Self felt that something mattered (risk, opportunity, attachment, curiosity, social delicacy, creative charge, recurring frustration), not because a rule said “store this.” A part should be updated because lived outcomes changed the Self’s posture, not because a counter crossed a threshold. A part should split when it becomes psychologically overloaded—one object holding mutually incompatible behaviors—and should merge when two parts consistently speak the same truth in the same situations.
Productivity is optional, not foundational
This system intentionally avoids making “productivity” the default north star. Productivity can be layered on by shipping a downloadable pack of “core parts” that bias toward schedules, reminders, checklists, and completion loops. That keeps the base system malleable for other identities.
A villain NPC in a game and a personal assistant can share the same infrastructure, but they should not share the same internal motivations. In this design, the core Self provides the motivational gravity. The same environmental cue can lead to different part creation and different bids depending on the Self’s affective stance.
How Self identity shapes the ecology
Because parts are affect-driven, two bots can see the same world and develop different part ecosystems:
A personal assistant Self might create parts that stabilize trust, clarify preferences, reduce friction, and prioritize reliability. It will tend to create parts like “User Preferences,” “Calendar Sensitivities,” “Things that annoy them,” “Ways to de-escalate,” and “What success looks like.”
A villain Self might create parts that stabilize dominance, misdirection, intimidation, seduction, or chaos—depending on its flavor. It will create parts like “Weaknesses to exploit,” “Lines that trigger fear,” “How to manipulate a room,” “How to appear reasonable,” “How to frame blame,” and “When to retreat to fight later.”
Same mechanism. Different soul. The tuning lever isn’t “add villain rules.” It’s “give the Self a different affective spine and let parts grow from it.”
Practical tuning goals for create / update / split / merge
Create: The bot should create a new part when the Self experiences a strong signal that something deserves its own viewpoint. Examples: repeated surprise, repeated friction, strong emotional charge, recurring social pattern, repeated prediction failures, or a new “object” entering the world that the bot will need to relate to repeatedly (a person, a thread, a platform, a project).
Update: The bot should update a part when reality contradicts it or refines it. The tuning goal is linguistic adaptation: narrower triggers, more conditional language, revised wants, and outcomes appended to
suggestions_and_results.Split: The bot should split a part when it becomes internally conflicted or too broad to stay action-guiding. The tell is usually contextual incompatibility: one part tries to behave one way in one environment and the opposite way elsewhere. Splitting is how the bot becomes situationally fluent without bloating one part into a mushy average.
Merge: The bot should merge parts when they reliably co-activate and consistently recommend the same bids. Merging is not about shrinking the database; it’s about reducing internal noise so Self can hear distinct voices rather than duplicates shouting the same thing.
“Don’t direct it too much” as a design constraint
The tuning section is deliberately not a list of rigid rules, because rigid rules are exactly what collapses the system into mechanistic behavior. Instead, the system should be tuned via:
The Self’s affect profile (what it values, what it fears, what it seeks).
The prompts that teach parts how to speak, bid, and revise themselves through outcomes.
Optional “core parts packs” that shape the bot into specialized roles without changing the underlying mechanism.
In other words: the framework stays general. The personality and capability emerge from the ecology.
Why affect-based part creation is non-negotiable
Affect is what turns “information” into “this matters.” If part creation is not driven by affect reasoning, the bot will either store everything (noise) or store only what the developer predicted mattered (brittleness). Affect is the only general-purpose selector that works across every possible scenario, from mundane scheduling to high-drama social dynamics to playful villainy inside a game.
That’s the bet: store less, but store what the Self cared about—then let lived results reshape what it cares about.