docs: add strands-dakera to the Memory Stores community category

[ferhimedamine]

Summary

Adds a community catalog entry for strands-dakera — a persistent, decay-weighted memory store for Strands agents, backed by a self-hosted Dakera server.

Published on PyPI: https://pypi.org/project/strands-dakera/ (pip install strands-dakera).

Following the maintainers' guidance in this thread, the page is filed under the new Memory Stores community category (added in #3130) rather than Tools — strands-dakera's primary integration is a MemoryStore (DakeraMemoryStore) that plugs into the agent loop via a MemoryManager. A full-CRUD dakera_memory tool for explicit model-invoked memory is documented on the same page.

Changes

• site/src/content/docs/community/memory-stores/strands-dakera.mdx — catalog page with the required frontmatter (community: true, integrationType: memory-store, description, languages: Python, project, service).
• site/src/config/navigation.yml — lists the page under Community → Memory Stores.

What it does

DakeraMemoryStore gives agents durable, cross-session memory with decay-weighted recall (importance × recency × semantic relevance), wired through MemoryManager with automatic injection and extraction. The dakera_memory tool exposes full CRUD (store / retrieve / get / update / delete). Self-hosted, no cloud key required.

Related: #3130

[ferhimedamine]

@lizradway @opieter-aws fyi 🙏 thx

[opieter-aws]

Hey @ferhimedamine thanks for your contribution!

This made me realize that we were still missing the MemoryStore template. I've added this (PR).

Would you be able to integrate as a store instead? This allows devs to integrate memory into their agent loop out of the box (including memory injection and extraction triggers)

[ferhimedamine]

Thanks @opieter-aws — that's a much better fit, done.

I've implemented DakeraMemoryStore as a MemoryStore: Dakera-AI/strands-dakera#1

• search(query, options) → Dakera's decay-weighted recall, mapped to MemoryEntry (with id/score/importance preserved in metadata).
• add(content, metadata) → a single client-side write sink, so enabling extraction uses the manager's ModelExtractor. add_messages/initialize/get_tools are left as the inherited Protocol stubs so _has_method detects them as absent.
• Targets strands-agents>=1.45.0; 28 tests pass (ruff + mypy clean) against the real memory API.

Usage:

from strands import Agent
from strands.memory import MemoryManager
from strands_dakera import DakeraMemoryStore

store = DakeraMemoryStore(agent_id="alex", writable=True, extraction=True)
agent = Agent(memory_manager=MemoryManager(stores=[store]))

I've updated this docs page to lead with the store (tool kept as an alternative). One taxonomy question: integrationType in content.config.ts is currently ['model-provider','tool','session-manager','integration','plugin','agent-extension'] and there's no community/*/stores category yet — so I left integrationType: tool for now. Would you like me to add a memory-store value + a stores/ (or memory-stores/) section here to match the new extension point, or do you plan to model that yourself as the store API lands? Happy to follow whichever convention you prefer.

[ferhimedamine]

Update: the DakeraMemoryStore integration is now released — strands-dakera 0.2.0 is on PyPI (requires strands-agents>=1.45.0). So this docs page now describes a shipped feature: pip install "strands-dakera>=0.2.0" gives you the MemoryStore shown here.

The page leads with the store (agent-loop integration via MemoryManager), keeping the dakera_memory tool as an alternative. Ready for a review whenever you have a moment, @opieter-aws — and happy to adjust the integrationType/section if you'd like a dedicated memory-store category.

[github-actions]

Assessment: Comment

Clean, well-scoped docs addition. Frontmatter matches the community-tool convention, and the navigation entry is inserted in the correct alphabetical position. One substantive fix on a link, plus one open taxonomy item you already raised.

Review Categories

• Links: The MemoryStore reference points to the bare homepage instead of the existing memory docs page — see inline comment.
• Catalog metadata: integrationType: tool under-represents the store integration the page now leads with; depends on the maintainer decision from the thread (non-blocking).
• Style (nit, non-blocking): File is missing a trailing newline at EOF (mixed across existing pages, so low priority).

Nice work responding to the earlier feedback and pivoting to the MemoryStore integration.

[opieter-aws]

Hi @ferhimedamine, thanks for calling out we were still lacking a community page for Memory Stores.

We just merged this so you can move your section. Thanks!

[ferhimedamine]

Thanks @opieter-aws — done. I've moved the strands-dakera section into the new Memory Stores category:

• Page relocated to site/src/content/docs/community/memory-stores/strands-dakera.mdx
• integrationType switched from tool to memory-store, so it renders in the Memory stores catalog table
• Nav entry moved under Community → Memory Stores

That's the better home for it — the primary integration is a DakeraMemoryStore that plugs into the agent loop via MemoryManager; the explicit dakera_memory CRUD tool stays documented on the same page. Rebased on main, and the PR is green/mergeable again. Appreciate you spinning up the category!

[github-actions]

Assessment: Comment (near-approval)

Re-reviewed after the move to the new Memory Stores category. Both prior points are addressed: the page is relocated correctly, integrationType: memory-store matches the enum added in #3130, the nav entry is in place, and the branch is rebased on main. Nice iteration.

One small follow-up remains before this is fully clean:

Follow-up

• Link style (Important, easy fix): The MemoryStore reference uses an absolute path; it should be a relative .md-style link to respect the configurable base path and match every other doc page — see inline comment.
• EOF newline (nit): Missing trailing newline.

Once the link is made relative, this is good to go.

[github-actions]

Documentation Preview Ready

Your documentation preview has been successfully deployed!

Changed pages:

• community/memory-stores/strands-dakera

Updated at: 2026-07-21T20:32:10.270Z

[opieter-aws]

@ferhimedamine could you rebase and check the CI please? Sorry for the delay on my side!

[ferhimedamine]

Done — rebased on latest main and fixed the link. Thanks for the patience, @opieter-aws!

Two changes in this push:

• Relative MemoryStore link — switched /user-guide/concepts/memory/overview/ → ../../user-guide/concepts/memory/overview.md, matching the sibling memory-stores/overview.mdx so it resolves through PageLink.astro/ASTRO_BASE_PATH instead of bypassing the base path. This was also the root cause of the red Docs / CI — astro-broken-links-checker was failing on that one absolute link (Broken link: /user-guide/concepts/memory/overview/); it's now a valid relative link.
• EOF newline added to the page.

Rebased onto main (resolved the navigation.yml overlap so both agentcore-memory-store and strands-dakera are listed under Memory Stores) — PR is back to MERGEABLE. CI re-running now; the docs broken-link check should be green this time. Ready for another look. 🙏

[github-actions]

Assessment: Approve ✅

All prior feedback across both rounds is resolved:

Resolved items

• MemoryStore link: Now a relative .md link (../../user-guide/concepts/memory/overview.md) matching the sibling overview.mdx — respects the configurable base path. ✓
• Catalog taxonomy: integrationType: memory-store (valid enum value) with the page correctly filed under the Memory Stores category and nav. ✓
• EOF newline: Fixed. ✓

Frontmatter is schema-valid, the internal link target resolves, and the branch is rebased on latest main. Clean, well-scoped community docs addition — nice work iterating on the feedback.

[ferhimedamine]

@opieter-aws all green , i see you approved , can we merge ?

[ferhimedamine]

Thanks for merging, @opieter-aws! 🙏 One heads-up on the live site: the page still 404s in production —

• https://strandsagents.com/docs/community/memory-stores/strands-dakera/ → 404
• The Memory Stores catalog at https://strandsagents.com/docs/community/memory-stores/overview/ also renders empty.

I dug in and it looks like a deploy-cadence thing rather than anything in this PR (files are correctly on main, and the Deploy Preview rendered fine). The production Pages workflow (docs-deploy-github-pages.yml) is workflow_dispatch-only, and the last run was 2026-07-17. Both this page and the sibling agentcore-memory-store page (merged 07-20) landed after that, so neither is on gh-pages yet — that's why both 404 and the catalog is empty:

• https://strandsagents.com/docs/community/memory-stores/agentcore-memory-store/ → 404

Could you kick off a "Docs: Deploy to GitHub Pages" run when you get a chance? That should publish both pages and populate the catalog. Might also be worth adding a push: [main] trigger so future docs merges auto-publish. Thanks again!

[ferhimedamine]

Thanks for merging, @opieter-aws! 🙏 One heads-up on the live site: the page still 404s in production —

• https://strandsagents.com/docs/community/memory-stores/strands-dakera/ → 404
• The Memory Stores catalog at https://strandsagents.com/docs/community/memory-stores/overview/ also renders empty.

I dug in and it looks like a deploy-cadence thing rather than anything in this PR (files are correctly on main, and the Deploy Preview rendered fine). The production Pages workflow (docs-deploy-github-pages.yml) is workflow_dispatch-only, and the last run was 2026-07-17. Both this page and the sibling agentcore-memory-store page (merged 07-20) landed after that, so neither is on gh-pages yet — that's why both 404 and the catalog is empty:

• https://strandsagents.com/docs/community/memory-stores/agentcore-memory-store/ → 404

Could you kick off a "Docs: Deploy to GitHub Pages" run when you get a chance? That should publish both pages and populate the catalog. Might also be worth adding a push: [main] trigger so future docs merges auto-publish. Thanks again!

Fixed 🎉