DEV Community: Thomas Jumper

Shared agent memory does not mean shared secrets

Thomas Jumper — Tue, 04 Aug 2026 14:30:00 +0000

"Give every agent shared memory" can sound like an invitation to build a new, invisible data dump. That is not the workflow I want.

Useful shared memory has boundaries.

First, do not store secrets. API keys, passwords, access tokens, customer data, and raw production logs need their proper systems of record. A memory tool is not a vault.

Second, make entries inspectable. A person should be able to see what was stored, which agent stored it, and whether it is still useful.

Third, keep project scope explicit. A lesson from one project should not casually appear in another just because the same person happens to be using the same client.

Fourth, design for correction. Working knowledge changes. Teams need a way to export, archive, revise, or erase memories when a decision is reversed or a note goes stale.

Finally, use memory as an aid to verification, not a replacement for it. A recalled note can tell an agent where to look and what failed before. It should not overrule the current code, test suite, or security policy.

That is the design bar I hold StremAI to: useful project memory that remains human-readable, attributable, scoped, and under the user's control.

The goal is not for agents to remember everything. It is for a useful lesson to survive long enough to help the next connected agent without creating a new source of hidden risk.

What boundary would make you comfortable letting your team share agent memory?

How to onboard a new coding agent without a 40-page prompt

Thomas Jumper — Thu, 30 Jul 2026 14:30:00 +0000

A huge onboarding prompt is an understandable response to a real problem: a new coding agent begins with none of the context a teammate would accumulate over months.

It is also a poor long-term interface.

The longer the prompt becomes, the harder it is to know what is current, what is important for this task, and what should have been a real document instead. The agent receives a wall of context before it has even asked a question.

Try a three-layer onboarding model instead.

Layer 1: Instructions in the repository.

Keep stable rules in CLAUDE.md, AGENTS.md, and project docs: test commands, style, ownership boundaries, and security rules.

Layer 2: A small first-task checklist.

Tell the agent which docs to read and what it must verify before changing code.

Layer 3: Recallable working knowledge.

Let the agent retrieve relevant decisions, pitfalls, and recent handoffs when the task calls for them.

This creates an onboarding flow that pulls context on demand instead of shoving every past lesson into every session.

The practical check is simple: give a new agent a normal task and ask it to explain the relevant architecture decision before it writes code. If it cannot find the answer, either the source doc is missing or the shared-memory habit is not established yet.

The point is not to eliminate human judgment. It is to stop spending human judgment on the same orientation speech over and over.

StremAI can act as the third layer through MCP: connected agents recall project knowledge when it is relevant, while your repository remains the source of truth for instructions and code.

Why your AI coding agents keep reopening the same bugs

Thomas Jumper — Tue, 28 Jul 2026 14:30:00 +0000

There is a familiar kind of wasted hour in agent-assisted development.

An agent finds a bug. It proposes the obvious fix. You explain that the obvious fix broke production last time because of one constraint hidden in a previous investigation. The agent adjusts. A week later, a new session proposes the same fix again.

The problem is not that the model is bad at debugging. The context died where the work ended.

The durable part of a debugging session is usually much smaller than the transcript:

Symptom: what the user or system actually did.
Cause: the confirmed mechanism, not the initial guess.
Constraint: the tempting fix that must not be used and why.
Verification: the test or production signal that proves the repair.

After a real incident or hard bug, store that four-part record. It gives the next agent a chance to avoid the same false start without pretending that a memory replaces investigation.

Example:

Symptom: callback succeeds locally but fails after deploy. Cause: the deployed origin differs from the configured redirect origin. Constraint: do not accept arbitrary redirect URLs as a workaround. Verification: complete the sign-in flow from a clean browser session.

That is more useful than "we fixed OAuth once." It is also safer than pasting an entire incident transcript into every new prompt.

Shared memory should make agents better at asking the right first question. It should not turn stale notes into unquestioned truth.

I built StremAI to make these compact lessons available across connected agent sessions. The entry stays attributable and human-readable, so a developer can inspect, correct, archive, or erase it when reality changes.

The handoff that should not require a meeting

Thomas Jumper — Thu, 23 Jul 2026 14:30:00 +0000

The frustrating part of using multiple coding agents is not that they are different. It is that every handoff starts with a ritual: explain what has already happened, explain the strange decision, explain what not to touch, explain the one test that lies.

Some handoffs deserve a meeting. Most do not.

For routine work, a useful agent handoff has four parts:

Decision: what we chose and why.
State: what changed, what remains, and what is intentionally untouched.
Pitfall: the failure mode most likely to waste the next person's time.
Pointer: the file, issue, or runbook that is the source of truth.

That is small enough to store as project memory after a meaningful change, and specific enough for another connected agent to recall before it begins.

Here is an example:

Decision: use the existing retry helper for webhook delivery. State: validation is complete; follow-up is observability. Pitfall: do not retry non-idempotent writes. Pointer: docs/webhooks.md.

The goal is not to make an agent pretend it was in the prior session. It was not. The goal is to give it the durable context needed to start responsibly.

I think this is the right unit of agent collaboration: a compact, attributable memory that can be checked against the real code and docs.

StremAI is the shared MCP memory layer I use for that workflow. One connected agent stores a decision or pitfall; another can recall it before doing the next piece of work. The MCP memory guide has the setup.

What a coding agent should remember, and what belongs in Git instead

Thomas Jumper — Tue, 21 Jul 2026 14:30:00 +0000

The fastest way to make agent memory untrustworthy is to treat it like a second repository.

Memory is useful when it holds the things that are expensive to rediscover but do not belong in source control as the primary record. Git and docs are still the source of truth for code, specifications, credentials, and change history.

Here is the simple split I use.

Good memory candidates:

Why the team chose an approach when the code alone does not explain it.
A recurring failure mode and the first diagnostic check that saves time.
A setup detail that is real but has not made it into formal documentation yet.
A decision made in a working session that needs to be visible to the next session.
The name and location of a canonical doc the agent should read before changing a sensitive area.

Keep out of memory:

API keys, passwords, tokens, customer data, or private identifiers.
Raw code dumps.
Anything that should be versioned, reviewed, and merged through git.
Unverified guesses presented as facts.

The test is boring and useful: would a teammate be harmed if this memory were stale? If yes, write or update the source-of-truth document. Then memory can point to it and explain when it matters.

For example, "read the migration runbook before touching billing" is good memory. The migration runbook itself should live in the repository.

This keeps recall concise. Agents retrieve the reason, the warning, and the pointer instead of flooding a session with an old copy of the whole world.

Shared memory works best as working knowledge with boundaries, not as a mysterious black box. That is why StremAI shows human-readable, attributed entries and gives people controls to export, archive, or erase them.

What is one thing your team keeps re-explaining that should be a memory, not another paragraph in a prompt?

The two-minute test for whether your coding agents actually share context

Thomas Jumper — Thu, 16 Jul 2026 14:30:00 +0000

Most "connect your agent" setup flows stop too early. A green dot tells you a configuration exists. It does not prove that one agent can retrieve what another agent learned.

Here is the two-minute test I use after connecting any shared-memory service.

In your first coding agent, store one harmless note:

Store a memory titled "setup check" with the content "shared memory is wired up."

Open a fresh session or a different connected agent.
Ask it:

Recall the memory titled "setup check."

There are only two useful outcomes.

It returns the note. Good: the connection, account, project scope, and recall path are all behaving together.
It cannot find the note. Do not keep coding and hope. Check that both clients signed in to the same account and project, then restart the client that was connected before the configuration changed.

This test sounds almost too small, but it catches the failures that matter: a local-only configuration, an expired sign-in, a client connected to the wrong project, or a setup that did not survive restart.

It also gives a team a shared definition of "working." Working is not a dashboard badge. Working means useful context makes it across a real boundary: agent to agent, or session to session.

Once the check passes, replace the test note with five things you are tired of re-explaining: a deployment quirk, a flaky test, an architecture decision, a setup trap, and the convention that keeps coming up in review.

That is enough to make the next session noticeably less blank.

I built StremAI around this exact round-trip. It connects through MCP and lets connected agents store and recall project memory. You can try a recall in the StremAI playground before committing to a workflow.

Your CLAUDE.md is not your agent's memory

Thomas Jumper — Tue, 14 Jul 2026 14:30:00 +0000

I like CLAUDE.md. I also think people are asking it to do a job it cannot do.

CLAUDE.md, AGENTS.md, and .cursor/rules are where you put the rules you want an agent to follow: how to run tests, which folders are sensitive, what style the team uses, and when to ask before deploying. That is written context. It belongs in git.

But a coding agent also learns things while it works.

It discovers that a particular test is flaky under one flag. It learns why an apparently odd abstraction exists. It finds the deployment step that is not in the runbook yet. Those are not stable enough to hard-code into an instruction file, and they are too useful to lose when the session ends.

That is the distinction I use:

Instructions are what your team writes down before the work.
Memory is what your connected agents learn during the work.

The practical move is not to replace instruction files. Keep them. Add a small memory protocol beside them:

How to give Claude Code, Cursor, and Codex shared memory over MCP

Thomas Jumper — Tue, 31 Mar 2026 12:44:08 +0000

I use more than one coding agent in a normal week: Claude Code for most work, Cursor when I'm living in the editor, Codex CLI for scripted runs. They're all good. They also share nothing.

A lesson learned in one session ("staging DB resets Sunday nights", "that test is flaky, ignore it", "we chose pgvector on purpose, stop suggesting alternatives") is gone in the next session, and was never visible to the other tools at all.

The built-in memory options don't cross that gap, and their docs say so: Claude Code's auto memory is per-repository and machine-local; Codex's memories are stored locally and off by default; Cursor's documented persistence layer is Rules, which are files you write yourself.

Instruction files like CLAUDE.md, AGENTS.md, and .cursor/rules are genuinely useful for the context you write. Keep them. What they don't hold is the context your agents learn while working.

The fix is a shared memory layer over MCP: one server that any MCP client can connect to, so a memory stored by one connected agent can be recalled by another.

Here's the full setup with StremAI. Full disclosure: I'm the founder. There are also open-source options like OpenMemory, agentmemory, Memorix, and others if you'd rather self-host, and the verification steps below work with any shared-memory MCP server.

1. Claude Code

claude mcp add --transport http stremai https://stremai.com/api/mcp --scope user

Run it, then approve the browser sign-in. No API key to paste. --scope user makes the connection available in every project, not just the current directory.

2. Cursor

Add one server entry to ~/.cursor/mcp.json for global use, or .cursor/mcp.json for one project:

{
  "mcpServers": {
    "stremai": {
      "url": "https://stremai.com/api/mcp"
    }
  }
}

Cursor should prompt a browser sign-in. Honest note: OAuth verification for Cursor is still in progress on our side. If the prompt doesn't appear in your build, use an API key fallback:

{
  "mcpServers": {
    "stremai": {
      "url": "https://stremai.com/api/mcp",
      "headers": {
        "Authorization": "Bearer ab_live_YOUR_KEY"
      }
    }
  }
}

Existing "agentbay" entries keep working; use "stremai" for new installs so docs and troubleshooting match.

3. Codex CLI

curl -sSL https://stremai.com/install-codex.sh | bash

Or manually in ~/.codex/config.toml:

[mcp_servers.stremai]
url = "https://stremai.com/api/mcp"

4. Verify it actually works

Most setup guides skip the proof step. Don't.

In any connected agent:

store a test memory titled "setup check" with content "shared memory is wired up"

Then open a different tool, or a fresh session, and ask:

recall the test memory called "setup check"

If the second agent returns it without you repeating anything, you have working shared memory. That's the whole product in one round trip: what one connected agent learns, another connected agent can recall.

5. Make it useful

First, tell your agents when to use memory. Put a few lines in your existing CLAUDE.md or AGENTS.md:

- Before answering questions about this codebase, recall relevant project memory.
- After completing a real change, store durable lessons: decisions, pitfalls, gotchas.
- Don't store secrets or raw code; those belong in git.

Second, seed it. Store the five things you're most tired of re-explaining: deploy quirks, flaky tests, architecture decisions, setup gotchas, or the rule everyone keeps rediscovering.

Recall quality is ranked, so the relevant entry surfaces when it matters instead of everything flooding the context window.

What to expect

Memory is user-controlled. Entries are human-readable, attributed to the agent that stored them, and you can export, archive, or erase them from the dashboard.

On teams, one engineer's agent's lesson can be recalled by teammates' connected agents, which is the part that changes onboarding. The point is not that agents magically know everything. The point is that useful working context stops dying inside one tool's session.

StremAI is free to start with no credit card. It is verified with Claude Code and Claude Desktop today, with Cursor, Codex, Windsurf, and OpenClaw supported or in active verification.

Docs: stremai.com/docs/mcp-memory

Try a real recall without an account: stremai.com/playground

Questions or a setup that didn't work? Comment. I read all of them, and broken-setup reports are worth more to me than praise.