Blog

AI Agent Knowledge Graphs What Goes In One and Why It Matters

When you hear that a custom AI agent has a 'knowledge graph,' the vendor is making a specific architectural claim. The agent does not just search a pile of documents; it has a structured representation of your business as entities and relationships. Customers, products, deals, vendors, contracts, playbooks - all as typed nodes with typed edges between them. This piece explains what goes into a real knowledge graph, why the pattern is showing up across every serious agent vendor, and how to tell whether a vendor has one or just a vector database with marketing on top.

Free analysis

Tell us about your business. We build the agents.

Free analysis · Human support · USA based team

Sentie Team·May 21, 2026·7 min read

Why Vector Search Alone Is Not Enough

Most AI products you have heard of run on a vector database. The pattern: ingest your documents, chunk them into pieces, embed each chunk into a high-dimensional vector, store the vectors, and at query time search for the chunks most semantically similar to the question. The technique works for question-answering over documents and is the engine behind most retrieval-augmented generation (RAG) systems.

It is also the wrong tool for an agent that needs to act on your business.

A vector search can tell you which document mentions a customer. It cannot tell you that customer is also a vendor, has three open invoices, was referred by another customer two years ago, and his account is owned by the same sales rep who closed the original referral. Those are relationships, not text similarities. Vector search does not have relationships; a knowledge graph does.

A real custom AI agent needs to reason over the structure of your business, not just search through text about it. The knowledge graph is the layer that gives the agent that structure.

What a Knowledge Graph Actually Contains

A knowledge graph is built out of nodes (the things in your business) and edges (the relationships between them). The honest definition is mechanical, not magical.

**Typed nodes.** Every entity in your business gets a type. A customer is a Customer node. A product is a Product node. A deal is a Deal node. A vendor is a Vendor node. A playbook is a Playbook node. Each node holds the attributes specific to its type: a Customer has a name and an email and an account-owner; a Deal has a stage and an amount and an expected close date.

**Typed edges.** Every relationship between nodes gets a type too. A Customer purchased a Product. A Deal involves a Customer. A Customer was referred-by another Customer. A Deal is owned-by a SalesRep. The edge types are as important as the node types because they let the agent reason about how things connect.

**Attributes on both.** Nodes have properties; edges can too. The 'purchased' edge between a Customer and a Product can hold the purchase date, the amount, and the channel. The 'referred-by' edge can hold the date and the referral-source attribution.

**Time as a first-class dimension.** A serious knowledge graph tracks how the data changed over time, not just the current state. The agent can ask 'when did this customer last engage' and get a real answer.

**Documents as referenced context, not as the graph itself.** A modern knowledge graph references the document store (which still uses vector search for retrieval over unstructured text) rather than replacing it. Both layers exist; they answer different questions.

Why Every Serious Agent Vendor Is Building One

The knowledge graph pattern has shown up independently across the most-watched custom AI agent products of 2025-2026:

- **Sentie's Business Brain** uses a per-tenant knowledge graph as the substrate every agent reads from - **Garry Tan's GBrain** (open-sourced 2025) explicitly mentions a knowledge graph plus Minions job queue plus hybrid search - **Knowlee** markets 'The Brain' - their Neo4j-backed enterprise knowledge graph - **SAP AI Foundation** ships a neuro-symbolic knowledge graph with 452,000 tables - **Glean's** entire substrate is a per-tenant knowledge graph over the customer's enterprise tools - **Anthropic's Skills + Managed Agents** assume structured per-tenant context (the graph layer is implicit but real)

This is convergent design. The problem of turning a foundation model into a useful operator for a specific business forces the same architectural answer every time. Vendors who claim they do not need a knowledge graph either have one they have not described or are selling you a vector database with a different name.

How to Tell Whether a Vendor Actually Has One

When you are evaluating a custom AI agent vendor, ask five questions. The answers separate real knowledge graphs from rebranded vector stores.

**1. What are the node types you have configured for businesses like mine?** A real graph has named, typed nodes. The vendor should be able to enumerate them: Customer, Deal, Product, Vendor, etc. If the answer is vague ("it learns the structure from your data"), they are searching documents.

**2. What are the edge types you have configured?** Relationships matter as much as entities. "Customer purchased Product," "Deal owned-by SalesRep," "Customer referred-by Customer." If the vendor cannot describe the relationships, they do not have a graph.

**3. Can you traverse the graph in queries?** Show me a query like "find all customers in the home-services industry who have an open deal and were referred by another customer with a paid maintenance plan." Graph traversal is the unique capability; if the vendor cannot demo a multi-hop query, they have something else.

**4. How does the graph stay current?** A graph is only useful if it reflects the current state of your business. Real-time sync from your CRM, helpdesk, and accounting systems; change-event tracking; deduplication. Static-snapshot graphs go stale within weeks.

**5. Is the graph mine?** Can I export the graph contents? Can I see the schema? Can I edit a node or an edge directly? A real knowledge graph is the customer's data; the vendor operates on it. Closed graphs you cannot export create lock-in by obscurity.

What Sentie's Business Brain Holds (Worked Example)

For an HVAC contractor that becomes a Sentie customer, the Business Brain knowledge graph typically contains:

**Node types**: Customer (household or commercial), Property (with address, equipment, age), Equipment (make/model/installation date), MaintenanceAgreement (active/expiring), Quote (open/closed), Job (scheduled/in-progress/completed), Technician (skills/certifications/schedule), Part (in-truck inventory), Vendor (parts suppliers), Communication (calls/emails/SMS exchanged with customer).

**Edge types**: Customer owns-Property, Property has-Equipment, Customer has-MaintenanceAgreement, Quote belongs-to-Customer, Quote covers-Equipment, Job assigned-to-Technician, Job uses-Part, Part sourced-from-Vendor, Customer was-referred-by-Customer, Customer received-Communication.

With this structure, the dispatch agent can answer: 'which technicians within 15 miles of this no-cool emergency have heat-pump certification and a likely-needed compressor on the truck?' That is a six-hop graph traversal that a vector search cannot execute. The same graph lets the quote-follow-up agent identify: 'which open quotes are for customers whose existing equipment is past warranty and who have a maintenance agreement expiring soon?'

The graph is what makes a Sentie HVAC agent feel like an operator who actually knows your business, not a chatbot that has read your manuals.

Knowledge Graphs vs Other Substrate Components

A knowledge graph is one component of the [Business Brain](/blog/what-is-a-business-brain) substrate. It sits alongside:

- **Skills registry** - the catalog of actions the agent can take, distinct from the entities it acts on - **Memory layer** - the persistent per-tenant context (what the agent has tried, what worked) - **Hybrid retrieval** - the combination of vector search + keyword search + graph traversal; ensembles win over single-method retrieval - **Model routing** - which foundation model handles which task - **Durable job queue** - for long-running multi-step workflows - **Constitution file** - the plain-text spec defining rules and tone

The knowledge graph is the structured-data layer. The other components handle execution, learning, and governance. A serious substrate has all of them; vendors that only have the graph or only have skills are missing pieces.

For the full architectural picture, see [What Is a Business Brain](/blog/what-is-a-business-brain).

The Practical Test

Next time a vendor pitches you a custom AI agent, ask them to draw the knowledge graph for a customer in your industry. Boxes for the node types, arrows for the edge types. If they can do it on a whiteboard, they have one. If they pivot to talking about vectors, embeddings, and semantic search, they have a document store with marketing on top.

At Sentie, the free assessment includes a sketch of what the Business Brain knowledge graph would hold for your specific business. Your dedicated [Success Manager](/about) walks through the entity types, the relationship types, and the data sources during the discovery call. The graph is built before any agent ships.

[Start the free assessment](/onboarding) to see what your Business Brain knowledge graph would actually contain.

// faq

Questions, answered.

Ready to start your
AI transformation?

Get a custom AI analysis in under 5 minutes.