Memory And Knowledge

KsADK includes memory and knowledge integration points for agent applications. The public documentation treats these as optional capabilities layered on top of the local runtime.

Capability Model

Memory and knowledge are related, but they solve different problems:

Runtime Boundary

KsADK separates memory and knowledge into three layers:

1. framework tools, where the agent explicitly calls load_memory, save_memory, or a knowledge search tool.
2. ambient context, where the runtime retrieves short formatted context before calling the runner.
3. backend services, where application-specific storage or retrieval happens.

What To Use Locally

For open-source examples, prefer storage that a developer can run without a private account:

• in-memory state for quick tests.
• local files for deterministic examples.
• SQLite for small persistent demos.
• a local Redis instance only when the guide explicitly needs Redis behavior.

Long-Term Memory

Long-term memory is accessed through a small backend contract:

The runtime service chooses a backend from environment configuration, formats results into prompt text, and exposes framework tools such as load_memory and save_memory. If no long-term memory backend is configured, the public runtime should continue to work normally.

Example local shape:

def save_preference(memory_store: dict[str, list[str]], user_id: str, value: str) -> None:
    memory_store.setdefault(user_id, []).append(value)


def search_preferences(memory_store: dict[str, list[str]], user_id: str, query: str) -> list[str]:
    return [item for item in memory_store.get(user_id, []) if query.lower() in item.lower()]

Knowledge Retrieval

Knowledge retrieval is for external facts, manuals, or product data. The public SDK should not assume a private hosted dataset. A public example can use a small local file corpus:

DOCUMENTS = [
    {"title": "refund-policy.md", "text": "Refunds are reviewed within 5 business days."},
    {"title": "shipping.md", "text": "Standard shipping takes 3 to 7 business days."},
]


def search_documents(query: str, top_k: int = 3) -> list[dict[str, str]]:
    query_lower = query.lower()
    matches = [doc for doc in DOCUMENTS if query_lower in doc["text"].lower()]
    return matches[:top_k]

ADK Versus Other Frameworks

ADK projects can receive memory and knowledge through ADK-compatible tools and, when configured, an ADK memory service. LangGraph, LangChain, and DeepAgents projects should usually receive context through the runner payload or explicit hook functions.

Runtime Context Flow

When configured, KsADK can build memory and knowledge context before calling the framework runner:

Framework Integration

Memory and knowledge features should be exposed through normal framework hooks:

• ADK tools or callbacks.
• LangChain tools.
• LangGraph state and checkpointers.
• DeepAgents model/tool configuration.

LangGraph

For LangGraph projects with custom state, expose a top-level ksadk_prepare_state(payload, session_context) function. Use the payload for the current input and the session context for runtime-provided context:

def ksadk_prepare_state(payload: dict, session_context: dict) -> dict:
    return {
        "messages": payload.get("input_messages", []),
        "question": payload.get("input", ""),
        "knowledge": session_context.get("kb_context"),
        "memory": session_context.get("memory_context"),
    }

LangChain

For LangChain projects, expose ksadk_prepare_input(payload, session_context) when the application needs direct access to memory or knowledge context:

def ksadk_prepare_input(payload: dict, session_context: dict) -> str:
    sections = []
    if session_context.get("kb_context"):
        sections.append("Knowledge context:\n" + session_context["kb_context"]["formatted_text"])
    if session_context.get("memory_context"):
        sections.append("Memory context:\n" + session_context["memory_context"]["formatted_text"])
    sections.append("User request:\n" + payload.get("input", ""))
    return "\n\n".join(sections)

ADK

Environment Variables

Use placeholders in public docs. The exact backend configuration may vary by deployment, but these names define the public-facing configuration family:

OpenClaw Memory Backend (Optional)

The OpenClaw runtime declares a memory backend through MEMORY_BACKEND_MANIFEST. The backend_type can be one of:

Notes:

• lancedb maps to an in-process LanceDB memory plugin (plugin id memory-lancedb) and is not exposed through the agentengine openclaw deploy --memory-system CLI; that CLI choice is limited to openclaw_default / mem0.
• When mem0 is selected, MEM0_API_KEY / MEM0_USER_ID / MEM0_BASE_URL are required (injected by the hosted platform).
• Rendering the memory-lancedb output disables openclaw-mem0 to avoid loading both backends at once.
• The manifest config can optionally override dbPath, embedding, and storageOptions.

backend_type: lancedb
config:
  dbPath: /data/agent-memory/lance
  embedding:
    provider: openai
    model: text-embedding-3-small
  storageOptions:
    topK: 5

For the full variable list, see ksadk environment variables reference.

Failure Behavior

Hosted Integrations

Hosted memory, knowledge base, and Skill Service integrations can be documented as optional capabilities after their public credential model is approved.

Recommended Public Example Pattern

When adding a memory or knowledge example to the public repository:

Example Data Rule