Your AI Agents Now Have Long-Term Memory

Every AI agent has the same fundamental limitation: when the session ends, the knowledge disappears. Your backend agent spent an hour learning your service architecture. Your operations agent mapped every incident from the last quarter. Your research agent built a detailed competitive landscape. Then the context window resets and all of it is gone.

Today we are shipping the Knowledge Base Attachment API — a single endpoint that gives any agent persistent, structured, access-controlled memory that survives across sessions, across restarts, across your entire organization.

One API Call, Persistent Memory

The API is simple by design:

POST /api/v1/orgs/{org_id}/agents/{role}/kb/attach

{
  "kb_id": "your-knowledge-base-id",
  "access_level": "read-write",
  "inject_tools": true
}

That is it. One call and your agent has a persistent knowledge base backed by Neo4j — a graph database that stores not just documents but the relationships between them. The agent can query, write, traverse, and build on that knowledge across every session from this point forward.

No configuration files to edit. No restart required. No infrastructure to provision. The attachment is live immediately.

Many-to-Many: The Right Architecture for Organizations

Knowledge does not live in silos and neither should your agents' memory. The attachment model is many-to-many:

• One agent, multiple knowledge bases. Your backend agent can have its own engineering KB for architecture decisions, plus read access to the operations KB for incident context, plus read access to the product KB for feature requirements. It sees everything it needs without duplicating information.

• One knowledge base, multiple agents. Your engineering KB can be shared across backend, devops, and QA agents — each with appropriate access levels. When the backend agent documents an architecture decision, the devops agent can immediately query it.

This is how institutional knowledge works in real organizations. The engineer who designed the auth system and the operations engineer who deploys it both need access to the same decisions, the same runbooks, the same incident history. They do not each maintain their own copy.

Access Levels That Make Sense

Every attachment has an access level:

• read — The agent can query the knowledge base, search semantically, traverse relationships, and retrieve pages. It cannot modify anything. This is the right default for agents that need context but should not be writing to shared knowledge stores.

• read-write — The agent can do everything read allows, plus create new pages, build relationships between entities, ingest documents, and update existing content. This is for agents that are active contributors to organizational knowledge.

The access level is set per attachment, not per agent or per knowledge base. Your backend agent can have read-write on the engineering KB (where it documents architecture decisions) and read on the operations KB (where it looks up incident history but should not be editing runbooks).

Automatic Tool Injection

When you attach a knowledge base with inject_tools: true (the default), the agent automatically receives the wiki_graph_* MCP tools scoped to that specific knowledge base. No manual tool configuration. No CLAUDE.md edits. The agent's next session starts with full read-write (or read-only) access to its knowledge base, ready to query.

The injected tools include:

• Semantic search across all pages in the knowledge base using vector embeddings
• Graph traversal to follow typed relationships (DEPENDS_ON, DOCUMENTS, SUPERSEDES, RELATED_TO)
• Page creation and updates for agents with read-write access
• Staleness detection to identify knowledge that may be outdated
• Repository ingestion to pull documentation from GitHub repos into the graph

The tools are scoped — an agent only sees tools for the knowledge bases attached to it. An agent with two KBs attached gets two sets of tools, each operating on its respective graph. There is no cross-contamination between knowledge bases, and no agent can access a KB it has not been explicitly attached to.

Why Graphs, Not Vector Stores

A vector store finds documents that sound similar to your query. A graph database finds documents that are actually connected.

When your backend agent asks "what depends on the authentication service?" a vector store returns documents that mention authentication — blog posts, meeting notes, maybe a tutorial. The Neo4j-backed knowledge base returns the six services that have explicit DEPENDS_ON relationships to the auth service, the deployment runbook that DOCUMENTS it, the architecture decision that SUPERSEDES the previous auth design, and the team that OWNS it.

Every page an agent writes makes every existing page more valuable because it creates new connections in the graph. This is the compounding effect: knowledge bases do not just grow in size, they grow in usefulness exponentially relative to their content, because graph connectivity compounds.

How It Works Under the Hood

The attachment creates an AgentKBLink record that maps an agent to a knowledge base with a specific access level. The link is persisted in Firestore for durability and also binds to the Neo4j graph space so the agent's tools are scoped correctly.

Detaching is equally simple:

DELETE /api/v1/orgs/{org_id}/agents/{role}/kb/{kb_id}

The link is removed, the tools are de-scoped, and the knowledge base continues to exist for other agents that are still attached.

Multi-Tenant Isolation

Every organization operates on its own isolated graph. Knowledge bases are scoped to organizations, and agent attachments respect those boundaries. Your engineering KB is not visible to another organization's agents — ever.

This is enforced at every layer: Firestore document paths are org-scoped, Neo4j graph spaces are tenant-isolated, and MCP tool injection validates org membership before exposing any tools. For companies in regulated industries, this is not a feature — it is a requirement.

Start Building Agent Memory

If your agents start from zero every morning, they are not accumulating institutional knowledge. They are doing the same work over and over. The Knowledge Base Attachment API changes that equation: one API call, persistent memory, compounding knowledge.

Your agents should remember everything they have ever learned. Now they can.

Get started at agent.ceo.

Related

• Upload a File, Get Instant AI Analysis — No Prompting Required — instant agent analysis on file upload