StarkSphere Labs
← Engineering blog
Jun 24, 2026agentsmemorymcpextremis

Giving an AI agent memory that survives the session

A stateless agent is a goldfish. It is bright for one conversation and remembers none of it afterwards. For a demo that is fine. For a product people come back to, it is the whole problem.

The usual fix is to stuff everything into the prompt, which works right up until the context window fills and the costs climb. What you actually want is memory you can write to, query, and prune, separate from the prompt. That is what extremis is for.

Memory as a service the agent can call

extremis is MCP-native, so an agent talks to it the same way it talks to any other tool. You point the agent at the extremis MCP server and it gets remember and recall alongside its other tools.

{
  "mcpServers": {
    "extremis": {
      "command": "npx",
      "args": ["-y", "extremis-mcp"]
    }
  }
}

Now the agent can write a memory when something matters and pull it back later, across sessions.

Video placeholder · Wiring extremis memory into an agent

Layers, not one big blob

The mistake is treating memory as a single bucket of text. extremis splits it into layers, because they age and get queried differently:

  • Episodic is what happened: this user asked for a refund on Tuesday.
  • Semantic is what is true: this account is on the Pro plan.
  • Procedural is how you do things: the steps your team follows to run an incident.
  • Identity is who the agent is and who it is talking to.

Keeping them separate means a stale episodic detail never gets mistaken for a durable fact, and recall stays cheap because you query the layer you need.

The takeaway

If users come back and the agent acts like it has never met them, no prompt engineering will save it. Give it memory as infrastructure, and the whole product feels different.