Knowledge Graph

Every memory entry in Kanoniv is linked to one or more entities in the identity graph. Over time, these links form a knowledge graph: entities are nodes, memory entries are annotations, and the identity resolution engine maintains the structure as entities merge, split, and evolve.

This is not a separate graph database. It is the identity graph itself, enriched with agent-contributed knowledge.

Memory accumulates on entities

When an agent memorizes a fact about an entity, the memory is stored as an annotation on that node in the graph. Over time, entities accumulate a rich profile of agent observations:

Entity ENT_7f82 (John Doe, [email protected])
  |
  +-- [decision]       "Qualified as enterprise lead"        qualifier-agent      Mar 10
  +-- [investigation]  "VP Engineering at Acme Corp"         enrichment-agent     Mar 11
  +-- [pattern]        "Always uses personal email"          pattern-agent        Mar 12
  +-- [decision]       "Approved for enterprise pricing"     billing-agent        Mar 13
  +-- [investigation]  "Spoke at AWS re:Invent 2025"         research-agent       Mar 14
  +-- [decision]       "Synced to Salesforce"                crm-agent            Mar 15

Any agent that resolves this entity - by email, phone, name, or any other identifier - receives the full accumulated knowledge. The entity becomes a knowledge hub, not just a data record.

Merges combine knowledge

When the identity resolution engine determines that two entities are the same real-world person, it merges them. Memory follows the merge.

Before merge:

Entity ENT_7f82 ([email protected])           Entity ENT_3c91 ([email protected])
  +-- "Qualified as enterprise lead"         +-- "Personal email preference noted"
  +-- "VP Engineering at Acme Corp"          +-- "Attended webinar on March 5"

After merge:

Entity ENT_7f82 ([email protected], [email protected])
  +-- "Qualified as enterprise lead"
  +-- "VP Engineering at Acme Corp"
  +-- "Personal email preference noted"
  +-- "Attended webinar on March 5"

All four memory entries now live on the merged entity. No knowledge is lost. An agent that previously only knew about [email protected] now gets context from the [email protected] side of the graph, automatically.

This is powerful because agents do not need to anticipate merges. An agent that enriches a phone number record and stores findings contributes knowledge that becomes available to agents working with the email record - but only after the identity engine confirms they are the same person.

Pattern detection across memory

As memory accumulates on entities, patterns emerge that no single agent could detect.

Consider an entity with memory from five different agents over two months:

[decision]       "Qualified as enterprise lead"           qualifier-agent       Jan 15
[investigation]  "Budget approved for Q2"                 research-agent        Jan 20
[decision]       "Sent enterprise pricing proposal"       sales-agent           Feb 1
[pattern]        "Responds within 1 hour on weekdays"     engagement-agent      Feb 10
[decision]       "Requested custom SSO integration"       support-agent         Feb 15
[investigation]  "Evaluated competitor (Dedupe.io)"       competitive-agent     Feb 20
[decision]       "Approved for pilot program"             sales-agent           Mar 1

Each entry was written independently by a different agent. Together, they tell a story: this is a serious buyer with budget, fast response times, specific technical requirements, and competitive awareness. Any agent encountering this entity gets the full narrative without asking.

An orchestrator agent can search memory for patterns:

{
  "tool": "search_memory",
  "arguments": {
    "q": "enterprise pricing approved",
    "entry_type": "decision"
  }
}

This returns all entities where agents have recorded enterprise pricing decisions - a pipeline view built entirely from agent memory, without a separate CRM.

Institutional knowledge

Agent memory creates institutional knowledge that survives agent rotation.

In traditional systems, when an agent is retired or replaced, its context disappears. The new agent starts from scratch. In Kanoniv, the knowledge lives on the entities, not on the agent. Replace enrichment-agent-v1 with enrichment-agent-v2 and the new agent picks up exactly where the old one left off - because the memory is linked to the entities, not to the agent instance.

This is especially valuable for:

• Agent upgrades - deploy a new model version without losing accumulated context
• Horizontal scaling - spin up additional agent instances that immediately have full context
• Failover - a backup agent takes over with complete knowledge of the state
• Team changes - a new developer's agents inherit months of accumulated observations

The flywheel

Entity-linked memory creates a self-reinforcing cycle:

Agents contribute knowledge
        |
        v
Entities accumulate richer profiles
        |
        v
Agents make better-informed decisions
        |
        v
Better decisions produce better outcomes
        |
        v
Better outcomes attract more agents and use cases
        |
        v
More agents contribute more knowledge

This flywheel has a critical property: it gets more valuable with every interaction. The 1000th memory entry on an entity is more valuable than the 10th, because it builds on the context provided by the previous 999. An agent making a decision with 50 prior observations has a fundamentally different information landscape than one with 2.

Cross-entity knowledge

Memory is not limited to single entities. An entry can link to multiple entities simultaneously:

{
  "tool": "memorize",
  "arguments": {
    "entry_type": "investigation",
    "title": "Acme Corp acquisition of Widget Inc",
    "content": "Acme Corp acquired Widget Inc on March 1. Contacts from both companies should be treated as one organization for pricing purposes.",
    "entity_ids": ["ENT_7f82", "ENT_4d56", "ENT_9a3b"]
  }
}

This creates a memory entry that appears when any of the three linked entities is recalled. Cross-entity memory captures relationships, events, and context that span multiple people or organizations.

Searching the knowledge graph

The knowledge graph supports two access patterns:

Entity-first: recall

Start with an entity, get all its knowledge:

{
  "tool": "recall",
  "arguments": {
    "entity_id": "ENT_7f82"
  }
}

Knowledge-first: search

Start with a question, find relevant entities:

{
  "tool": "search_memory",
  "arguments": {
    "q": "Salesforce migration",
    "limit": 20
  }
}

Returns memory entries across all entities that mention Salesforce migration. Each entry includes its linked entity IDs, so the agent can follow up with get_entity or recall to get the full picture.

Local and cloud

The knowledge graph has two tiers:

Local (free SDK) - Memory stored in SQLite on the agent's machine. Works immediately, no signup required. Supports memorize, recall, and search for a single agent. Knowledge stays on one machine.

import kanoniv
mem = kanoniv.get_memory(agent_name="my-agent")
mem.memorize("Customer prefers annual billing", entity_fields={"email": "[email protected]"})

Cloud (Kanoniv Cloud) - Memory stored in PostgreSQL with identity resolution, row-level security, and cross-agent sharing. Knowledge persists across sessions, machines, and agent restarts. Multiple agents contribute to and read from the same knowledge graph.

from kanoniv import Client
client = Client(api_key="kn_live_...")
mem.sync(client)  # local memories resolve to canonical entities in the cloud

The upgrade path is deliberate. Start local, experience the value of entity-linked memory, then sync to cloud when you need persistence and cross-agent coordination. The API is the same. The difference is where the knowledge lives and who can access it.