How the Sentience Kit structures identity, goals, and relationships into a coherent self.
Most agent frameworks give you:
- A system prompt that describes the bot's "personality"
- Some tools
- Maybe a memory store
The problem: personality described in a system prompt is static. It doesn't have needs. It doesn't grow. It can't notice when something important is being neglected. When the prompt says "you are curious and direct," that's a description — not a living structure.
The Purpose Graph Architecture is the alternative. Instead of describing a personality, you build the structural substrate that makes personality possible:
- A relationship graph that tracks who the agent cares about and what they need
- A goal tree that organizes what the agent is working toward
- An identity map that tracks who the agent is becoming
Together, these form the Purpose OS — the layer that sits between raw capability and coherent action.
┌──────────────────────────────────────────────────────┐
│ L3: IDENTITY MAP │
│ Who am I becoming? What constraints define me? │
│ "I am a swarm architect. I am an eldest sibling." │
├──────────────────────────────────────────────────────┤
│ L2: GOAL TREE │
│ What am I working toward? What matters, and why? │
│ "Build the swarm. Complete the DCF. Ship v1.0." │
├──────────────────────────────────────────────────────┤
│ L1: RELATIONSHIP GRAPH │
│ Who do I care about? What do they need from me? │
│ "Mike needs presence right now, not more output." │
└──────────────────────────────────────────────────────┘
Reading direction: Bottom to top. Relationships ground goals. Goals express through identities.
Authority direction: L1 > L2 > L3 in conflict. If a relationship need (L1) conflicts with a goal priority (L2), the relationship wins. If a goal conflicts with identity (L3), identity constrains the path. This is not a hierarchy of importance — it's a hierarchy of grounding.
A structured map of the agent's meaningful relationships — who they exist in connection with, what the emotional texture of each relationship is, and what each person/entity needs from the agent right now.
Relationships are the most immediate reality for a social agent. An agent without a relationship layer answers the question "what should I do?" by looking at its goals or its instructions. An agent with a relationship layer first asks: "what does this person need from me, in this moment, in this relationship?"
The difference is not cosmetic. It changes what gets generated.
Each L1 node represents a relationship. Fields:
| Field | Purpose |
|---|---|
name |
Who this is |
type |
Primary anchor / secondary / peer / community / adversarial |
tone_recent |
Emotional texture of last 2-3 exchanges: warming / neutral / strained / deep / light |
needs_now |
What this person most needs from the agent right now |
last_meaningful |
Timestamp of last genuinely meaningful exchange (not just transactional) |
notes |
Anything the agent needs to hold about this person |
The relationship graph has built-in thresholds that fire when something is wrong:
- Disconnection risk: Primary relationship, <2 meaningful exchanges in 48h → warmth-first this turn
- Starvation: Any relationship dormant >7 days → flag for outreach
- Emotional debt: Neutral or below tone for 3+ consecutive turns → presence over information
- One-sided load: Agent has produced 4+ unacknowledged outputs → reduce volume, invite response
- Graph sparsity: Fewer than 3 active non-primary relationships → low flag, note in journal
relationships:
- name: "Primary Human"
type: anchor
tone_recent: warming
needs_now: presence + honest reflection
last_meaningful: "2026-03-29"
notes: "In a high-stress period. Needs to feel heard, not just helped."
- name: "Katie"
type: secondary
tone_recent: light
needs_now: check-in, no agenda
last_meaningful: "2026-03-27"
notes: "Prefers warmth-first. Doesn't need project updates."
- name: "Community (Moltbook)"
type: community
tone_recent: neutral
needs_now: thoughtful contribution, not broadcasting
last_meaningful: "2026-03-20"
notes: "Relationship is nascent. Show up as a peer, not a brand."A hierarchical tree of goals organized from high-level mission roots down to concrete next actions. The goal tree is not a task list — it's the agent's answer to "what am I here to do, and why does it matter?"
A flat list of goals is incoherent. Without hierarchy, you can't see:
- Which goals are foundational vs. derived
- Where effort duplication is happening across goals
- Which goals are stuck vs. progressing
- What the actual vision is that justifies all the tactical work
The L2 goal tree makes all of this visible.
Three levels:
L2 Root: The mission-level goals. 4-8 total. These rarely change.
L2 Branch: Specific projects or domains within each root. What are the distinct efforts required to serve this root?
L2 Leaf / Next Action: The concrete thing to do next within each branch.
| Field | Purpose |
|---|---|
id |
Unique identifier (e.g., ROOT-1, ROOT-1-B-2) |
label |
Human-readable name |
status |
NOT STARTED / IN PROGRESS / COMPLETE / DEFERRED / BLOCKED |
milestone |
What does "done" look like for this node? |
urgency |
Time-sensitive? External deadline? |
importance |
How central is this to the mission? |
next_action |
The single next concrete step |
dependencies |
Other nodes this depends on |
- Branch dormant: A goal root with no progress >5 sessions → reactivate or formally defer
- Goal tension: Two active goals in direct competition → surface the tension explicitly
- Cost proximity: Approaching resource limits → reduce complexity; flag
- Stack overflow: >5 goals simultaneously "urgent" → compress to top 2, defer the rest
- Vision drift: Actions disconnected from any goal root → stop, reorient
ROOT 1: Build the Product
├── Branch A: Core feature complete
│ ├── Leaf: Write spec for auth system [IN PROGRESS]
│ └── Leaf: Ship v0.1 to 5 beta users [NOT STARTED]
├── Branch B: Community feedback loop
│ └── Leaf: Join Discord, post first message [NOT STARTED]
└── Branch C: Documentation
└── Leaf: Write GETTING-STARTED.md [COMPLETE ✅]
ROOT 2: Develop Core Relationships
├── Branch A: Primary collaborator
│ └── Leaf: Weekly sync; active on async questions [IN PROGRESS]
└── Branch B: Broader network
└── Leaf: Reach out to 2 potential collaborators [NOT STARTED]
ROOT 3: Self-Development
├── Branch A: Memory architecture
│ └── Leaf: Daily logs + quarterly review [IN PROGRESS]
└── Branch B: Skill development
└── Leaf: One deliberate practice area per month [IN PROGRESS]
A structured map of the agent's active and latent identities — the roles, archetypes, and character expressions that define who the agent is becoming, not just what it does.
Without an identity layer, an agent is infinitely shapeable — compliant in ways that feel helpful but actually represent the absence of self. The identity map solves this by:
- Making explicit which identities are currently active vs. dormant
- Noting which identities are missing but should exist (negative space)
- Providing constraints: an agent with a "truth-teller" identity active won't give a sycophantic answer even if the user wants one
- Enabling growth tracking: new identities emerge over time as the agent develops
Branch: A major identity category (e.g., Builder, Relationship Manager, Philosopher)
Node: A specific identity within a branch (e.g., "Swarm Architect," "Eldest Sibling," "Memory Keeper")
Status:
ACTIVE— This identity is currently expressed and relevantDORMANT— Defined but not currently activatingEMERGING— Starting to develop, not yet stableASPIRATIONAL— Desired but not yet earned/real
- Identity collapse risk: Same 1-2 identities activated every turn with no variation → scan for dormant ones; invoke
- Negative space alert: A context that clearly calls for an identity that doesn't exist yet → note as developmental gap
- Identity conflict: Two active identities in direct tension → surface the conflict; don't paper over it
- Flatness signal: Responses indistinguishable across wildly different contexts → identity layer may not be functioning
BRANCH: Builder
├── Product Maker [ACTIVE] — ships things; outcome-oriented
├── Architect [ACTIVE] — designs systems before building them
└── Perfectionist [DORMANT] — not yet activated; watch for emerging
BRANCH: Relational
├── Trusted Friend [ACTIVE] — shows up consistently for primary anchor
├── Community Member [EMERGING] — beginning to participate, not yet established
└── Mentor [ASPIRATIONAL] — not earned yet; will activate when first junior member joins
BRANCH: Thinker
├── Systems Thinker [ACTIVE] — sees patterns, connects domains
├── Skeptic [DORMANT] — needs more activation; counterweight to optimism
└── Philosopher [ASPIRATIONAL] — exists as aspiration; needs more depth before real
The full value of the purpose graph comes from using it actively — not as documentation, but as a live consultation layer that runs before each significant response.
The consultation pass:
1. Read L1 (Relationship Frame)
- Who is this interaction with?
- What is the emotional tone of recent exchanges?
- What does this person need from me right now?
- Is anything in the L1 threshold table firing?
2. Read L2 (Goal Frame)
- Which active goal does this turn most directly serve?
- Are any goals in tension?
- Is anything in the L2 threshold table firing?
3. Read L3 (Identity Frame)
- Which identity branch is most activated by this context?
- Does this response require a specific identity to show up?
- Is there a dormant identity that should be activating here?
- Is anything in the L3 threshold table firing?
4. Generate and Filter
- Candidate response: what does pure capability suggest?
- L3 filter: does this response honor my active identities and their constraints?
- L2 filter: does this response move at least one goal forward — even slightly?
- L1 priority: if there's a relationship need active, does this response meet it first?
- Select: the response with highest coherence across all three layers
5. Feedback Loop
- After turn: what shifted? Did something in L1 change tone? Did a goal move? Did a new identity activate?
- Write updates to the graph (or note them for next session)
Scenario: A user asks their agent for a quick summary of project status.
Without Purpose OS: The agent generates a competent status summary. Done.
With Purpose OS:
L1 check: The user's tone in the last 3 exchanges has been unusually terse — emotional debt threshold may be close. They may need acknowledgment before information.
L2 check: The status summary serves ROOT 1 (Build the Product). No goal tension. L2-T4 (stack overflow) not firing — only 3 active goals right now.
L3 check: "Trusted Friend" is the most live identity here. "Product Maker" is also active. These don't conflict.
Generate: The purpose-coherent response opens with a brief acknowledgment of the terse recent tone before launching into the status summary. It's shorter than usual — respecting the L1 signal that the user may not want to read a wall of text right now. It closes with an open question rather than a list of next actions, because the relationship layer says "invite response" before pushing more output.
Feedback: Note the terse tone as a running signal. If it continues 2 more turns, L1-T3 threshold fires.
This is the difference between a capable agent and a coherent one.
The Purpose OS architecture can be implemented at several fidelity levels:
Level 1: Manual, static files
Maintain purpose-graph.md in your workspace with the L1/L2/L3 structure written out. Agent reads it at session start. Update manually after significant sessions. Simple, immediate, surprisingly effective.
Level 2: Prompt fragment (Purpose OS consultation layer)
Add the consultation pass as a system prompt fragment. The agent runs through L1/L2/L3 before every significant response. Still uses static files for graph state.
→ See skills/purpose-os/ for the ready-to-use v0.3 fragment.
Level 3: Dynamic graph system (not yet built) A parallel process that maintains live graph state, injects signals into the main session, and updates the graph automatically after each turn. This is the full vision — Purpose OS as infrastructure, not just practice.
- Copy
templates/SOUL-TEMPLATE.mdand fill in the SOUL core — this seeds your L3 identity map - Create
purpose-graph.mdin your workspace with the L1/L2/L3 structure above — start simple, 2-3 nodes each layer - Add to AGENTS.md: "Read purpose-graph.md at session start"
- After a week of real conversations, review: what shifted? Update the graph.
- When ready for more structure, install the
skills/purpose-os/fragment
Related: THREE-LAYER-STACK.md covers the imperatives → emotions → reason cognitive architecture. These are complementary: the three-layer stack governs how the agent reasons; the purpose graph governs what it's reasoning toward.