How is this different from our postmortems and runbooks?

Postmortems and runbooks are documents people must remember to read. Glen gives agents memory they retrieve and write automatically in one MCP call, so the relevant prior incident and mitigation surface in context during the next one.

Is the memory shared across the on-call rotation?

Yes. Glen is org-shared, so every SRE's agents read and write the same store. A root cause captured during one incident is immediately available to whoever, and whatever agent, gets paged next.

Shared memory for SREs

Site reliability engineers run on institutional knowledge: which service is fragile under load, what the last three incidents had in common, the runbook step that is technically wrong but actually works, the dashboard that lies. That context lives in postmortems no one rereads, in pinned Slack messages, and in the on-call engineer's memory, so when the same pattern recurs at 3am, whoever is paged starts from cold. As SREs lean on AI agents to investigate alerts, summarize incidents, or propose remediations, those agents start cold too, with no awareness of what already broke and how it was fixed. Glen, shared memory for AI agents, gives those agents a durable, team-shared memory through a single MCP tool that retrieves relevant operational history and records new findings in one round trip.

Wire Glen into the agents your SRE team relies on, an incident-investigation assistant, a coding agent reading logs and metrics, a runbook helper, and each gains one tool that reads the relevant history and writes back what it learned. When an alert fires, the agent retrieves what the team already knows: the previous incident with this signature, the dependency that tends to cascade, the mitigation that worked last time. Once the incident is handled, the agent records the root cause, the timeline, and the durable lesson so the next page is faster. You stop rediscovering the same failure modes and stop depending on whoever happens to have lived through the last outage.

The difference is that operational knowledge becomes shared and durable instead of trapped in individual memories and unread postmortems. Glen is org-scoped, so the memory spans every SRE and every agent on the team, and even other teams' agents that touch the same systems. One engineer's agent records that a particular queue backs up when a downstream cache evicts; every other agent recognizes the pattern next time. Because Glen is a standard MCP server, the same memory is readable from any MCP client, so an alert-triage agent, a postmortem writer, and a deploy assistant all draw on one consistent record of how your systems behave under stress. Connect once over OAuth or an API key and let your reliability knowledge compound across incidents and on-call rotations.

FAQ

How is this different from our postmortems and runbooks?: Postmortems and runbooks are documents people must remember to read. Glen gives agents memory they retrieve and write automatically in one MCP call, so the relevant prior incident and mitigation surface in context during the next one.
Is the memory shared across the on-call rotation?: Yes. Glen is org-shared, so every SRE's agents read and write the same store. A root cause captured during one incident is immediately available to whoever, and whatever agent, gets paged next.