Contacts should build themselves

Think about the last time you needed to reach someone you’d talked to a few months earlier. You probably didn’t open your address book. You searched your inbox for their name, found a thread, and replied to it, because the thread was the only place their address was guaranteed to be current.

That’s a strange thing to admit about a piece of software every operating system has shipped for forty years. The address book didn’t fail because the idea was wrong. It failed because keeping it current was your job, and a stale entry looks exactly like a good one until you use it. You find out the address is dead when the mail bounces, which is late enough that you stop trusting the list and go back to searching your inbox.

One person, four handles

There’s a second problem stacked on top of the first. Your address book was designed for a world where a person had one address. Now the person you’re trying to reach has an email address at work, a different one they use for invoices, a Slack handle in a shared channel, a phone number you got at a conference, and a Teams account at the client you’re both working for. None of those know about each other.

So the record fragments. Google Contacts has one version, harvested from Gmail. Slack has another that’s really just a workspace member. Your phone has a third with the mobile number and nothing else. Each is partially right, and reconciling them is exactly the sort of tedious work people never get around to.

What we built

There’s a Contacts section in this+that now, and the thing worth saying about it is what you don’t do: you don’t fill it in.

It assembles itself from the channels you’ve already connected. Google Contacts, Outlook, Slack, Google Chat, Teams, and the teammates in your this+that account all feed it. When the same person shows up from two places, we resolve them into one record with both origins attached, so the Slack handle and the work email land on the same human instead of two half-people. Anything the sync gets wrong, you can merge by hand.

The part we spent the most care on is what happens when you edit something. Fix a job title that’s two roles out of date and the next sync won’t overwrite it. Delete an email address that person stopped using and it doesn’t reappear an hour later. Every sync-backed address book we’ve used gets this wrong, and getting it wrong is what teaches people to stop editing.

The history is the point

Open a person and you see your correspondence with them: the emails and the messages, across channels, in order, with who wrote to whom.

You didn’t file any of that. As mail and messages arrive, they attach themselves to the people involved. So the record isn’t a card with a phone number on it. It’s the answer to “what’s my history with this person,” which is the actual question you had when you went looking for them.

That answer has been sitting in your accounts the whole time, spread across four apps that each hold a slice and none of which will show you the whole thing. Assembling it is not clever. It’s just work nobody had done.

You can share a person with your team, which is where this beats a personal address book. When somebody goes on vacation or hands off an account, the teammate picking it up gets the record: every address that person actually uses, the phone number that works, the job title that’s current, and the notes their colleague kept on them.

What they don’t get is your inbox. The activity on a shared contact is read from the viewer’s own mail, so a teammate sees their history with that person and never yours. Your side of the correspondence stays private even when the contact is shared, which is the boundary you’d want the moment you think about what’s in your DMs.

What it is not

We’re not building Salesforce. There are no deals here, no pipeline stages, no forecast, no close dates. Your systems of record keep their job, and the structured fields stay in them.

Think of it as what Google Contacts would be if it kept itself current and remembered your conversations. That’s the whole ambition. It’s a directory of the people you actually talk to, which sounds modest until you notice you don’t have one.

A new contact can start something

A directory you have to remember to open is worth less than one that acts. So a person arriving is a trigger: a workflow can run the moment someone is created, whether you typed them in or a sync brought them over.

What it does from there is up to you. It can write a page in the Brain for that person or their account, which turns a new name into a place your team keeps what it knows. It can push the record into Salesforce or HubSpot through a connected MCP server, so the system of record gets the contact without anyone retyping it. It can share the person with a team, or append a dated note. Workflows can also search your people mid-run, and an agent step can do the same work with a record kept of anything it changed.

That last one matters more than it sounds. It means the contact list and the knowledge layer aren’t separate products you have to reconcile. A person shows up in your mail, lands in Contacts, and a workflow puts them where your team will actually look for them.

Why this slice first

The Brain rests on the same bet as Contacts: knowledge that needs a person to maintain it won’t stay current, so the maintenance has to come out of the communication a team is already producing. Contacts is the smallest version of that, running in production on the easiest slice of the problem.

It also gets past the thing every knowledge layer hits on day one, when it’s empty and somebody has to fill it before it’s worth opening. Contacts is populated the moment you connect an account, because the people were already in there. Starting from something real and letting it correct itself is a different proposition than starting blank and promising to keep it fed, and we’d rather learn that on contact records than on everything a company knows.

Contacts earns its keep the day you connect an account, before you automate anything. The list is right, the history is there, and a handoff no longer starts from zero. Workflows are where it compounds, and that’s the part we’re building out now.

Further out is a Brain that stays current without being told to, where an account page is right because your team talked to the customer and not because somebody wired up an automation for it. The people layer already works that way. The rest is in progress.

Key takeaways

• Address books go stale because they depend on maintenance, so people abandon them and search their inbox instead. The fix is a contact record that assembles itself.
• The same person arrives as an email address, a Slack handle, and a phone number that don’t reconcile. this+that resolves those into one record with every origin attached, and you can merge the rest by hand.
• Your edits survive the sync. A job title you corrected is not overwritten, and an email you deleted does not come back.
• Each person carries your correspondence with them, assembled automatically from mail and messages across channels, so the record answers “what’s my history here” and not just “what’s their number”.
• Contacts can be shared with a team, which means a handoff starts from the actual history rather than from a name.
• This is not a system of record and will not become one. No deals, no pipeline, no forecasting.
• A new contact is a workflow trigger. From there a workflow can write a Brain page for the person, push them into Salesforce or HubSpot over MCP, share them with a team, or add a dated note, and agent steps can do the same with an audit record.
• Contacts is a small proof of the bet the Brain rests on: maintenance has to come from the communication a team already produces, and a knowledge layer that arrives populated beats one that starts empty and asks to be filled. A Brain that maintains itself across everything a company knows is the larger goal.