persona-garden-patch

• is_a::Inquiry Form
• has_status::Seed Stage
• in_domain::Agentic Architecture
• in_precinct::Garden Precinct

How Should Persona Node Changes Sync to Agent Configuration Files

Research Question

Given the decision that persona nodes are the design authority and agent configuration files are downstream renditions: what is the sync mechanism? When a persona node’s behavioral scope, blind spots, or operational architecture changes, how does that change reach the Claude Code agent file, a future SOUL.md, or an AGENTS.md entry?

Why This Matters

Today the sync is manual — a human or agent edits the persona node, then separately edits the agent file. This works for eight personas on one platform. It breaks when:

• Scale increases — 20+ personas across multiple projects
• Platforms multiply — the same persona renders to Claude Code, OpenAI, Ollama, SoulSpec
• Drift accumulates silently — the persona node says one thing, the agent file says another, and no one notices until behavior surprises

The portability inquiry asks whether personas should be portable across frameworks. This inquiry asks the prior question: how do changes flow from source to rendition within any framework?

Open Sub-Questions

1. Automated rendition generation: Should a skill or script generate agent files from persona nodes? What would the template look like? How much of a persona node maps mechanically to an agent file versus requiring human judgment?

2. Drift detection: How would the system detect when an agent file has diverged from its persona node? Hash comparison? Predicate-based consistency checks? A last_synced:: predicate on the agent file?

3. Reverse flow: When operational experience reveals that an agent file needs a behavioral change, should the change go directly to the agent file (fast, but creates drift) or always through the persona node first (slower, but maintains authority)?

4. Rendition scope: What belongs in the persona node versus the agent file? The persona carries design rationale and blind spots — but should it also carry platform-specific rendering hints (renders_as::claude-code, renders_as::soulspec)?

5. Compound persona structure: Victoria Gracia’s compound personas (system prompt + cultural context documents) suggest that deep personas need more than a single file. How does the compound node pattern (lead file + Renditions/) map to multi-platform persona delivery?

Current Status

Blocked: Cannot fully explore until the architecture moves beyond Claude Code. The single-platform case (persona node → one Claude Code agent file) is simple enough that manual sync works. The interesting questions emerge with multiple target platforms, which requires at least one additional framework integration to test against.

Sources

• Persona Nodes as Design Authority for Agent Configuration — the decision this inquiry investigates the implementation of
• Dialogue between Christopher Allen and Peter Kaminski (March 2026) on compound personas and reflection personas
• Victoria Gracia’s compound persona work — empirical validation of deep persona structure

Relations

• motivated_by::Persona Nodes as Design Authority for Agent Configuration
  • This inquiry asks how to implement the decision’s downstream-rendition model.
• relates_to::Does the Garden Persona Architecture Need a Portability Layer
  • The portability inquiry asks whether to support multiple frameworks; this inquiry asks how changes flow to renditions regardless of framework count.
• relates_to::Persona Drift Causes Detection and Prevention
  • Drift between persona node and agent file is a form of persona drift — but at the design level, not the runtime level.

This site is open source. Improve this page.