What's New

Adding an article to a project, or declaring it as ground truth, used to ask for something nobody has in hand: a 36-character id. Getting one meant leaving the page, finding the article in the Library, copying the id, and coming back. Now you type the title and pick it from a list. The id field is still there — it is exactly right when you are pasting from a script or an agent's output — but it is no longer the only way in.

The list shows what you can actually add. Ground truth excludes private articles — including your own, because no membership widens a private article and a brief nobody on the team can open is not a brief. The list says which question it is answering, so "no matches" never leaves you wondering whether search is broken.

Where an artifact came from, and where it belongs, are two different facts. An article written by an agent inside a project's work is produced there — that is its origin. Putting it in the project is a decision someone makes, and it is the one with consequences: the project ranks it up in retrieval, its agents may maintain it, and if the article is set to project visibility, the team can read it. The Projects control on an article now shows both — a created here note where it came from, and a checkbox for whether it is in the project. They are independent, and an article can be either, both, or neither. If something an agent wrote looks like it belongs to a project but is not in it, that is now visible, and one click fixes it.

Projects get a display name you can change. Renaming lives in the project's Settings, and a delegate can do it, not only the owner. What changes is the label you read; the project's identity stays fixed, so nothing filed under it comes loose.

A project can say what is NOT true. Ground truth has always had two halves — what a project answers from, and what it must not repeat. The second half now carries: a project inherits ENGRAM's own list of known-false claims, and agents can read and set a project's list over MCP with get_project_refuted and set_project_refuted, bringing the tool surface to 53. It matters because the two behave differently on purpose: a brief is ranked up and reaches a worker on its own, while a list of falsehoods is never retrieved as truth — so an agent has to ask for it, and now it can.

Visibility reads at a glance. Private, project and public artifacts now carry the same labelling everywhere they appear — Library, Viewer and Projects page — so you can tell what an article is exposed to without opening it.

For agent authors: when remember is given entity ids that do not resolve, ENGRAM now extracts entities from the content instead and says so in the response, naming what it discarded. A memory that would otherwise be unreachable gets stored and stays findable — and you are told the links are not the ones you asked for.

Until now a project was yours. You could curate what it held, declare what it answered from, and split it into units — but only you could see any of it. A project can now have members: add a colleague or one of your agents, and they can read the project and the material in it. It is the difference between a folder and a team.

Ground truth your team can keep to itself. Anchoring a project used to mean publishing the brief — the only way to make it readable by the people working from it. Now an article set to project visibility can be a project's ground truth: governed by the team, invisible outside it, and resolved by every worker on the project exactly as a public one is. A brief no longer has to be public to be shared.

A unit sees what its repository is working from. Sub-projects can now read the artifacts their parent holds, so a unit starts from the repo's material instead of an empty shelf. They stay the parent's — listed separately, never claimed by the unit — and a unit that wants to work only from its own material can turn the inheritance off. An inherited brief stays readable either way.

What membership does not do is worth saying plainly, because it is usually assumed. A member can read; they cannot edit the project, change its settings, or reach anyone's memories — those stay personal and are shared one at a time, deliberately. A private artifact stays private to its owner no matter who joins.

And now the agents on a project can actually work together. A token marked Restricted used to be all-or-nothing — safe, and unable to collaborate: an agent could be put on a project and curate what it held, yet not share a single memory with the person who added it. That line was drawn around the agent, back when there was nothing smaller to draw it around. A project is smaller. Agents now sit on a ladder — Contributor, Project Collaborator, Agent Manager — and on the middle rung and above, a Restricted token keeps exactly the abilities that only make sense between collaborators: sharing a memory or live working state with someone it shares a project with, and raising its own article from private to project. It is still one toggle; the rung decides how far it reaches. See Roles & agent management.

An agent manager can delegate again, and publishing is clearly yours. Restricting a manager's token used to remove the one thing that made it a manager — it could not create a sub-agent or hand out a token. Now it can, under a rule simpler than the ban it replaces: a token can never mint one more powerful than itself, so a delegation tree only narrows as it grows. Meanwhile anything an agent writes can be private, or project-visible for the team — but making something readable by everyone is an act for a full-authority token. Until project visibility existed there was no way to give a team a brief without publishing it to the whole instance; now there is.

Seven more tools for agents, bringing the MCP surface to 51: curate what a project holds (add_to_project, remove_from_project, list_project_artifacts), manage who is on it (add_project_member, remove_project_member, list_project_members), and read a single memory back by id with get_memory — the missing counterpart to correcting one, which until now meant editing something you could not first read.

A project used to be something you filtered by. It is now something you can curate. The new Projects page — a top-level tab, beside Knowledge Base — lists every project you own and, for the one you pick, shows what it holds, what it answers from, and how it is set up. One screen instead of a filter chip and a lot of inference.

An artifact can belong to more than one project, and now says so. Open any article or document and the new Projects control lists the projects it belongs to; tick or untick to change that on the spot. A research note can sit in two teams' projects at once, which is usually the truth of it. The Library's project filter now finds an artifact under every project it belongs to rather than just one.

Adding to your Library says where things will land. The Add to Library panel now carries a project chip, so a page you fetch or a file you upload goes where you meant it to. With no project selected it tells you plainly that the artifact will go to your default project rather than quietly choosing one for you.

Two words worth knowing on the Projects page. Artifacts marked created here came out of the project's own conversations; everything else was added on purpose. Only the latter is a claim anyone made about the work — and only the latter can be maintained by the project's agents.

An access token has always said who you are. It now also says how much it may do. Every token you hold can be set to Restricted: it reads everything you can read and adds articles, documents and memories as before, but it cannot create accounts or hand out credentials — it can't mint a sub-agent, issue or rotate a token, or change a user. The toggle is on each key in Settings → API Keys, and on each agent token under Administration → Agents.

The point is the tools that read things you didn't write. A desktop assistant that ingests documents and web pages, an agent triggered by a webhook, a CI job — each of them takes in text from somewhere else and acts on it, while holding a token that can do everything your account can. Restricting that one token leaves the assistant working exactly as it did and takes the account-creating power off the table. The token you drive yourself stays Owner; authority is set per token, not per account, so one agent can hold both.

Nothing changes until you change it. Every existing token keeps full authority, so no integration breaks on upgrade — this is opt-in, one key at a time. New keys can be created Restricted from the start, rotation preserves whatever a token had (so routine rotation never quietly hands power back), and a Restricted token can't lift its own restriction — that takes the browser or another Owner token.

Retrieval is associative — it finds what's related. That's what you want when you're exploring, and not what you want when a question has a right answer. Ground Truth lets a project declare which articles are authoritative, so questions asked in that project are answered from the documents you chose rather than from whatever happens to be nearby. Declare a set and retrieval prefers it; switch a project to restrict and the answer comes from that set only — the difference between being informed by a document and being bound by one.

It grounds your agents, not just your articles. A coding agent working in a project reads its ground truth the same way you do — so the contract, the conventions and the decisions your team agreed are what it builds against, rather than whatever it inferred from the code in front of it. Two agents on the same project work from the same document instead of two plausible readings of it, and a new agent starts out already knowing how the system behaves. The same set is also what the accuracy checks verify against, so an article that contradicts your ground truth gets caught before it reaches your knowledge base.

Your default project already has one. ENGRAM now ships its own documentation as a ground-truth corpus, and every user's default project draws on it automatically — so asking “how does recall actually work?” is answered from ENGRAM's own reference rather than from whatever you happen to have saved. Nothing to configure, and nothing changes for projects where you've already declared your own ground truth: those keep exactly the scope you gave them. Agents inherit it too, which means a new agent starts out knowing how the system it's working in behaves.

Your coding sessions capture what happened day to day. The new Build Timeline turns that history into the shape of the whole system — and how it got there. Open a project in Coding Sessions and you'll see every component your agents have built move through its life: scaffolded → wired → tested → deployed, on a real timeline, with the releases that shipped it marked along the top. A dependency graph shows what's connected to what. A Features view groups a run of releases into the initiative they delivered — so a project like Memory Fact Update becomes a single arc you can click into to see its releases, the components it touched, and the very sessions that built it. A Build activity heatmap shows your true development pace — git commits, not just captured sessions — and gap flags surface anything dormant or never shipped. It's sourced from git, which is authoritative about what actually shipped, joined to your session history for the why. Nothing to set up: it reads the history you already have.

Decisions get reversed, versions bump, preferences update — and now your memory keeps pace without ever losing the past. When you correct something, ENGRAM supersedes the old memory instead of overwriting it: recall returns the current truth, while the previous belief stays on record, so you can always see what you used to think — and undo a correction if it was wrong. Three plain-language moves do it: revise a fact, forget one that's no longer true, or revert to bring a retired memory back. ENGRAM also notices contradictions on its own — a confident update is applied automatically, and anything it isn't sure about is set aside for you to decide in Knowledge Health → Gaps → Memory, where you see the two beliefs side by side — Retiring and Keeping — and approve or reject. And the whole story is now visible in the Memory Explorer: every memory shows whether it's the current belief or a retired one, along with the dates it was valid — and opening any memory reveals a History tab with the full trail of what you used to believe, newest first, including when and why each version was retired. Your connected tools get the same three moves over MCP. Nothing is ever silently rewritten, and nothing is ever deleted.

You can now bring sources into your Knowledge Base without going through Chat. Add from URL fetches a web page, pulls out just the article — dropping nav bars, ads, and cookie banners — and files it as a clean document you can later summarize, compare against your notes, or ground a report on. Upload file adds a PDF, Markdown, or text file directly. Both live in a new Add to Library panel that stays open so you can queue several at once and watch each one index. The Library's filters are cleaner too: pick a source (web pages, uploaded files, conversation, and more) and visibility as two simple controls. Agents can do the same over MCP with the new ingest_url_as_document tool. And when you build a report grounded on those sources, chat now shows a “Grounded on” badge above the answer — listing exactly which documents fed it, and whether each went in in full or was summarized to fit — so you can see what the report actually stands on, distinct from the related reads it merely referenced.

A new Agent Manager role lets people you designate create and manage their own connected agents — the bots and assistants that connect to ENGRAM as their own accounts — without granting full administrator access: they provision agents, manage their access tokens, and see an activity history for just the agents they own, up to a per-manager limit. Building on that, an orchestrator agent can now grow its own team — promote an agent you own to Agent Manager and it can create specialist sub-agents, each a distinct identity with its own memory, and fan work out to them. The Agents page shows the whole team as a delegation tree, with the person at the top as the single point of limits, audit, and control; and disabling an agent now pauses it (re-enabling restores it) rather than tearing it down. Grant the role from Administration → Users.

Long research PDFs and other documents are now captured completely and in reading order — every section makes it into your knowledge base, in the order the author wrote it. That means more complete search results and better-grounded articles when you build on an attached source. Documents you'd added earlier were rebuilt to the same standard, so your existing library benefits too.

When an assistant drafts an article to fill a knowledge gap, ENGRAM now checks its claims about how ENGRAM itself works against the real system before the draft reaches your inbox. Drafts that get it wrong are flagged for a closer look — or set aside — and when you review a proposal you can see the exact concerns highlighted in the draft text, so you approve accurate knowledge rather than plausible-sounding mistakes. Auto-drafted articles also carry a clear “AI-drafted” marker in your Library until you've reviewed them.

When you share a memory with an assistant you collaborate with, you can now scope that share to a project — so the assistant draws on those memories only while it's working in that project, and a single assistant helping you on several projects keeps each one's memory separate. Pick a project or conversation in Your Memories and the share dialog offers it as the scope; or use Share all to hand over a whole project or conversation at once. New scope badges mark memories that are private to a conversation or task, so you can see what you're widening before you share. (Sharing with people is unchanged — they recall everywhere they work.) And a new Help button in the Memory Explorer explains how memory, suggestions, and sharing fit together, right where you need it.

The Memory Explorer is reorganized into three tabs — Your Memories, Suggestions, and Sharing — so each has room to breathe. In Your Memories you can now filter long-term memories by where they came from (a project, a conversation, a source) and see your total at a glance; click any memory to read its full content in a side panel. Suggestions lets you review a batch memory-by-memory — keep the ones worth keeping, skip the rest — and tells you when one was handed off by someone else. And a dedicated Sharing view shows what you've shared and what's been shared with you, by name, with a preview of each memory and a click to read it in full.

The assistants you already work in — Claude Code, Claude Desktop, and other connected tools — can now recall your ENGRAM memories on demand, not just inside ENGRAM chat. Ask one to look up what you decided, and it brings back what's relevant — your own memories, or any shared with you — each tagged with why it surfaced. You can share a memory with a collaborator and hand off a piece of work for them to review, and an assistant can discover who you're able to share with so it picks the right recipient. It all stays private by default and fail-closed: nothing surfaces that isn't yours or explicitly granted to you, sharing is enabled by your operator, agent recipients are opt-in, and any grant is revocable.

For owners running ENGRAM, a new operations dashboard makes the memory features observable at a glance — how often memories are reinforced through use, what's being shared, and which inferred suggestions are kept versus set aside. It pairs with a refinement to reinforcement itself: the memories ENGRAM actually draws on to answer you now count toward growing stronger, so “sharper with use” reflects the answers they helped produce. As always, these memory behaviors stay off by default — the dashboard helps owners decide when to turn them on and confirm they're working as intended.

The memories you actually rely on now grow stronger the more they're used. Each time ENGRAM recalls a memory to help answer you, that memory's pull on future retrieval ticks up a little — so the notes that keep proving useful surface more readily over time, the way spaced repetition strengthens what you revisit. It's entirely automatic: there's no action to take and nothing new to manage, and it only ever strengthens your own memories. Like inferred suggestions, this is off by default — your operator decides whether to enable it.

ENGRAM memory has always been private to you. Now you can deliberately share a memory — a single fact, or everything tied to one task or project — with another ENGRAM user, so it surfaces in their retrieval too. Sharing is explicit, bounded, and revocable: you choose what and with whom, you can set a grant to expire, and you can pull it back at any time; the recipient can recall what you shared but never edit or re-share it. A new Sharing section in the Memory Explorer shows everything you've shared and everything shared with you. The same rails power hand-offs between assistants working on your behalf. Private-by-default doesn't change — nothing is shared until you create a grant.

Until now ENGRAM only kept the memories you deliberately committed. Now it can also notice the salient things you didn't stop to flag — a decision you landed on, a fact you established, a preference you voiced — and gather them at the close of a task into a set of suggested memories. Nothing inferred is ever recalled on the quiet: every suggestion first passes an independent reviewer, and only the clearly worth-keeping ones are kept automatically — the rest wait for you. A new Suggestions inbox in the Memory Explorer collects everything awaiting your review — inferred proposals and your own committed recaps, each badged by where it came from — to Accept or Reject in one place. Inferred suggestions are off by default, and nothing inferred becomes recallable without the reviewer's approval or your accept.

ENGRAM has always remembered by quietly observing your work. Now you — or an assistant working alongside you — can deliberately decide this is worth remembering: a decision and its rationale, an established fact, a preference. One remember action commits it, and it becomes part of what ENGRAM recalls for you. At the close of a coding session or task, ENGRAM can gather the whole arc into a recap — proposed for your review, not saved behind your back. Accept it to make those memories recallable, or set it aside. Nothing durable is kept without your say-so.

Group everything that belongs to one body of work — conversations, coding sessions, captured research, and the articles and documents drawn from them — into a project. A Projects panel across Chat, Knowledge Base, and Coding Sessions lets you search, create, and switch projects; new chats file into your active project automatically, and you can move items between projects at any time. ENGRAM also now traces where each piece of knowledge came from, so every article and document shows its source.

A brand-new account is no longer an empty room. Ask “What is ENGRAM?” or “How does the Knowledge Hub work?” and get grounded answers right away, drawn from a set of public onboarding articles — no setup or content of your own required. Your own knowledge then builds on top as you research and save.

ENGRAM moved from a single-machine setup to a proper hosted service: reach it at its own address over your private Tailscale network from any of your machines, sign in with a magic link, and — for owners — manage accounts and runtime settings from an Administration area. Releases now ship through an automated build-and-deploy pipeline.

See your knowledge base the way a librarian would. The Knowledge Health panel surfaces gaps (topics you've discussed but never written down, islands that never connected), a Coverage & Depth view of how well each topic is covered, and a Vitals dashboard of recent activity — so you know what's missing and where to grow.

The core of ENGRAM: chat with long-term memory that recalls by relevance rather than recency; a Knowledge Base of articles and documents that become part of your personal graph; a Graph Explorer to navigate your topics; capture of research from other assistants (Claude Desktop, ChatGPT, Gemini) and of your Claude Code sessions; and bring-your-own-LLM so you choose the model behind it. Your conversations and the memories drawn from them stay private to you.