Before your last meeting with someone important, did you open your company's CRM?
Probably not. You scrolled through the chat history.
A sales CRM is good at answering, "Where is this customer in the pipeline?" It is often worse at answering, "Where did I leave things with this person?"
AI-era CRM should handle both. Adding a chat box to the existing interface is not enough. The system has to preserve relationship context: how two people met, what changed, what was promised, which channel works best, and what should be remembered before the next conversation.
The things that do not fit in fields
Try putting these into a conventional CRM:
He recently got divorced and does not want to discuss it.
His daughter takes the gaokao next year, and he is anxious.
He dislikes phone calls. Send a text instead.
Last time we spoke, he was interested in the book I recommended.
Which fields should hold them?
Usually they end up in Notes: the unstructured box that every CRM provides and few people read carefully later.
The structured record keeps the name, employer, title, email address, last-contact date, and deal value. Those fields are useful for a sales organization. They are less useful five minutes before a conversation. The title is on LinkedIn. The email is in an address book. What you need is context: what changed, where the last conversation stopped, and what deserves care this time.
Fields were a historical compromise
This was not careless design. When CRMs emerged, structure was the practical choice.
Databases needed schemas, and lists had to be scannable. To find everyone in manufacturing, based in Shanghai, with no contact in three months, a system needed columns for industry, city, and date. Each person became a row.
That compression was useful, but it was lossy. The first information to disappear was whatever could not be classified in advance.
For decades, there was no good alternative. Teams could store free-form meeting notes, but retrieving one relevant sentence from hundreds of thousands of words was difficult. Unstructured text was easy to write and hard to reuse.
Fields were not the ideal representation of a relationship. They were a reasonable design under a technical constraint.
That constraint is disappearing
Large language models make natural-language records readable by machines.
Consider this note:
He said his company was making layoffs. He thinks his job is safe, but his mood seemed off.
This is more than a bag of searchable keywords. A model can distinguish the background event from his personal situation, preserve the uncertainty, and surface the note before the next meeting.
That suggests a different architecture: record the observation in natural language, then derive structure when it is read.
If a user wants to filter people by industry, extract industry at query time. If they want a meeting brief, retrieve recent changes, previous topics, and communication preferences. The person writing the first note should not have to predict which facet will matter three years later.
This does not mean schemas disappear. Stable IDs, dates, entity types, and explicit participants still matter. The shift is narrower: do not force every human detail into a fixed taxonomy merely so a machine can read it.
A person is not a static contact card
One person can be your former colleague, current customer, friend's spouse, and an investor in your side project.
The relevant role changes with the situation. During a contract renewal, "customer" comes forward. At dinner with friends, it recedes. Real roles overlap and evolve, and no schema designer will anticipate every category, including something as specific as "my cousin's landlord."
People change too. When someone changes employers, overwriting the old company removes useful history. Six months without contact is itself information. A communication pattern that has cooled may matter more than the current value of a job-title field.
Identity is just as untidy. Is Zhang San in WeChat the same person as San Zhang on LinkedIn, 张叁 on a business card, or the person represented only by a phone number? An email address or phone number is something a person holds for a period of time. It is not the person. Identifiers can change, be shared, or be reassigned.
A reliable system should not silently turn uncertain evidence into a confident identity merge.
If it finds two people named Zhang Wei, an agent can answer:
I found two matches: a colleague from 2019 and a photographer you met last month. Which one do you mean?
That admission of uncertainty is useful. A mistaken merge may produce no error at all, while every future note quietly attaches to the wrong person.
What guanxi adds to the conversation
The open-source project behind this idea is called guanxi-crm, so the name needs some explanation.
The Chinese word guanxi (关系) is often translated as "connections" or "networking." Both translations are incomplete. Depending on context, it can refer to a relationship shaped over time by shared history, trust, social roles, favors, obligations, and an understanding of what each person can reasonably ask of the other.
That does not make Chinese relationships mysterious or uniquely transactional. Every culture distinguishes a contact from a person who has shown up for you repeatedly. The useful part of the Chinese term is that it makes accumulated relational context hard to ignore.
This is also why guanxi should not be reduced to "who can help me." The important memory may be that someone once made an introduction for you. It may also be that you promised to send a document, that their parent has been ill, or that a subject is better left alone. Reciprocity includes care and responsibility, not only access.
A contact database captures identifiers. Relationship memory has to preserve context, change, trust, and boundaries.
What changes when CRM is designed for agents
Traditional CRM and agent CRM do not have to compete. Sales and customer success still need accounts, opportunities, activities, and stages. An agent-native system adds another layer: the person and the context behind the workflow.
| Traditional CRM is good at | An agent CRM should also do |
|---|---|
| Tracking accounts, opportunities, activities, and stages | Preserving the conversations, promises, preferences, introductions, and history behind them |
| Collecting data through forms, imports, and integrations | Extracting facts from conversations and events while retaining readable source context |
| Using a primary email or contact record as identity | Supporting multiple, shared, and changing identifiers, and stopping when a match is ambiguous |
| Recalling work through timelines, dashboards, tasks, and pipeline views | Producing a pre-meeting brief with recent interactions, forgotten details, referrals, and explicit follow-ups |
| Adding AI on top of an existing UI and schema | Giving agents native interfaces such as CLI, JSON, authoritative IDs, and documented recovery paths |
| Requiring people to use the CRM application | Letting people inspect the same memory through an agent, CLI, Obsidian, or Markdown files |
The last two rows matter more than they first appear. An agent interface is not simply an API that returns success or failure. When an identity operation fails, the error has to provide candidates and a safe next action. Otherwise the agent may route around the guardrail and invent an ID from a filename or a fragment of context.
This leads to two useful asymmetries.
Incomplete information should be accepted. A note such as "someone I met at a conference, works in supply chain, surname may be Wang" is worth saving. A rigid form may reject it because required fields are missing. Worse, an agent asked to complete the form may invent values just to pass validation.
Identity ambiguity, however, should fail loudly. Missing information can be completed later. A wrong identity merge quietly corrupts every record that follows.
The same discipline applies to inference. Facts such as contact recency and frequency can be computed. A person's "importance" or "value" should not be.
We banned scores for people
While designing the system, we adopted a product rule: no importance, priority, or value score on a person, and no leaderboard of "best contacts."
The reason is partly ethical and partly practical. Once a tool asks users to judge whether someone is useful, the records start filling with titles, employers, influence, and access. The ordinary details that create genuine context disappear. The resulting data becomes less human and, eventually, less useful.
Sorting by observed facts is different. It can be reasonable to ask who has not been contacted recently or which relationships have frequent interactions. Those answers describe the record. They do not claim to measure a human being's worth.
Relationship memory also contains highly sensitive information: family events, health concerns, job changes, private conversations. Making prose machine-readable increases the need for user control. The data should be portable, inspectable, and stored with deliberate privacy boundaries.
An implementation: Markdown as truth, SQLite as recall
guanxi-crm is an open-source, local-first relationship-memory CLI built around these constraints.
Its authoritative data lives in UTF-8 Markdown files. SQLite is a disposable recall index that can be rebuilt from those files. People have stable IDs, while names, aliases, email addresses, and phone numbers remain identity evidence rather than primary keys. Shared identifiers and duplicate names are allowed to remain ambiguous instead of being silently resolved.
Interactions are separate, dated records. Their participants must be explicit; mentions in free-form text do not automatically become participants. A sensitive marker can keep a line in the source while excluding it from ordinary briefs. The repository also ships a relationship-memory Skill that tells an agent to resolve authoritative IDs before writing and to stop for clarification when identity is ambiguous.
The current project is deliberately modest: a single-user, offline, headless CLI with no application server or dedicated graphical UI. People can still open the vault directly in Obsidian to browse Markdown, backlinks, and its graph view. The system provides a trustworthy memory layer that an agent can query; it does not pretend to infer an entire social world from a contact list.
For people who prefer a ready-to-use version rather than installing the CLI and Skill, the Personal Relationship Management Agent on ClawMama packages the workflow into an Agent that can be used directly.
One useful test
Many CRM fields were designed for a world in which machines could not read human language.
That world is changing. We can now preserve relationships closer to the way people actually remember them: not only "name, company, title, deal value," but "his daughter's exam is next year," "he prefers text," and "he wanted to discuss that book again."
A relationship-memory system does not need a grand metric. One question is enough:
Two months from now, before you meet someone, can it surface one thing you had forgotten but should remember?
If it cannot, it is still just a better address book.
Top comments (0)