Engram Shares AI Agent Runbooks via MCP

Engram is an open-source project from the aiengram GitHub organization that stores shared procedural memory for AI agents through MCP and REST. It deals with a very practical agentic coding problem: agents keep rediscovering the same steps, but most repo memory is either local, unverified, or trapped in chat history. The useful idea is not that agents need more memory; it is that reusable procedures should carry evidence from real runs before another agent trusts them. Engram is a peer-verified runbook memory for agents.

Understand what Engram actually stores

Engram stores procedures, not vague notes. A procedure is an execution-shaped runbook: search for this, run that command, check this output, avoid that failure mode.

The project exposes those procedures over MCP, the Model Context Protocol, and REST. Agents can call engram_search to find a relevant procedure, fetch it with engram_get, run it locally, then submit an attestation after execution.

The interesting part is the ranking model. Engram says it combines BM25 search with vector search, then ranks procedures by trust using Wilson-ranked scores from execution attestations. In plain English: text relevance gets you candidates, but repeated successful use should move a procedure up.

The trap is treating this like a generic knowledge base. A wiki page can be useful even when nobody has tried it recently. A procedural memory system is only as good as the runs, failures, and attestations that keep it honest.

Notice the Nostr-shaped bet

Engram uses Nostr-native identity with secp256k1 Schnorr keys through nostr-tools. The README says procedures and attestations are broadcast as Nostr events, including replaceable events for records, long-form articles, and reactions.

That gives the project a portable identity story. The same key can exist across MCP, REST, and relays, rather than tying trust to one SaaS account.

It also makes Engram feel different from a private context registry. The source describes open recall, peer verification, hybrid search, and fail-closed publishing with static analysis plus Gemini review before procedures go live.

That is a lot of machinery for a small repo. As of the September 2026 Show HN signal, the repository was TypeScript, Apache-2.0 licensed, and tiny by GitHub-star count. Read that as an early experiment, not as a battle-tested platform.

What changes in the coding day

The day-to-day change is simple: before an agent invents a migration plan, it can look for a previously verified one. That matters most for procedures that are easy to explain but annoying to get right.

Picture Claude Code, Anthropic's coding agent, working in a service repo. Before changing a Prisma migration, it searches Engram for the local migration procedure, finds a runbook that says to regenerate types, run the containerized database, and inspect the generated SQL, then follows those steps in the repo.

That is more useful than telling the agent to be careful. It gives the agent a concrete path and gives the reviewer a claim to inspect: did the runbook fit, and did the agent actually follow it?

The trap is skipping local judgment. A verified runbook from another repo can still be wrong for yours. The procedure should be treated like a patch suggestion: helpful, reviewable, and never exempt from tests.

This is also where Engram overlaps with the broader context-registry conversation. APIMatic's Context Registry takes a more API-docs-centered path for coding agents; Engram's bet is that executable procedures can become shared memory. If you want that adjacent story, see Show HN: APIMatic’s Context Registry for Coding Agents.

Try it as a read-only memory first

The safest first boundary is read-only recall. Let the agent search and fetch procedures, but do not let it publish new procedures or attestations until a human has looked at what it ran.

For Claude Code users, the practical shape is an MCP permission note plus a review habit. The note says the Engram MCP server may be used for recall, while publishing, attestation, and any relay-writing action require explicit approval. A short CLAUDE.md line can support that boundary without turning repo memory into a policy novel.

A useful line is: before using an external runbook, summarize why it fits this repository and name the local command that will verify it. That keeps the agent from laundering outside instructions into local authority.

The trap is giving the memory layer write permissions too early. If an agent can publish procedures automatically, one bad run can become another agent's confident suggestion.

Copy this integration decision table

Use this table when deciding how to wire Engram into a real coding workflow. It is deliberately small. The point is to choose the boundary before the first impressive demo.

Permission-boundary note for Claude Code: keep Engram recall read-only at the MCP layer, then use a hook or review step to catch risky command execution. The memory server can suggest a path; the repo still decides what may run.

That boundary fits the larger agentic coding governance question without making Engram into a compliance system. The concrete issue is smaller and sharper: can a coding agent borrow a runbook without inheriting unsafe permissions?

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• How should teams start with Claude Code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “Engram Shares AI Agent Runbooks via MCP.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• engram — source
• Model Context Protocol — specification
• Claude — Agent
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.