Knowledge Graph for AI Agents

A knowledge graph for AI agents gives agents a shared map of organizational objects and the evidence that connects them. Instead of treating every message, ticket, document, and database row as unrelated text, the graph resolves information around durable entities such as companies, projects, people, incidents, and decisions.

For company agents, the useful graph is not only a static set of triples. It also needs time, provenance, permissions, and a way to represent changing evidence.

What the graph adds

Suppose several systems mention the same customer:

Slack: “Acme’s CTO left last month”
Jira: incident INC-4421 affects Acme
CRM: renewal date is September 30
Gmail: the new VP asks for a security review

Text retrieval can find each item. A knowledge graph gives agents a shared organizational object — Company:Acme — around which those observations, people, projects, and decisions can be connected.

That makes questions such as “what changed with Acme?” easier to answer consistently across agents because the system does not have to rediscover the entity boundary from scratch on every query.

Knowledge graph vs vector database

These are complementary rather than mutually exclusive.

Capability	Vector retrieval	Knowledge graph
Semantic similarity	Strong	Usually combined with search/retrieval
Stable entity identity	Not inherent	Core
Explicit relationships	Weak/implicit	Core
Source provenance	Optional metadata	Can be first-class
Temporal changes	Usually external	Can be modeled directly
Multi-agent shared writes	Not inherent	Natural fit
Permission-aware organizational objects	External concern	Can be part of the model

A vector database answers “which pieces of text are similar to this query?” A knowledge graph can answer “which organizational object does this evidence belong to, how is it related to other objects, and how has that state changed?”

Production agent systems often use both. Semantic retrieval finds candidates; entity structure gives them stable organizational meaning.

Events matter as much as entities

A company is not a static graph. Projects move, people change roles, customers renew, incidents open and close, and agents take actions.

If the graph stores only the latest value, it becomes hard to answer:

when did this fact become true?
which source said it?
what did the agent know before taking an action?
was a later correction applied?

For that reason, Lobu keeps append-only events as evidence and uses entities as the shared organizational index over that evidence. Durable memory can then attach facts or summaries to the entity without discarding the underlying history.

This is closer to an event-sourced organizational graph than a static RDF-style knowledge base. See The context layer is an event store and Related systems and research.

A graph shared by several agents

The graph becomes especially valuable when agents are not all running inside the same application.

For example:

ChatGPT researches a customer and saves a durable fact
a background behavior observes new Jira events
Codex investigates a technical blocker
a support agent later asks for the current account context

Those agents can keep their own local conversation and filesystem state while converging on the same authorized organizational entities.

That is different from copying one agent’s full memory into another. The shared layer contains durable company state; each agent keeps its own working context. See Shared memory for AI agents.

Permissions are part of the graph boundary

Organizational graphs can become dangerous if ingestion strips away source permissions. A private email should not become globally readable simply because its entities were extracted into a shared index.

A production context graph therefore needs to carry access scope alongside entities and evidence. The same company can be a shared entity while individual source events remain visible only to the users or agents authorized to read them.

In Lobu, scoped identities and source permissions govern retrieval and actions over the shared organizational model.

How Lobu uses graph-like organizational state

Lobu’s model has several related primitives:

entities — typed shared objects such as companies, projects, and members
connections — configured external systems or accounts
feeds — collected, streaming, or virtual data exposed by those connections
events — append-only evidence of observations, outputs, actions, approvals, and outcomes
memory — durable facts and summaries associated with entities
behaviors — standing agents that consolidate or act on new signals
identity and policy — the scope under which an agent reads or acts

Together they form a live organizational context graph that external agents can access over Lobu MCP.

Lobu is broader than a knowledge-graph database: it also provides connectors, agent identity, approvals, credential isolation, execution, and audit. The graph is the shared context model inside that operating layer.

When a knowledge graph is useful for agents

A graph-like model is most useful when:

many sources refer to the same customers, people, or projects
several agents must converge on shared company state
relationships between entities are as important as document text
state changes over time and provenance matters
humans need to inspect or correct the shared model
retrieval must respect user and source permissions

For a single personal assistant searching one small document collection, a graph can be unnecessary structure. Plain files or ordinary retrieval may be simpler and better.