MAY 2026·6 min read·Build

Building Nodes: relationship intelligence for the agent era

The belief

Before software, business has always run on human relationships. In a world where AI commoditizes outreach to anyone, people stop paying attention to anything that feels generic. Trust becomes the only moat. We are coming back to human relationships, and we need agent operators that make those connections happen for us.

That is the thesis behind Nodes. A relationship layer, built for AI Agents in a world where the warm path is the only path that still works.

The infrastructure gap

Today's people data infrastructure: PDL, Clearbit, ZoomInfo, was built for a human scanning a list and filling gaps with judgment. A person looks at a name, reads some signals, and decides whether to reach out. The tool supports that decision. It does not need to be machine-readable. It just needs to be good enough for a human to act on.

Agents need something different: real-time, structured, contextual people data they can reason over, including the relationship signals (who knows whom, how strongly, through what path) that no current API exposes. A list of names and job titles is not enough. An agent trying to find the best path to a decision-maker needs to know whether anyone on the team has a real relationship with that person, how warm it is, and what the most credible introduction looks like. None of that exists in any current data product.

Whoever solves both the data engineering and the agent-readable representation owns a category of infrastructure that did not need to exist 18 months ago. That is what Nodes is building.

The missing relationship context

The reply rate on cold outreach dropped from 8.5% in 2019 to 3.5% today. That is not a targeting problem or a copywriting problem. It is an architectural one. Every tool in the market was built outside-in: start from a database of strangers, filter by title and company, drop into a sequence. They have no memory of the relationships a business already owns. They cannot find the warm path that already exists.

What they miss is not data. It is context. Specifically:

  • The relationships you already own. Every CRM and ATS is full of dormant contacts. The warm connections live scattered across email, calendar, WhatsApp, and phone contacts. No system captures them, scores them, or makes them searchable.
  • Relationship strength. LinkedIn tells you someone is a second-degree connection. It does not tell you whether that connection is worth activating, how recently they spoke, or how much that person trusts the connector.
  • The fastest warm path. Who on your team actually talks to this person, how often, how recently: these signals exist in private conversations but are completely unmapped. Finding the right connector still means a Slack blast and hoping someone remembers.
  • The introduction itself. Even when you find the right path, executing it is still manual. A good intro requires a hyper-personalized message with shared context. None of that is systematized today.

In the agent era, this problem compounds. Agents deployed for outreach, sourcing, and deal flow without relationship context are just faster spray-and-pray. For agents to operate effectively, they need structured relationship data. That infrastructure does not exist yet.

Building the MVP in one week

I did not wait for a co-founder, a design system, or a perfect architecture. I shipped a working MVP in one week. The bet: if the core value of Nodes is surfacing relationship context from data people already own, the fastest way to test it is to actually import that data and see whether the output feels useful.

The MVP solves one thing: import your contacts, surface who matters, and reconstruct the context around each relationship. If you have conversation history from Gmail or WhatsApp, it generates a relationship summary: how you met, what you talked about, why this connection is worth activating now. That is what makes it feel different from a spreadsheet. It does not just surface a name. It gives you a reason to reach out.

How it is built

The stack: React 18 + TypeScript + Vite on the frontend, Supabase for the database, auth, and edge functions, Tailwind CSS + shadcn/ui for the interface, deployed on Vercel. AI runs through OpenRouter (Gemini Flash for scoring and search) and OpenAI for embeddings. Zero to production in one week.

Here is how the pipeline works, step by step:

  • Step 1: Import. You connect your contacts from LinkedIn, Gmail, and WhatsApp. Each source is parsed and stored locally under its own key. Nothing is sent to a server at this stage.
  • Step 2: Merge and deduplicate. LinkedIn connections load first as the primary source, keyed by name. Gmail and WhatsApp contacts are then matched against them in order: by name, then email, then LinkedIn URL, then first name plus company. Reversed name formats (BONNET Vanessa = Vanessa Bonnet) are resolved. When two records refer to the same person, the richer version wins: accented names are preferred, up to four emails are kept per contact, and data from all sources is combined into one canonical record.
  • Step 3: Strength scoring. Each contact gets a percentile-based score from 0 to 100, built on four signals: multi-channel presence (40 pts), recency of last interaction (25 pts), frequency (20 pts), and bidirectionality (15 pts). Scores are relative to your own data distribution, so they reflect who matters most given what you actually have, not a universal benchmark.
  • Step 4: Embed and index. Each contact profile is embedded and stored in Supabase's vector database. This is what makes natural language search possible.
  • Step 5: AI search. When you run a search ("who do I know in climate tech in New York?"), a Gemini Flash edge function parses your intent, generates clarifying questions if the query is ambiguous, then ranks contacts using both semantic similarity and relationship strength. You get a ranked list with explanations: why this person matches, how strong the connection is, what makes them worth reaching out to now.
  • Step 6: Relationship summary. For any contact, if conversation history is available from Gmail or WhatsApp, a separate edge function reads that history and generates a short narrative on demand: how the relationship started, what you have talked about, and what context is most relevant for the outreach you have in mind. The generation runs locally. No conversation data leaves the device.

The result is a system that starts from data you already own, surfaces who matters and why, and gives you the context to reach out like you actually know the person, because you do.

← All projects