GoodMem Memory Connector API for agentic tasks and workflows

[MuaazWahid]

We built a memory connector for Semantic Kernel that can simplify the process of setting up memory management for AI agents in Semantic Kernel. As of now, Semantic Kernel developers who want to setup persistent memory for agentic tasks have to manage embedding services, models, and dimensions across collections.

GoodMem is a lightning-fast memory API for AI agents to easily read & write persistent memory for agents (embedding pipeline included).

GitHub feature request: #13626

Codebase: https://github.com/PAIR-Systems-Inc/goodmem-semantic-kernel

without GoodMem

# 1. Pick, configure, and maintain an embedding service
embedding_service = OpenAITextEmbedding(
    ai_model_id="text-embedding-3-small",
    api_key=OPENAI_API_KEY
)

# 2. Stand up a vector store and wire in the embedder
store = InMemoryVectorStore(embedding_service=embedding_service)
collection = store.get_collection("agent-memory", record_type=Memory)

# 3. Manually ensure embedding dimensions match your model
# 4. Begin to write agent logic

with GoodMem

async with GoodMemCollection(record_type=Memory, collection_name="agent-memory") as collection:
    await collection.upsert(memory_list)
    agent = ChatCompletionAgent(
        name="MemoryAgent",
        service=OpenAIChatCompletion(ai_model_id=openai_model),
        instructions=("Always search memory before answering factual questions."),
        function_choice_behavior=FunctionChoiceBehavior.Auto(),
        plugins=[collection.as_plugin(name="memory")],
    )

[aniruddhaadak80]

From my point of view, the value here is obvious because memory wiring is one of the first things that turns simple agent examples into infrastructure work.

The tradeoff I would want to understand is how much configuration is intentionally hidden. Abstracting embeddings and dimensions is great for adoption, but teams eventually need to reason about migration, re indexing, model changes, and debugging retrieval quality.

If the connector surfaces collection metadata and a clear story for re embedding over time, it feels much stronger as a long term integration instead of only an onboarding shortcut.

[MuaazWahid]

hi aniruddha, thanks for the feedback.
most of what you're asking about is already present in GoodMem. this plugin is a thin wrapper around our service; the full GoodMem API exposes more powerful features and configurations.

on metadata: GoodMem surfaces collection ("Space") metadata including labels for organization and filtering, space_embedders with default_retrieval_weight, standard audit fields (public_read, owner_id, created_at/updated_at), and default_chunking_config per space.

on re-embedding: memories are immutable once stored. dimensionality, model_identifier, and distribution_type cannot be changed while an embedder is referenced by a space. there is no automated re-embedding workflow today; that would be handled manually. we're planning to add a copy operation to move data between spaces as a cleaner path for re-indexing under a new embedder.

on retrieval debugging: this is manual at the moment and something we're looking to improve, it's on our radar as a future feature.

GoodMem is designed as a long-term memory infrastructure for AI agents, agnostic to embedders, models, and vendors. Happy to answer any further questions.

[Nyrok]

The retrieval debugging point from aniruddhaadak80 is the key one. Knowing what role retrieved content plays in the agent's reasoning matters for debugging. When memories get appended to flat prose system prompts, it's hard to isolate whether a failure comes from the retrieval step or from task instruction ambiguity.

Named semantic blocks help here. A context block gives retrieved memories a defined slot, separate from role, objective, and constraints. When something breaks, you can diff blocks individually instead of debugging an unstructured text blob.

I've been building flompt for exactly this, a visual prompt builder that decomposes prompts into 12 semantic blocks and compiles to Claude-optimized XML. Memory injection gets cleaner when the base prompt already has a defined context slot. Open-source: github.com/Nyrok/flompt

A star on github.com/Nyrok/flompt is the best way to support the project, solo open-source, every star helps.

[MuaazWahid]

hi nyrok, good point.

isolating retrieved content into a defined context slot makes it easier to find failures. if memory is injected into a flat system prompt, it's difficult to debug what came from retrieval vs. what came from task instructions.

GoodMem approaches this from the infrastructure side: memories are stored and retrieved as discrete, structured units rather than appended as raw text. however we do also have a built-in prompt builder, so memory injection and prompt structure can be managed with one tool rather than multiple tools.

however, the visual semantic block approach you describe is great for visual accessibility. i'll check out your project.

[vgudur-dev]

One angle that hasn't come up yet: write-path security.

When agents have persistent memory, the write path becomes an attack surface. A malicious user (or a compromised tool output) can inject instructions disguised as memories that persist across sessions and silently influence all future agent behavior. This is distinct from prompt injection because it survives context resets.

For memory connectors like GoodMem, adding a validation hook before upsert would let teams catch poisoned entries before they're persisted. Something like:

async with GoodMemCollection(...) as collection:
    collection.add_write_validator(scan_fn)  # reject entries that look like injected instructions
    await collection.upsert(memory_list)

We've been working on this exact problem at OWASP — Agent Memory Guard provides a scan_text() function that detects injection patterns in ~59µs per entry using entropy + heuristic + semantic layers. Zero deps, MIT licensed.

Would be interesting to see if GoodMem could expose a pre-write hook API so users can plug in their own validation logic (whether AMG or something else). The retrieval debugging point from @Nyrok is important, but catching bad data before it's stored is arguably higher leverage.