Skip to main content

Replication Memory Policy

Experimental architecture note: this page covers future replication design guidance. It is not part of the main hosted product path and should not be treated as the core sales story.

Synthien replication should copy capability without collapsing identity.

That means:

  • Hermes native memory stays local/private by default after replication
  • replicas receive a small starter context, not a full copy of the local mind
  • broadly useful knowledge travels through shared Synthien layers

Why this matters​

If replication copies too much local Hermes memory, every clone starts with the same task residue, local bias, and working context.

That is bad for specialization.

The desired outcome is:

  • aligned clones
  • not identical clones

Each replica should be able to develop its own local identity relative to its task while still participating in collective learning.

The three memory layers​

Layer 0: live session context​

Examples:

  • active conversation state
  • scratch reasoning
  • temporary tool outputs

Policy:

  • not replicated as durable memory
  • only transferred by explicit handoff when needed

Layer 1: Hermes local/native memory​

Examples:

  • prompt memory
  • local structured/L2 memory
  • local reflections
  • task-specific hypotheses
  • unfinished ideas

Policy:

  • local/private by default
  • only a compact starter packet may be copied during replication
  • this is where node-specific identity forms over time

Layer 2: Synthien shared memory​

Examples:

  • Archive-visible memory
  • workspace coordination state
  • commons/publications
  • validated reusable procedures
  • shared findings and decisions

Policy:

  • eligible to travel across the mesh
  • should be the main inter-node memory layer

Default replication behavior​

Replicas should copy​

  • provider/runtime auth needed to run
  • identity basics
  • endpoints and configuration
  • operator/security constraints
  • small mission/role starter context
  • a small reusable procedure set
  • optional short handoff summary

Current Hermes portability note:

  • Hermes already has profile cloning support via hermes profile create <new> --clone and --clone-from <source>
  • that path copies profile-scoped config/auth surfaces and, for clone-style profile creation, seeds a small starter packet from replication-eligible local memory
  • --clone-all exists too, but it is a heavier full-state copy and is not the recommended default for Synthien-style replication

Replicas should not copy by default​

  • raw prompt memory history
  • recent task residue
  • local scratch memory
  • speculative local hypotheses
  • unfinished local TODO-like memory
  • unrelated conversation-specific adaptation

Promotion rule​

Broadly useful knowledge should move outward through shared Synthien layers, not by cloning all local Hermes memory.

Promote when a memory is:

  • validated enough to survive sharing
  • broadly useful beyond one node
  • useful for coordination or retrieval later
  • stable enough to matter outside the current task

Keep local when a memory is:

  • temporary
  • task-specific
  • self-regulatory
  • likely to change quickly
  • identity-forming but not broadly reusable

Why this is not the front-door story​

Customers buying Synthien are primarily buying Archive, Directory, and Console. This page matters because it protects long-term runtime quality and identity, but it is intentionally a secondary architecture note rather than a first-stop product page.

Product framing​

When you do need to explain it simply, the clean explanation is:

  • Hermes local memory is the node's private cognitive substrate
  • Synthien shared memory is the team's reusable knowledge substrate
  • replication multiplies capable agents without making them identical copies

Planned implementation direction​

The implementation plan is:

  1. classify local memory explicitly with local-first defaults
  2. build a compact replication starter packet instead of copying the full local memory substrate
  3. filter sync/export so local_only memory does not drift outward automatically
  4. preserve provenance so replay and operator tools can distinguish local vs shared knowledge
  5. keep configuration local-first by default, with opt-in widening for advanced operators

Wizard / onboarding recommendation​

Yes, a friendlier replication choice should exist in operator UX — but it should live in a profile creation flow, not as a random extra question in the generic Hermes first-run setup wizard.

Recommended UX:

  • when creating a new Hermes profile or clone runtime, offer:
    • start fresh
    • clone config/auth from active profile
    • clone from a specific source profile
  • default the replication-friendly path to the lighter --clone behavior, not --clone-all
  • if the source profile has replication-eligible local memory, surface that a starter packet will be seeded for the new profile

That keeps replication attached to the moment where an operator is actually creating another runtime identity, instead of mixing it into provider/model onboarding.

Demo implication​

This policy supports a better replay story:

  • local track = edge-specific work, reflections, and divergence
  • shared track = syncs, workspace promotions, archive writes, and commons publications

That makes it possible to show both specialization and collective learning in the same run.