Research: Hydration Source Provider abstraction

Research spike: investigate whether a "Source Provider" abstraction is valuable for hydration.

Context

The current HydrationConfig has hardcoded source types (temporal, semantic, knowledge) backed by Memory.db. As we extend memory to all agents, we may want agents to pull context from multiple backends:

• Memory.db (personal knowledge)
• Codebase search (semantic code)
• RAG over docs (company wiki)
• Shared agent memories

Questions to Answer

1. Is the provider abstraction worth the complexity? 2. What's the right granularity? Per-source-type or unified? 3. How do providers declare their capabilities? 4. How does identity/auth work across providers? 5. Are there existing patterns (LangChain, LlamaIndex) worth borrowing?

Proposed Design to Evaluate

data SourceProvider = SourceProvider
  { spName :: Text
  , spBuildTemporal :: Maybe (ProviderConfig -> ContextSource TemporalResult)
  , spBuildSemantic :: Maybe (ProviderConfig -> ContextSource SemanticResult)
  , spBuildKnowledge :: Maybe (ProviderConfig -> ContextSource KnowledgeResult)
  }

data ProviderConfig = ProviderConfig
  { pcIdentity :: Map Text Text
  , pcOptions :: Map Text Value
  }

Success Criteria

• Clear recommendation: implement provider abstraction or keep it simple
• If yes, concrete design doc with types and migration path
• If no, document why and what simpler approach suffices