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?"
That problem led us to build guanxi-crm, a free, open-source, local-first relationship-memory tool. It stores readable Markdown as the source of truth, uses a rebuildable SQLite index for recall, and gives AI agents a strict CLI for identity resolution and relationship history.
You can read the bilingual ClawMama Blog version, install the project from GitHub, or use the ready-to-run Personal Relationship Management Agent.
The point is not to replace sales CRM. It is to preserve the context that conventional records usually flatten: 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.
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.
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. 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 identity evidence. It is not the person.
A reliable system should not silently turn uncertain evidence into a confident identity merge. If it finds two people named Zhang Wei, it should stop and ask which one you mean. Missing information can be completed later. A wrong identity merge quietly corrupts every record that follows.
What guanxi adds to the conversation
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.
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 |
An agent interface is not simply an API that returns success or failure. When identity resolution fails, the error needs to provide candidates and a safe next action. Otherwise an agent may route around the guardrail and invent an ID.
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. Identity ambiguity, however, should fail loudly.
We banned scores for people
We adopted a product rule: no importance, priority, or value score on a person, and no leaderboard of "best contacts."
Once a tool asks users to judge whether someone is useful, records start filling with titles, employers, influence, and access. The ordinary details that create genuine context disappear. Sorting by observed facts is different. It can be reasonable to ask who has not been contacted recently. That answer describes the record. It does not claim to measure a human being's worth.
Relationship memory also contains sensitive information: family events, health concerns, job changes, private conversations. The data should be portable, inspectable, and stored with deliberate privacy boundaries.
An implementation: Markdown as truth, SQLite as recall
guanxi-crm is deliberately modest: a single-user, offline, headless CLI with no application server or dedicated graphical UI.
Its authoritative data lives in UTF-8 Markdown. 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 may 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. 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.
People can inspect the same vault directly in Obsidian, including Markdown, backlinks, and graph view. If you do not want to install the CLI and Skill yourself, ClawMama packages the workflow as a ready-to-use Personal Relationship Management Agent.
One useful test
Many CRM fields were designed for a world in which machines could not read human language. That world is changing.
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)