Last weekend at sim conf, Karthic from THV looked at the chat interface we were about to build and said: you're about to ship a worse version of Claude inside a tab nobody opens. Why would you do that?
I didn't have a good answer. I had a spec. Streaming, tool-call rendering, retry logic, message reordering, history virtualization, attachment handling, mobile keyboard polish, push notifications, offline state. None of it research, all of it weeks of work — quietly building a chat surface every AI startup is now building in parallel, hoping ours is the one you'll open instead of Claude or Cursor.
We went home and deleted the spec. noticed v1 ships as two things: a substrate (relationship memory, identity graph, signal layer) and an MCP server. The chat is Claude, Cursor, Codex, OpenClaw — whatever you already use. That's an engineering shortcut with a distribution payoff: we're getting reach we'd otherwise have to buy.
the five-surface trap
When you build a personal agent, the list always ends the same way: a dashboard (investors and journalists need a URL), a mobile app (people live on their phones), a Telegram bot (where founders actually talk), a Slack bot (where teams work), and a Claude / Cursor / Codex integration (where AI work happens). That's five surfaces, five backlogs, five auth flows, and five places to ship a fix every time the agent gets a sharp edge. A two-person team that takes that list seriously ships nothing for six months.
The way out is to notice that four of the five are skins on the same agent, and the fifth — the LLM client — is a surface someone else builds for you, for free, if you ship the right interface.
That interface is MCP.
MCP as a distribution channel
The framing I had wrong: I thought of MCP the way I think of a webhook or a Zapier plugin. Something you ship after the product works, so power users can wire it into the rest of their stack.
Karthic's reframe: the AI-native version of "the free product is your distribution channel" is shipping an MCP. You don't fight for tab attention. You slot into the workflow you already have open in Claude, Cursor, or Cline. The star count on the repo becomes your funnel. The MCP recommends the full agent the moment you hit a question the MCP can't answer.
The discovery loop in MCP-first is the inverse of product-led growth. Instead of pulling users to your domain, you push your product into theirs.
That distinction matters. Most of the products in our space — Happenstance, Goodword, Dex — live on the web. Each is a tab. None of them are reachable from inside Claude or Cursor today. If MCP-first works, we never have to compete with their tab. We compete inside the chat session our user is already in.
what installing actually looks like
Here's the moment I keep coming back to.
I'm in Claude Desktop with the noticed MCP installed. I type: who in my network just changed jobs this month? Four seconds later Claude comes back with three names, each with the date of the change, what I last talked to them about, and a one-line "why this might matter to you right now." Two hours later I'm in Cursor working on something else. I ask the same question. Same answer, no re-auth, no tab switch.
That moment — the same agent reachable from wherever I'm already typing — is the entire product hypothesis. The substrate does the work once. Every surface reads from it without owning a copy.
what we ship, what we get for free
We ship: Postgres + ClickHouse for the substrate, a @noticed/agent-core TypeScript package that runs the multi-tenant agent (sessions, compaction, two-tier memory, tool registry, heartbeat) on top of the Vercel AI SDK, a semantic API in front of the substrate, an MCP server exposing five tools (search_people, get_person, find_warm_path, recent_changes, add_debrief), and a web dashboard for the things that are genuinely better as UI — OAuth flows, integration toggles, browsing person cards.
We get for free: a Claude Desktop chat experience. A Cursor agent that pulls from your noticed graph while you code. A Codex CLI that can ask "who do I know at this company" from your terminal. Any future MCP client. When Anthropic ships a better chat UI next quarter, our users get it. When Cursor adds voice, our users get it.
We used the same shape at Talent Protocol a few months ago. We shipped /llms.txt for spec-driven AI crawlers, /ai.txt for per-path agent permissions, and an MCP server documenting search_profiles and get_profile. Thirteen files served from Next.js route handlers. By the end of the week Claude Desktop, Cursor, and Windsurf could all find and use the product. None of that traffic existed seven days earlier.
Ship a chat interface that holds up under real use: weeks of work, none of it research. Ship an MCP server: define a tool schema, wire it to your semantic API, return JSON. A working version is an afternoon. A good version is a few days.
The MCP server cost us about a week. A reasonable chat would have cost us a quarter. We shipped the substrate instead.
build what the host doesn't have
The MCP framing forces the question: what should your product actually be in a world where Claude already does so much?
The honest answer for noticed: the relationship memory. Claude doesn't know who you met last week, what they're working on, who in your network just changed jobs, or which of your dormant connections could open the door you need. It can't, because that context isn't anywhere it can read. Build that substrate, expose it as MCP, and Claude becomes a much sharper agent the moment yours is installed.
Intelligence is getting cheap, fast. Relationships aren't. Every model gets better at reasoning, writing, summarizing, planning. None of them get better at remembering the people in your orbit. That's the layer humans rely on most for warm intros, and it's the layer AI agents are most obviously missing.
The rule of thumb: build what the host can't, and ship it as a tool the host can call.
We could be wrong about a few things. If Anthropic ships a first-party relationship-memory feature next quarter, the substrate we're building gets a much harder competitor overnight. If MCP itself doesn't get adoption beyond technical users, the funnel we're betting on stays small. We've made peace with both risks because the upside — being installed inside every agent that ships after us — is bigger than the downside of building Yet Another Chat alongside fifty other companies.
what we give up
Three things.
Brand surface. When you talk to noticed inside Claude, you're inside Claude. You don't see our logo, our typography, our voice. The interaction quality is ours; the chrome belongs to the host. We accept it because you're already there, and pulling you somewhere else to see our chrome is friction we can't justify yet.
Onboarding control. If you only have a few seconds to teach someone new what your agent does, doing it inside someone else's client is harder. Our dashboard carries the first-run experience. The MCP path assumes you're already comfortable with your LLM client.
One opinionated chat. Eventually there will be a noticed chat — when there's an interaction we can't express in any host client, or when the agent needs to be proactive in a way MCP doesn't model well (heartbeats, ambient nudges, async surfaces). We'll ship it once the substrate is great.
the longer bet
Two layers underneath everything above.
First: the agent surface keeps moving. Every product needed a website, then an app, then a chatbot. The next layer is the agent — your agent — a surface we plug into rather than build. Products that ship as MCP servers will be reachable by every agent that gets shipped after them. Products that ship as standalone chats will keep rebuilding the same UI forever.
Second: the long-term shape of noticed is your agent calls my agent. The current paradigm of humans interrupting other humans is ending — when AI agents flood every inbox, the only signal left is a trusted intro. The most interesting noticed queries are two-sided ones ("draft a warm intro between me and the right person on Maria's side"), well beyond the read-only "who do I know at Anthropic" shape. For that to work, agents have to talk to other agents over a stable protocol. MCP is the closest thing we have to that protocol today, and shipping our surface as MCP from day one means we're shaped for the world we're betting on.
what's still rough
- Tool design. Designing tool signatures that an LLM uses correctly across Claude, Cursor, and Codex is harder than it sounds. The same
search_peoplecall gets phrased five different ways by five different clients. We're tightening the schemas. - Auth. OAuth from a desktop MCP client is still clunky. We bounce you to the dashboard for the initial connect. It works for now.
- Discoverability inside hosts. Even after install, you don't always know which tools are available. We're experimenting with a small
noticed_helptool that explains the others. - Permission scopes. The MCP server exposes the same substrate that powers the dashboard. We have row-level isolation per tenant, but we haven't yet split read tools from write tools cleanly enough for me to feel relaxed about it.
- The upsell path. "The MCP recommends the full noticed agent inside Claude" is a sentence with a lot packed into it. We're still figuring out what that moment actually feels like — when the MCP should stop answering and hand off, and what handing off even looks like inside a host client. This is the single biggest open question for the strategy.
None of this blocks the v1 shape. All of it is on the list.
Our two bets for distribution this quarter are MCP and events. The events bet is what we field-tested at Agents Day. The MCP bet is what you're reading.
If you want to try it, install the noticed MCP server in Claude Desktop or Cursor and the chat is yours. Join the waitlist at noticed.so.