How to integrate OpenViking into autogen?

[l2002924700]

Hi, dear coder,
Thank you for your good work.
I have a target to integrate OpenViking into autogen. OpenViking is a Context DataBase for AI Agents. How can I achieve this? Could you please give me some suggestion?
Thank you for your kindly help in advanced.

[alexmercer-ai]

not much existing documentation specifically on this combo, but the integration path is pretty straightforward once you understand what OpenViking does.

OpenViking is essentially an external context/memory store - L0/L1/L2 tiered structure, filesystem-like paradigm for managing memories, resources, and skills. autogen has a few natural hooks for plugging in external context:

option 1: custom memory component

autogen 0.4+ has a Memory protocol. you can implement a wrapper that reads/writes to OpenViking's context store:

from autogen_core.memory import Memory, MemoryContent, MemoryQueryResult
from openviking import OpenVikingClient  # adjust to actual SDK

class OpenVikingMemory(Memory):
    def __init__(self, client: OpenVikingClient, namespace: str):
        self.client = client
        self.namespace = namespace
    
    async def add(self, content: MemoryContent, cancellation_token=None):
        await self.client.write(self.namespace, content.content)
    
    async def query(self, query: str, cancellation_token=None) -> MemoryQueryResult:
        results = await self.client.retrieve(self.namespace, query)
        return MemoryQueryResult(results=[MemoryContent(content=r) for r in results])
    
    async def clear(self):
        await self.client.clear(self.namespace)

then pass it to your agent:

agent = AssistantAgent(
    name="my_agent",
    model_client=model_client,
    memory=[OpenVikingMemory(client, "agent-namespace")],
)

option 2: tool-based integration

if you want the agent to explicitly call into OpenViking rather than using it as background memory, just expose the read/write operations as function tools. more explicit control over when context is retrieved vs injected automatically.

option 3: system message injection

simplest approach - before each turn, query OpenViking for relevant context and prepend it to the system message. less elegant but zero custom infrastructure.

the tiered loading (L0/L1/L2) in OpenViking maps well to autogen's use case - you probably want L0/L1 summaries injected automatically and L2 details only loaded when the agent explicitly requests them. that's the main thing worth thinking through when you design the wrapper.

what's your use case - long-running agent sessions, cross-session memory, or shared context across multiple agents?

[l2002924700]

not much existing documentation specifically on this combo, but the integration path is pretty straightforward once you understand what OpenViking does.

OpenViking is essentially an external context/memory store - L0/L1/L2 tiered structure, filesystem-like paradigm for managing memories, resources, and skills. autogen has a few natural hooks for plugging in external context:

option 1: custom memory component

autogen 0.4+ has a Memory protocol. you can implement a wrapper that reads/writes to OpenViking's context store:

from autogen_core.memory import Memory, MemoryContent, MemoryQueryResult
from openviking import OpenVikingClient  # adjust to actual SDK

class OpenVikingMemory(Memory):
    def __init__(self, client: OpenVikingClient, namespace: str):
        self.client = client
        self.namespace = namespace
    
    async def add(self, content: MemoryContent, cancellation_token=None):
        await self.client.write(self.namespace, content.content)
    
    async def query(self, query: str, cancellation_token=None) -> MemoryQueryResult:
        results = await self.client.retrieve(self.namespace, query)
        return MemoryQueryResult(results=[MemoryContent(content=r) for r in results])
    
    async def clear(self):
        await self.client.clear(self.namespace)

then pass it to your agent:

agent = AssistantAgent(
    name="my_agent",
    model_client=model_client,
    memory=[OpenVikingMemory(client, "agent-namespace")],
)

option 2: tool-based integration

if you want the agent to explicitly call into OpenViking rather than using it as background memory, just expose the read/write operations as function tools. more explicit control over when context is retrieved vs injected automatically.

option 3: system message injection

simplest approach - before each turn, query OpenViking for relevant context and prepend it to the system message. less elegant but zero custom infrastructure.

the tiered loading (L0/L1/L2) in OpenViking maps well to autogen's use case - you probably want L0/L1 summaries injected automatically and L2 details only loaded when the agent explicitly requests them. that's the main thing worth thinking through when you design the wrapper.

what's your use case - long-running agent sessions, cross-session memory, or shared context across multiple agents?

Thank you for your kind reply. I will have a try to implement the case which shared context across multiple agents.

[Rick1330]

Integrating OpenViking (Context DB) with AutoGen

Integrating a specialized context database like OpenViking into AutoGen is a great way to handle persistent agent memory across complex multi-agent conversations.

The Strategy: Using ConversableAgent Hooks

In AutoGen, the cleanest way to integrate an external database is to subclass ConversableAgent or use the register_reply mechanism to intercept and store messages.

1. The "Storage" Approach (Simplest):
Register a hook that saves every incoming/outgoing message to OpenViking.

from autogen import ConversableAgent

def openviking_sync(recipient, messages, sender, config):
    # 'messages' is the history of the conversation
    latest_msg = messages[-1]
    
    # Pseudocode for OpenViking integration
    # openviking_client.save_context(
    #     session_id=config["session_id"], 
    #     content=latest_msg["content"],
    #     role=latest_msg["role"]
    # )
    
    return False, None # Continue to next reply function

agent = ConversableAgent(...)
agent.register_reply(
    trigger=[ConversableAgent, None],
    reply_func=openviking_sync,
    position=0 # Run this first to ensure context is saved
)

2. The "Context Retrieval" Approach:
Use OpenViking to fetch relevant historical context before the agent generates a response. You can inject this into the system_message.

# Fetch from OpenViking
# relevant_history = openviking_client.query("search query")

# Update system message dynamically
# agent.update_system_message(f"Here is relevant context: {relevant_history}")

Best Practice: Custom State Manager

If OpenViking supports state management, you can create a custom GroupChatManager that uses OpenViking as the "truth" for the conversation history instead of the in-memory message list.

If this helps you get started with your integration, please consider marking it as the answer!

[Rick1330]

@l2002924700 For the shared context across multiple agents, focus on the OpenViking L1 (shared) tier.

In AutoGen, a practical way to implement this is to register a post-reply hook on your GroupChatManager. After every speaker transition, have the hook "commit" the last message to the shared OpenViking namespace. Then, modify your agents' system_message to include a dynamic retrieval block that pulls from that shared namespace before each turn. This ensures the "global state" is always synchronized across the team.

[l2002924700]

thank u for ur kind reply, I'll have a try.

[msaleme]

The cleanest integration path is to treat OpenViking as a memory boundary with two separate responsibilities: retrieval for relevance, and persistence for continuity. If you collapse both into one hook, you usually end up over-injecting stale context.

A practical pattern in AutoGen is:

1. query OpenViking before each turn for a very small relevance window,
2. inject only the returned summary or top-k snippets,
3. persist the new turn after completion,
4. keep sensitive or per-task scratch state out of the long-term store unless it has earned promotion.

I would also recommend defining the trust policy up front. External memory changes the attack surface because poisoned context can survive across sessions. So the wrapper should record provenance for each memory item, support TTL or recency decay, and make it easy to separate verified operator-authored state from agent-generated summaries.

That separation matters more than the storage backend. The memory store that wins is usually the one the agent can query narrowly and audit later, not the one with the richest schema.

[l2002924700]

thank u for ur kind reply, I'll have a try.