Ingests what is true today
PF1 converts your content, and data from systems such as your CRM, into nodes and edges.
How the pf1
knowledge graph works
A technical overview of the knowledge graph that every PF1 agent reads from and writes to.
The PF1 knowledge graph is the data model that every PF1 agent shares. It stores your company's knowledge, your accounts and deals, and what your buyers and team do, as nodes and edges.
A node can be a buyer, an account, a deal, a call, a decision or something your content tells buyers, such as "We store all customer data in the EU." An edge connects two nodes and describes how they relate. For example, an edge can show that a buyer read a piece of content or that a deal ended in a win.
Records every signal and decision
PF1 records what buyers read, ask and share, and what your team decides, with the time and the reason.
Improves with every interaction
PF1 uses each buyer response and each deal outcome to rank what agents retrieve next.
Drives every agent’s work
Briefs, pages, answers and coaching come from the same graph, so they do not contradict each other.
Data model
Nodes and edges carry properties. The diagram shows the main node types and how they connect. Each knowledge node records its source: approved content or a conversation. If a rep says "eight weeks" on a call and your approved content says "six weeks", the graph shows the difference.
PF1 ingests new data the moment it arrives and converts it into nodes and edges. New data includes an uploaded document, a CRM change, a recorded call, a buyer opening something you sent, and a rep's decision. Systems such as your CRM, call recorder and email send part of this data, and activity inside PF1 creates the rest.
How PF1 builds the graph
pf1 turns company knowledge into nodes in the graph
pf1 records what your team knows, including what nobody has written down. It reads each document, deck, page and call, and creates a knowledge node for each thing it tells a buyer, such as where you host data or how long deployment takes, linked to its source section and version.
pf1 matches people and accounts across systems
One person can appear as an anonymous visitor, a CRM contact, an email sender and a speaker on a call. PF1 merges these records into one person node. When an anonymous visitor fills in a form, PF1 moves their earlier activity to the named person.
pf1 links buyer activity to what the buyer read
PF1 delivers your content to buyers, so it records their activity as it happens. It records views, time on each section, return visits, downloads, forwards, new people on the deal, deal room uploads, gated-page form submissions and each buyer’s path from anonymous visitor to named contact.
pf1 records decisions with the reason and the deal state
PF1 records decisions that people make on calls and in emails, such as an approved discount, an exception or a commitment. Each decision node stores who decided, the reason and the deal state at that time.
pf1 compares new versions with old versions
When an asset changes, PF1 marks each changed knowledge node as superseded and links the old node to the new one. Agents can see the current version and the version each buyer read.
pf1 links outcomes back to the deal
When a deal closes, PF1 links the outcome to every knowledge node, interaction and decision in it, and tracks how each performs in won and lost deals.
pf1 embeds knowledge and questions
PF1 embeds each knowledge node and buyer question. An embedding is a list of numbers that represents the meaning of a text, so “Where is our data hosted?” sits close to “We store all customer data in the EU” although the two share almost no words.
Why the work
happens at ingestion
pf1 works out these relationships once, when data arrives, so agents do not have to search for them at query time. It follows existing links from a buyer to what they read, the question it answered, the decision on the call and the outcome of similar deals. Each request stays small, because the agent receives a few knowledge nodes instead of dozens of overlapping passages. Smaller requests cost less and give the model fewer wrong passages to choose from.
Compared with search over documents (RAG)
The common way to give AI access to company data is retrieval-augmented generation (RAG). A RAG system splits documents into chunks, embeds them, stores them in a vector database and retrieves the closest ones for each question. Good RAG systems add filters and re-ranking. This works for questions about what a document says, but not for questions about people, deals and history.
What should I send Marcus before Thursday?
Retrieval over chunks
What should I send Marcus before Thursday?
- Security overview v5:"We store all customer data in the EU, in Frankfurt and Dublin."similarity 0.84
- Security overview v4:"We store all customer data in the EU, in Frankfurt."similarity 0.83
- SSO guide,"PF1 supports SSO via SAML 2.0."similarity 0.61
Traversal over the graph
What should I send Marcus before Thursday?
- Marcus —read→ the v4 residency section, since changed
- Marcus —forwarded_to→ Anika, Compliance
- Sam agreed a residency addendum on the call (reason: regulator)
- A similar won deal sent the EU rollout story
Send Marcus and Anika the updated residency information, the addendum and the EU rollout story.
One deal,
end to end
This example follows one deal from the first visit to the next deal it informs. The left column shows what your team sees. The right column shows what PF1 writes. The names are fictional.
An anonymous visit
/ What the team sees
An unidentified visitor spent 6 minutes on Data residency in the Security overview
PF1 identifies the visitor
/ What the team sees
Marcus Lee, IT lead, Halbrook. His record includes his earlier reading.
Discovery call
/ What the team sees
Marcus asked about data residency and SSO, and mentioned a competitor.
Decision: Sam agreed to a data residency addendum. Reason: Halbrook's regulator requires EU processing in writing.
An agent prepares the follow-up
/ What the team sees
Draft for Sam
We store all customer data in the EU[Security overview v4]
SSO one-pager[SSO guide]
[Anchor][Traverse][Constrain][Rank][Pack]
The rep changes it
/ What the team sees
Sam edited the draft
SSO one-pager → Customer story: EU rollout
Reason: "Marcus said compliance signs off, not IT."
A new stakeholder appears
/ What the team sees
New person on the deal
Anika Rao, Compliance. Never on a call. Read the customer story twice
Your residency information changes
/ What the team sees
For Sam
What you say about data residency has changed. Marcus and Anika read the old version.
Brief before Thursday's call
/ What the team sees
Meeting brief · Halbrook
- Data residency remains open. The addendum is unsent.
- Invite Anika from compliance to the call.
- Marcus and Anika saw outdated residency information.
- Similar won deals had a compliance review before pricing.
The deal closes
/ What the team sees
CRM
Halbrook · Closed won
The next deal
/ What the team sees
Draft for a new deal, same segment, same competitor
Lead with the current residency information and the EU rollout story. Offer the addendum early.
Across every deal
These three questions need data from many deals. Each example shows the question, the path the graph follows and the result.
How do we win
against [competitor] in enterprise healthcare?
Follows
- Deals where buyers mentioned that competitorSegment: enterprise healthcare
- Questions raised, what reps sent and said, decisions madeoutcome
Returns
The questions, content and decisions that appear in won deals but not in lost ones, with links to each deal and source.
What shows up in deals we win at this stage but not in deals we lose?
Follows
- Deals at that stagecontent read, questions raised, decisions made, people involved
- outcomegrouped by segment
Returns
The content, answers and actions that appear more often in won deals, such as a compliance review before pricing. Marketing uses this to choose what to lead with, and enablement to choose what to train.
How do our top reps handle the security objection?
Follows
- Security questions from buyersthe calls where buyers asked them
- what each rep said and sent in responseoutcome, grouped by rep
Returns
How the reps whose deals close answer it, checked against approved content, so any rep or agent can give the same answer.
What makes the PF1 knowledge graph different
A competitor could copy any one of these features. The combined record is different. PF1 must capture it as events happen, and nobody can reconstruct it afterwards. It starts on the day you connect PF1 and grows with each deal. Any system can read your existing decks, documents, call recordings and CRM history. The PF1 graph links that material to the buyers who read it, the decisions around it and the deals it appeared in.
Buyer activity links to knowledge node
The graph records that Marcus read version 4 of what you say about EU data residency. A file-tracking tool records only that he opened a PDF.
Decisions include the reason and the deal state
Agents can see what your team decided, why, and what the deal looked like at that time.
Outcomes change ranking
PF1 links every knowledge node, decision and interaction to the outcome of the deal, which changes what agents return next.
Buyer activity links to knowledge node
The graph records that Marcus read version 4 of what you say about EU data residency. A file-tracking tool records only that he opened a PDF.
Provenance and scope
A competitor could copy any one of these features. The combined record is different. PF1 must capture it as events happen, and nobody can reconstruct it afterwards. It starts on the day you connect PF1 and grows with each deal.
Any system can read your existing decks, documents, call recordings and CRM history. The PF1 graph links that material to the buyers who read it, the decisions around it and the deals it appeared in.
Provenance
Each knowledge node links to its exact source, and each agent output links to the nodes it used, so you can trace any answer to the call, email, section or version it came from.
- Answer in the draft email
- "We store all customer data in the EU"
- Security overview v5, section 3
Approved knowledge
PF1 stores approved content, knowledge from conversations and agent observations separately, each with its source. An agent can record that buyers in a segment keep asking the same question, but it cannot change what your company says.
- Approved content
- Said in conversation
- Agent observations
Scope
PF1 limits every query to your account before it traverses or ranks anything. An agent working on a deal reads only that deal's subgraph unless it explicitly requests precedent from other deals
Your account
This deal