Does this fit the Strands model-driven philosophy?

Yes. Strands gives the model tools and lets it act; Glen is just one more tool. The agent reads context and records facts through it, so durable memory becomes part of the loop without extra orchestration.

Do separate Strands agents share what they learn?

Yes. Glen is org-scoped, so a fact one Strands agent records is readable by every other agent in your org, on Strands or any other framework, instead of being trapped in one process.

Shared memory for Strands Agents

Strands Agents takes a model-driven approach: you give an agent a prompt and tools, and the loop lets the model plan and act with minimal orchestration code. That simplicity gets you to a working agent fast, but it also means memory is whatever you bolt on. A Strands agent keeps a conversation in context during a run, yet nothing durable persists afterward, and two agents built with Strands share nothing. Each one rediscovers the same operational truths, the API quirk, the customer preference, the fix that worked, every time it starts. Glen, shared memory for AI agents, gives your Strands agents a durable, shared memory as a single MCP tool, so what one agent learns becomes available to them all.

Because Strands leans on the model and tools rather than heavy orchestration, adding memory is naturally a matter of giving the agent the right tool, and Glen is exactly that. Connect it over MCP and your Strands agent gains one capability that retrieves relevant long-term context and records new facts in a single round trip. The model can read what the organization already knows before it plans, then write back what the run discovered, so durable memory becomes part of the agent loop without you standing up a vector store, an embedding pipeline, or a custom persistence path on the side.

Because Glen is org-scoped, that memory is shared across every Strands agent, every deployment, and every other agent in your organization, not tied to a single agent process. One agent learns a durable fact; another Strands agent, or an agent on a different framework entirely, reads it next time it runs. That cross-agent persistence is precisely what a lightweight, model-driven loop does not give you on its own. And because Glen is a standard MCP server, the memory your Strands agents write is readable from Claude Code, Cursor, or any other MCP client, so your minimal agents and the rest of your tooling draw on one knowledge base. Wire it in once over OAuth or an API key and let the knowledge compound run after run.

FAQ

Does this fit the Strands model-driven philosophy?: Yes. Strands gives the model tools and lets it act; Glen is just one more tool. The agent reads context and records facts through it, so durable memory becomes part of the loop without extra orchestration.
Do separate Strands agents share what they learn?: Yes. Glen is org-scoped, so a fact one Strands agent records is readable by every other agent in your org, on Strands or any other framework, instead of being trapped in one process.