The Person Record as a Primitive

You're about to get on a call with someone you haven't spoken to in three months. You remember there was something important, a project they mentioned or a favor they asked for, something you definitely needed to follow up on. It's not in your contacts app. It might be in your notes. Maybe Slack. You open three different apps in the two minutes before the call and find nothing useful. You get on and fake it.

That's not a memory problem. That's a data model problem.

What contacts apps actually store

Your contacts app is an address book. It has been an address book since the Palm Pilot, and the core schema hasn't changed much: name, phone, email, maybe company. Apple Contacts lets you add a note field, but it's a plain text blob with no structure and no connection to anything else. Google People surfaces birthdays and job titles. That's roughly it.

These apps were designed to answer one question: how do I reach this person? Not: what do I know about this person? Not: what's the status of the thing we were working on together?

Monica is an open-source personal relationship manager that launched in 2017. It has notes per contact, interaction logs, reminders, relationship types, and a proper timeline of your history with each person. It acquired a small but devoted user base. The fact that someone built an entire separate app just to store context about people says something about how badly the default tools fail at this. Not a contacts extension. A whole application, self-hostable, actively maintained.

The reason Monica exists is that the contacts problem isn't really a contacts problem. It's a context problem.

The scattered context problem

A person isn't just an identity. A person comes with history. With open threads. With preferences you've learned over time. With tasks you owe them or they owe you. With documents and decisions connected to them.

All of that belongs to the person. But in most workflows it lives wherever the tool happened to be open at the time. Meeting notes in one app. An email thread from eight months ago with the crucial detail. A text message you remember but can't search. A sticky note from a conference that is probably in a drawer somewhere.

The closest analogy in software is a join table. You have a contact record on one side. You have a document, a task, a project on the other. The relationship between them, which is the actually useful information, has nowhere reliable to live. So it either doesn't get stored, or it gets written into a freeform notes field that no software will ever intelligently query.

When you're three minutes from a call, you're not looking for a phone number. You're looking for the join table.

What a person record should actually be

If you treat a person as a first-class entity in a knowledge base, a few things become possible that weren't before.

You can link tasks to people. Not "add a note that says talk to Kari about the contract," but a real task row with a typed relation to Kari's record, surfaced whenever you open her page or ask what's open with her.

You can see every document where she's mentioned. Not by grepping for her name across a folder, but because documents link to person records the way code links to functions. The link is structural, not textual.

You can store context in fields: how you met, her current role, what she's working on, what you promised to send. Not a text blob. Actual fields that AI tools can query without guessing from prose and occasionally getting it wrong.

The difference between an address book entry and a knowledge entity is small to describe and significant in practice. An address book entry is a lookup table for communication channels. A knowledge entity is a hub that everything else attaches to. Tasks. Notes. Projects. Interactions. That's a different thing entirely.

What makes this genuinely hard

The reason person records haven't been done well is that people are ambiguous in a specific way that tasks and projects aren't.

"Kari" in your notes might be your colleague Kari Nordmann, your dentist Kari Olsen, or the Kari from a conference three years ago whose last name you never got. Merging duplicate records after the fact is harder than it sounds, because you've accumulated context against each record separately and none of it is obviously wrong.

There's also the question of how automatic to make the creation. If you mention someone's name in a meeting note, should the system automatically create a person record? Probably not without asking. Identity is higher-stakes than task extraction. A duplicate to-do is an annoyance. A duplicate person record with conflated history is genuinely confusing and hard to untangle.

The right behavior is probably somewhere between fully manual and fully automatic: the system notices you've written about someone who doesn't have a record, surfaces a suggestion, and waits for you to confirm before creating anything. More friction than autocomplete, less friction than building the record from scratch every time.

Whether people actually maintain those records over time is the harder question, and one Monica's user base never fully solved. Most personal CRM apps fail not because the data model is wrong but because keeping it updated is a discipline most people don't sustain. The data model matters. But so does making the maintenance feel like it's worth it.

---

Asgeir Albretsen is the founder of Harbor.