Customer Context Graph

The customer context graph is Outlit’s unified data model. It connects every customer interaction — website visits, product usage, billing events, support conversations — into a structured graph of entities and relationships. Instead of customer data scattered across Stripe, PostHog, your app database, and email, the graph gives you (and your AI agents) one place to query the complete picture.

​

What is the customer context graph?

The customer context graph is a structured representation of everything Outlit knows about your customers. It has four layers:

1. Entities — The people and companies you do business with: anonymous visitors, known contacts, customer accounts, and devices
2. Relationships — How entities connect: identity resolution links, account membership, cross-device associations
3. Activity timeline — A chronological log of every interaction from every source: pageviews, form submissions, Stripe charges, Slack messages, email threads, call transcripts
4. Facts — Temporal assertions about each customer that capture what it means, not just what happened: churn risk signals, expansion opportunities, competitive evaluations, champion changes, and more

​

How does Outlit build the graph?

Outlit builds the customer context graph in four stages:

​

1. Collect

Data flows in from multiple sources:

​

2. Resolve

Identity resolution links activity to real people. When a visitor submits a form, signs up, or logs in, Outlit connects their anonymous browsing history to their profile. The same person on different devices gets merged into one contact.

​

3. Connect

Entities form relationships:

• Visitors → Contacts: Via identity resolution (email, userId, device fingerprint)
• Contacts → Accounts: Via email domain matching and explicit association
• Accounts → Billing: Via Stripe integration or manual status updates

Each contact carries a journey stage (Discovered → Signed Up → Activated → Engaged → Inactive) and each account carries a billing status (None → Trialing → Paying → Churned).

​

4. Query

The graph is queryable through multiple interfaces:

• CLI — outlit customers list, outlit search "...", outlit sql "..."
• MCP — AI agents query customer context directly in Cursor, Claude Code, VS Code
• API — Programmatic access for custom integrations

​

What makes this different from a CRM or analytics tool?

Traditional tools capture one slice of the customer relationship: Outlit’s graph connects all of these — and goes further with facts. Instead of just showing raw data, a query like outlit customers get acme.com --include timeline,facts shows the complete story with reasoning: which pages Acme’s team viewed before signing up, how they used the product after onboarding, what their billing trajectory looks like, and what it all means — churn risk signals, expansion opportunities, champion changes, and competitive context.

​

How do facts work?

Facts are temporal assertions that Outlit maintains about each customer. While the activity timeline records what happened, facts capture what it means — the reasoning layer that makes the graph intelligent. Outlit generates facts from three sources: Every fact has temporal validity — it knows when it became true and when it stops being relevant. As new activity flows into the graph, facts are automatically validated or invalidated. A “contract renews in March” fact expires after March. A “customer is evaluating competitors” fact gets resolved when they renew. This means the graph always reflects the current state of each customer relationship, not stale snapshots. Facts are queryable through the same interfaces as the rest of the graph — CLI, MCP, and API.

​

How do journey stages fit into the graph?

Journey stages are properties on graph nodes — structured labels that Outlit maintains as contacts and accounts progress:

• Contact journey stages (Discovered, Signed Up, Activated, Engaged, Inactive) describe where each person is in their product engagement
• Account billing statuses (None, Trialing, Paying, Churned) describe the commercial relationship

Some stages are inferred automatically from integrations. The Outlit browser SDK auto-detects Discovered and Signed Up based on the identifiers provided. Engaged and Inactive are auto-inferred from product activity via PostHog or your SDK (browser or server). Activated is the one stage you instrument manually — since the definition of “activated” is specific to your product, you call user.activate() when a contact completes your onboarding or key milestone. Billing statuses update automatically when Stripe is connected. For full details, see Customer Journey.

---

​

Frequently Asked Questions

---

​

Next Steps