Architecture
The source systems hold the facts. Coby holds the context between them.
A customer context graph gives product teams and AI agents a shared, persistent model of users, accounts, product areas, evidence, decisions, and time—without pretending one new database should replace every source of record.
Last reviewed
The system in one view
The graph is not a prettier copy of each tool. It is the maintained connective layer needed to ask questions that cross them.
Scoped sources → identity + product resolution → evidence graph → teams and AI agents
analytics · support · CRM · billing · roadmap · code · decisions
↑ corrections, decisions, and outcomes update the shared context ↑
analytics · support · CRM · billing · roadmap · code · decisions
↑ corrections, decisions, and outcomes update the shared context ↑
Four responsibilities, kept separate
Sources of record
PostHog, Amplitude, a CRM, billing, support, Linear, GitHub, and other systems remain authoritative for their own live objects and metrics.
Identity and semantics
Coby maintains which identifiers refer to the same person or account and how product areas, owners, definitions, and decisions relate.
Evidence and history
Important claims retain source links and time. Corrections and superseded facts become part of the record instead of disappearing into the next prompt.
Decision-time context
The right subset is served to the product team or its AI agent for the question at hand, with gaps and uncertainty made visible.
Identity resolution is the join
A person may be an email in support, a UUID in analytics, a contact in CRM, and a member of a billing account. Those records do not become customer intelligence until the match is maintained and auditable.
| Without a maintained identity layer | With identity-resolved context |
|---|---|
| Each query tries to infer the join again. | Known mappings persist and can be corrected once for future investigations. |
| Similar names or shared domains create plausible false matches. | Matches retain the identifiers and evidence used, with uncertainty when proof is insufficient. |
| User-level behavior and account-level value remain disconnected. | A user can be placed in the right account, segment, lifecycle, and product history when sources support it. |
| Feedback clusters count messages, not resolved customers. | The team can distinguish repeated messages, unique people, accounts, and affected segments. |
How context is prepared for an agent
Route to the canonical source when the question is live and narrow
An open issue list should come from the issue tracker. A current subscription should come from billing. Coby does not need to replace direct access.Use the graph when the question crosses systems or time
Investigations involving users, accounts, evidence, prior decisions, and outcomes require context that no single vendor API owns.Retrieve only the context needed for the task
The agent receives relevant entities, definitions, evidence, and history instead of an indiscriminate dump of every connected source.Return provenance and uncertainty with the answer
A result should show what it used, how much it covered, what contradicted the conclusion, and which source could not be checked.Preserve verified corrections and outcomes
Human corrections, the eventual decision, and what happened afterward become reusable context rather than feedback lost in a chat transcript.
Context graph, RAG, and semantic layer are different jobs
| Approach | Primary job | What it does not solve alone |
|---|---|---|
| RAG or enterprise search | Retrieve relevant documents or passages. | Exhaustive coverage, deterministic identity joins, current-vs-superseded facts, and product-specific ownership. |
| Warehouse or semantic layer | Define governed metrics and analytical models. | Qualitative evidence, conversations, decision history, code and roadmap context, and narrative provenance. |
| Customer context graph | Maintain connected entities, evidence, definitions, history, and product relationships for investigations. | The canonical live state and specialized calculations that should remain in source systems. |
Security is part of the architecture
Sources, scopes, storage, retention, deployment, model providers, and human access must be explicit. They cannot be inferred from an architecture diagram.
Read Coby's current security and data-handling page for the detailed flow, hosting, encryption, access controls, subprocessors, deletion, and incident process. Client-specific terms are documented in the engagement and Data Processing Agreement.
Frequently asked questions
Does Coby query every connected system live?
No. Coby processes agreed source data into a structured product brain so identity, definitions, provenance, and history persist between questions. Source systems remain canonical, and source-direct queries can still be used when the freshest live state matters.
Is Coby just RAG over company documents?
No. Retrieval is one capability. The differentiating work is resolving shared entities, encoding product and customer semantics, preserving time and provenance, and connecting an investigation to prior decisions and later outcomes.
Does Coby replace a warehouse or semantic layer?
No. Warehouses and semantic layers remain appropriate for canonical metrics and governed analytical models. Coby connects those facts with qualitative evidence, product structure, and decision history at investigation time.
How is access scoped?
Each engagement defines the sources, credentials, fields, retention, and deployment model. Coby uses read-only or scoped access and documents the resulting data flow in the agreement and Data Processing Agreement.
Bring one difficult product question.
We will show which sources Coby used, how much evidence it covered, what it could not establish, and where a human still needs to decide.
Test a question with Coby