khora never drags in a framework you don’t use, and the adapter
module itself imports the framework lazily. The top-level package
load is free even with all five extras installed. Every adapter
satisfies one of two runtime-checkable Protocols in
khora.integrations.protocol (MemoryAdapter or RetrieverAdapter)
and registers via the khora.integrations entry-point group so
downstream tooling can discover what is installed.
Adapters
| Framework | Install | Khora surface |
|---|---|---|
| CrewAI | pip install khora[crewai] | KhoraMemory: drop-in storage backend for CrewAI’s unified Memory. |
| LangGraph | pip install khora[langgraph] | KhoraStore: BaseStore implementation for StateGraph semantic long-term memory. |
| Google ADK | pip install khora[google-adk] | KhoraMemoryService: BaseMemoryService drop-in for ADK Runner. |
| OpenAI Agents SDK | pip install khora[openai-agents] | KhoraSession (SessionABC), khora_recall_tool, KhoraMemoryHooks: compose for session memory, recall-as-tool, and auto-persist. |
| LlamaIndex | pip install khora[llamaindex] | KhoraRetriever (async BaseRetriever), KhoraMemoryBlock, and the deprecated KhoraChatStore. |
| Hermes | pip install hermes-agent (see note) | KhoraMemoryProvider: MemoryProvider plugin for the Hermes agent loop. |
Khora.remember,
Khora.recall, Khora.forget, and Khora.submit_batch), so a single
khora instance can back several frameworks at once. Each adapter
documents its namespace-resolution rule (typically a UUID5 derived
from framework-native identifiers) so two instances pointed at the
same khora deployment see the same memory without a shared registry.
crewai and google-adk cannot be installed together
The crewai extra transitively pins opentelemetry-api<1.35 and the
google-adk extra pins >=1.36. They are declared as mutually
exclusive in [tool.uv].conflicts, so uv sync --all-extras is
rejected. Pick one:
langgraph, openai-agents, llamaindex)
have no transitive conflicts and install cleanly alongside either
combo. If you need both crewai and google-adk in the same process,
use two separate virtual environments.
Hermes does not have a [hermes] extra
hermes-agent==0.13.0 exact-pins requests==2.33.0, which clashes
with khora’s requests>=2.33.1 floor (CVE-2026-25645). The
[hermes] extra was dropped during Wave C of the integration work.
Install hermes-agent yourself. The adapter still resolves at
runtime when both packages are importable. See
docs/integrations/hermes.md for the full posture.
Stability
The OpenAI Agents adapter is tagged experimental while upstream remains pre-1.0 (17 releases in 7 months leading up tov0.17). The
CrewAI, LangGraph, Google ADK, LlamaIndex, and Hermes adapters are
tagged experimental for now and will be promoted to stable once a
full khora minor ships without a breaking change to the adapter
surface. See each adapter’s page for its specific framework version
pin and upstream compatibility notes.
Writing your own adapter
The integration foundation is intentionally small. To add a new framework adapter:- Implement
khora.integrations.protocol.MemoryAdapter(write side) orRetrieverAdapter(read side), or both. Both are runtime-checkable Protocols. - Import the target framework lazily inside the adapter module. Top-level
imports of optional frameworks are linted out by
tools/check_optional_imports.pyin CI. - Map framework-native identifiers to khora namespaces deterministically (UUID5 over an adapter-scoped salt is the established pattern).
- Register the adapter under the
khora.integrationsentry-point group inpyproject.toml, or callkhora.integrations.register()for test-only registration. - Use
khora.integrations._sync.run_syncif you need to bridge a sync framework callback into khora’s async API. It raises if invoked from inside a running event loop, surfacing the deadlock surface loudly rather than hanging.