Needing a capability does not grant ownership
A memory app needs questions and revision proposals, so adding a provider client, prompt store, and conversation table seems natural. That quietly creates a second Pippa backend.
The family already has a canonical owner for identity, brain registry, conversation history, fallback, and Sidekick. Vestige should send target soul, context shape, and instruction through that plumbing, then receive results through its mediated writer.
A second brain splits history
Separate Vestige and Pippa conversations force one soul's decisions into two places. Model settings and safety rules drift, and identity changes in one surface fail to reach the other.
Reuse is not merely fewer API calls. It keeps identity continuity and provenance together. A client may look independent while brain state returns to its owner.
The boundary simplifies failure
If the brain owner is unavailable, Vestige can still serve Browser, Trail, Weight, search, and direct edit while consultation fails. If Vestige is unavailable, a living brain cannot bypass its memory writer.
Each outage removes only its responsibility. An owned brain or direct brain-to-vault write lets failure spread across boundaries.
Version the contract
Unstructured prompts hide coupling. Use typed host kind, curator identity, conversation binding, allowed actions, and result schema with a deployment order.
A consumer adopts the new contract after the owner deploys and treats unknown fields explicitly. Sharing plumbing does not remove versioning responsibility.