Sales Second Brain

Role

AI Martech Manager. I owned the product, the roadmap, the architecture decisions, and teams onboarding.

Timeframe

June 2026 to present. Shipped and in daily use by the US and UK sales team.

Team

An engineer from an external development partner and a brand designer. I was the only product and domain owner.

Built with

Model Context Protocol, Cursor or Claude plugin architecture, Relevance AI, Google Drive, Outreach, Salesforce.

Four problems, and the third one made the first two worse.

1. The same research, over and over

   Every seller rebuilt the same picture of an account before every call. That work was thrown away the moment the call ended, so the next person started from nothing.

2. Knowledge with no home

   Calls sat in a recording tool, emails in Outreach, pipeline in Salesforce, positioning in Drive, and the rest in whoever happened to run the account. No single place answered the question “what is going on with this client.”

3. An assistant nobody could trust

   A general AI assistant answers confidently whether or not it knows anything. In sales that is not a small flaw. One invented number in front of a client costs more than the tool saves, so sellers stop using it, and adoption dies quietly.

4. Every deck and one-pager built by hand

   A sales deck took hours in Figma or PowerPoint, a one-pager took most of an afternoon, and fonts, colours and spacing drifted off-brand from asset to asset. One team was the bottleneck for every request, and every new asset re-solved problems already solved before.

One plugin, 15+ skills, built on one knowledge layer.

It runs as a plugin inside the tools sellers already have open, so there is no new application to log into. 15+ skills sit on top of the same knowledge layer: cited question and answer, live enrichment, a value selling methodology engine, and a branded asset generator that produces editable client decks and one pagers.

Four calls that decide whether a system like this gets used or quietly abandoned.

1. Navigate, do not search

   The obvious build is full text search over everything. We did the opposite. The knowledge base is a catalog plus one folder per company, and the assistant browses it the way you would browse a well organized wiki: find the company in the index, open its folder, read the page whole.

   Search returns fragments that look relevant and often are not. Navigation returns the actual page. It is more precise, it costs a fraction of the tokens, and it fails visibly instead of silently.

2. Cite every claim, or do not make it

   Every fact in an answer carries the path of the page it came from, so a seller can check it in one click before it reaches a client. If the knowledge base does not cover something, the assistant says so and names the source that would need to be added. It is not allowed to fill the gap from general knowledge.

   This is the decision that bought trust. Sellers do not need an assistant that is right most of the time. They need one that is honest about which of the two it is being.

3. The assistant cannot write

   There is no write tool in the assistant’s scope at all. Not a restricted one, not a permissioned one. The backend owns every write to the knowledge base.

   The cost is real: users cannot tell the system to remember something, and that surprises people. The benefit is that a shared source of truth used by a whole sales team cannot be corrupted by one confused chat session. For a system whose only asset is trust, that trade is worth making.

4. Research once, then reuse

   A live research run does two things. It answers the person waiting, clearly labeled as fresh and not yet filed. It also queues the result for ingestion, so the same question next month is a cited page instead of another paid research run.

   Every filed result carries a date stamp, so a seller can see at a glance how stale it is and rerun the research themselves if the account has moved on.

   This is what turns the tool from an expensive lookup into an asset that gets more valuable the more the team uses it.

I ran this as the product owner with a two person external engineering team on a fixed hour contract and an internal brand designer. I set the roadmap, made the data and architecture calls, and ran the rollout. Three decisions were mine and worth showing.

1. Two connections to one system, because neither was enough

   Pulling sales activity out of Outreach looked like a one connector job. It was not. The HTTP API returned full account and email data but truncated call transcripts. The MCP interface returned full transcripts through GraphQL but lacked the application level access points. Each alone produced a knowledge base with a hole in it.

   We reviewed 38 endpoints and built against both, handled server side so the plugin never had to know.

2. One server, two scoped roots, for the UK expansion

   The US rollout worked, UK leadership saw a demo, and the UK team asked for their own. The default answer is a second deployment. That would have duplicated a multi gigabyte shared asset library and doubled the maintenance surface for a team of one engineer.

   Instead: one server, two top level content roots, and access scoped by token. A UK token has no awareness of US data and the reverse holds. Shared material lives once at the top level and compiles into both regions. Region specific material sits in its own root.

3. Designing the running cost down

   A system that reprocesses everything nightly with a language model has a bill that grows with the knowledge base. So the sync filters on last updated time and only touches records that actually changed. Pipeline data is written deterministically with no model call at all. A cheap cache check runs before a new company folder is created, so the same account does not get filed twice under two spellings.

• June 2026 Knowledge base and plugin builtWiki structure, citation model, and the read only access layer. Shipped to a small internal group first.
• August 2026 Demo to the sales team and CEOAround 25 people. Deliberately not a technical walkthrough. Two workflows shown end to end, with feedback collected through a form rather than a channel thread.
• August 2026 Sales activity connectorCalls, emails, and pipeline compiled per company, with parent accounts and their individual sites handled separately. Full transcripts stored alongside summaries, with citations on every claim.
• September 2026 UK expansionRequested by UK leadership after a demo. Delivered as token scoped regional roots on the existing server.
• In progress Internal AI marketplace listingMoves distribution from a manual install to a governed internal listing. Currently working through how authentication should be handled for a wider audience.