SOLUTION ARCHITECTURE

A buying-signal agent that lives inside Claude.

Four data sources - stitched at the account level via ZoomInfo Websights - feed a compliance-first orchestration layer that Claude queries in plain language - so LuxSci's SDR / BDR team can see the highest-intent accounts to reach out to, without a new portal to learn or bulk data to warehouse.

Prepared by VertoDigital For review · CMO Pete Wermter, CISO Greg Neville, Erik Kangas (founder) Draft v3 · Sep 2026

Data sources

GA4

Website intent

Pricing & product-page visits, repeat sessions, high-intent events tagged on the site - sessions carry a Websights-resolved account ID as a custom dimension.

Analytics Data API v1

Salesforce

CRM & pipeline

Accounts, open opportunities, stage, owner, activity - queried inside the secure instance. LuxSci runs Salesforce Enterprise Edition, which includes full REST/SOQL API access - confirmed, not a dependency.

REST API · SOQL

ZoomInfo

Firmographics + intent

Company match, size & industry, buyer-intent topics, plus Websights visitor-to-company resolution for anonymous site traffic - intent-first querying to conserve credits.

Enrich + Intent + Websights API

Company intel

Company profile & employee-growth signals via the LinkedIn Company Intelligence API, accessed live per company through VertoDigital's exclusive agency access. Matching LinkedIn companies against the full Salesforce account list is the one join that needs a small cache - see below.

LinkedIn Company Intelligence API

One exception: the Salesforce ↔ LinkedIn match. Single-company LinkedIn lookups are live, same as the other sources. But matching LinkedIn's Company Intelligence data against a full Salesforce account list over any real date range takes 10-15+ minutes to process - doing that live inside a Claude conversation risks long waits and timeouts. So this one join runs as a weekly batch job, with only the derived match result (account ↔ LinkedIn company, no CRM content or PII) cached in Cloudflare D1 for the MCP tools to read at query time - see "The MCP layer" below for how this fits the no-PII-storage design. Phase 1 inclusion is pending a quick scoping pass - in if it's minimal added work, per the Sep 17 call.

Websights stitching. ZoomInfo Websights tags site sessions client-side and resolves the visiting company in real time, writing an account ID into GA4 as a custom dimension - so GA4 session/behavior data and ZoomInfo firmographic + intent data share a join key before either reaches the MCP layer. This GA4 dimension doesn't exist yet - it's a straightforward GTM setup task, not a blocker. What's genuinely open is the match rate: how much of GA4 traffic Websights can actually resolve to a named account. We don't have that number yet and want to set expectations accordingly rather than assume full coverage.

accessed via MCP tools

Orchestration · Cloudflare

The MCP layer - hosted on Cloudflare Workers

An MCP server on Cloudflare Workers exposes each source to Claude as a set of scoped, read-only tools - no PII or source-record data is stored in the path. Per LuxSci's own direction (Greg Neville's review), this live-orchestration design is the path we're building: no persisted PII, and none of the added BAA/HIPAA governance overhead a store-and-serve model would introduce. One narrow exception - a non-PII matching cache for the Salesforce ↔ LinkedIn join - is called out below.

Live orchestration

GA4 · Salesforce · ZoomInfo · LinkedIn (single-company)

Claude→ OAuth login→ MCP · Workers→ Source APIs (service account)↺

No bulk data storage. Every request is gated by an OAuth login first, built directly into the MCP server, so the MCP layer knows which SDR/BDR is asking - then tools call each source API on demand using a single scoped service account per source; Claude composes the signals per query at runtime.

Why this works - smallest stored-data footprint, easiest CISO path, fastest to ship.

Known limits - API rate/credit limits, per-query latency, no long-term trend history.

Matching cache (Cloudflare D1)

LinkedIn ↔ Salesforce only

Weekly batch job→ LinkedIn CIAPI + Salesforce→ Cloudflare D1 (match keys only)→ MCP reads cache

Computing this match live across a real date range takes 10-15+ minutes - too slow and timeout-prone for a Claude conversation. A weekly batch job pre-computes it instead, and the cache holds only the derived join (account ↔ LinkedIn company) - no CRM records, no PII, nothing from the underlying Salesforce or LinkedIn data itself.

Why this works - D1 is native to the same Cloudflare stack, so no new vendor; the cache is narrow enough to keep the "no PII stored" commitment intact.

Known limits - this one signal can lag by up to a week between refreshes.

MCP protocol

Interface

Claude - the enterprise app, no new portal

plain-language, MCP-powered

SDRs / BDRs ask questions in the Claude they already use. Claude calls the MCP tools, reasons over the signals, and returns the accounts worth acting on. Phase 1 is read-only - insights stay in the conversation; nothing is written back to source systems yet.

"Which healthcare orgs hit pricing 2+ times this week?"

"Score my top 10 open accounts by combined intent."

"Why is [Account] scoring high right now?"

grounded by the brain

The brain · skills

The "brain" - skills & rules as Markdown

multi-tool flows, not one big prompt

We package repeatable work as skills - Markdown files holding the steps, ICP definitions, scoring logic and brand rules Claude follows. Each skill chains several scoped MCP tools rather than relying on one long prompt. Once live, these are plain text files - LuxSci's own team can self-service tweak ICP criteria, scoring thresholds, or brand rules by editing the Markdown directly, no redeploy or engineering ticket required for most changes.

Skill 01

Account intent scoring

Blends website company-based tracking, ZoomInfo intent topics and Salesforce stage into a 0–100 account score against the ICP.

get_account_sessions · get_intent_topics · query_accounts

Not in Phase 1

Day-over-day trend

Without any persistence layer, the agent can't answer "what changed since yesterday" or track intent over time - every query is answered fresh from the live APIs. A daily digest needs a small snapshot/cache, which this no-warehouse design intentionally excludes.

requires persistence · Phase 2 discussion

Not in Phase 1

HIPAA outreach drafter

Drafting and sending outreach touches compliance-reviewed brand copy and (eventually) writes activity back to Salesforce - out of scope for a read-only Phase 1. Revisit once write access and content sign-off are in place.

requires write access · Phase 2 discussion

MCP TOOLS & ENDPOINTS

What Claude can call, per source

Website trackingWeb analytics API

get_intent_events() · get_account_page_views() · get_repeat_visits() · get_account_sessions() · get_named_accounts()

SalesforceREST · /query (SOQL), /sobjects

query_accounts() · get_open_opps() · get_account_activity()

ZoomInfoEnrich · Intent · Search · Websights API

get_intent_topics() · enrich_company() · search_accounts() · get_websights_matches()

LinkedInLinkedIn Company Intelligence API + Cloudflare D1

get_company_profile() · get_employee_growth() · get_account_match()

Each tool is scoped & read-only in Phase 1. ZoomInfo calls lead with intent topics to keep credit usage low. Websights resolves visitor → company client-side and writes the account ID back into GA4, so get_account_sessions() and get_websights_matches() join on the same key - e.g. get_named_accounts() returns "Acme Health Corp - 3 sessions, pricing page" instead of an anonymous visitor count. get_account_match() is the one tool that reads from a cache (Cloudflare D1) instead of calling live - see "The MCP layer" above.

SECURITY & GOVERNANCE

Built for the CISO conversation

No PII or source-record storage, per LuxSci's direction. Data is queried on demand and never persisted - eliminating the BAA/HIPAA governance overhead a stored-PII model would introduce. The one exception is a small Cloudflare D1 cache for the Salesforce ↔ LinkedIn match, which holds only the derived join keys - never CRM content, LinkedIn records, or PII.
Salesforce stays in the secure instance. LuxSci's Salesforce Enterprise Edition confirms full REST/SOQL API access is available - the MCP tools above are feasible as designed. We still work entirely within LuxSci's boundary; no data leaves it.
CISO + founder sign-off. Greg Neville reviews governance; Erik Kangas approves system access before any credentials are provisioned.
Scoped, auditable tools. Each MCP tool is least-privilege and read-only in Phase 1.
Hosted entirely in LuxSci's Cloudflare account. The Workers MCP server lives in LuxSci's own Cloudflare account from day one. Login is handled via OAuth built directly into the MCP server, expected to federate with LuxSci's Google Workspace SSO (to confirm - not a blocker either way) - so LuxSci controls who can authenticate at the identity-provider level.
Service-account access to sources, logged per user. The Workers MCP server holds one scoped service account per source (GA4, Salesforce, ZoomInfo) rather than individual per-person credentials; every call is tagged with the OAuth-authenticated user. Call logs & audit trail use Cloudflare Workers' built-in observability/logging by default.
Websights resolves companies, not individuals. The GA4 stitching key is an account/domain match - no visitor-level PII is introduced into GA4 or the MCP layer.
Admin-controlled access, not just credentials. Source and user/role access is governed by LuxSci directly through a dedicated admin panel - see below.

ADMIN & ACCESS CONTROL

Core security feature

LuxSci controls exactly who can see what

This is a dedicated admin UI, built as a first-class part of the MCP solution - not a config file or a request routed through VertoDigital. It sits on top of the MCP server's OAuth login and gives LuxSci direct governance over which data sources are live and which users or roles can query them.

Per-source kill switch

Turn any source off instantly - GA4, Salesforce, ZoomInfo, LinkedIn - no deploy, no waiting on VertoDigital.

Role-based access

Decide which roles - SDR, BDR, Manager - can query which sources, and change it as the team changes.

Self-service, no ticket

LuxSci's own admin manages this directly through the panel, not as a request queued to VertoDigital's engineering.

Full visibility

See current access at a glance - who's enabled, on what sources - backed by the same Cloudflare call logs used for the audit trail.

Usage observability

Every MCP call - which source, which user, how often - is tracked via Cloudflare Workers' built-in observability at no added infrastructure cost, and surfaced right in the admin panel rather than left in a raw log.

Admin panel · access & usage (illustrative)

1,860

Calls this week

Active users

ZoomInfo

Top source

GA4 Enabled

SDR · BDR · Manager 612 calls/wk

Salesforce Enabled

SDR · BDR · Manager 340 calls/wk

ZoomInfo Enabled

SDR · BDR · Manager 908 calls/wk

LinkedIn Pending scoping

TBD -

Mockup for illustration - real numbers, roles & layout confirmed during build.

GUARDRAILS & WORST CASE

What happens if something goes wrong

Every tool is guarded against misuse, and because Phase 1 is read-only end-to-end, the ceiling on any failure mode below is a wrong or incomplete answer in the conversation - never a wrong write, deletion, or irreversible action against LuxSci's systems.

Tool allowlisting

Claude can only call the specific, scoped read-only functions listed above - no arbitrary API access, and no write or delete tool exists in Phase 1. Worst case: a malicious or confused prompt still can't modify or delete data, because the capability isn't there to call.

Injection-resistant data handling

Content returned from GA4, Salesforce or ZoomInfo (a note field, a company name) is treated as untrusted data, not instructions - the skill layer strips embedded directives before Claude reasons over it. Worst case: a poisoned CRM note or web session can't hijack the agent into unintended actions.

Rate & credit limits

GA4, Salesforce and ZoomInfo calls are capped per session and per day at the MCP layer. Worst case: a runaway loop or over-eager query pattern can't exhaust API budgets or trigger a source-side lockout.

Capped result sets

Every read tool returns a capped page size (e.g. top 50 accounts, not a full-table dump) - separate from the rate/credit caps above. Worst case: someone tries to reconstruct a full CRM/analytics export via many small reads instead of one big one; capped result sizes make that impractical, not just disallowed. (Cap sizes here are placeholders pending LuxSci's input.)

Phase 2 · later

Future growth options once Phase 1 launches

Write-back to Salesforce. Push the intent score & signals onto the account record for the whole team.

Feed paid-ads ABM. Send top in-market accounts to the ad platforms for account-based targeting.

Content agent. A second agent that drafts on-brand assets from the same brain.

NEXT STEPS

Getting to a V1 build

Security & infrastructure session. A 1-hour walkthrough of the initial Cloudflare setup and API token verification, run by VertoDigital for LuxSci's team.

Build V1 and demo. VertoDigital builds a working Phase 1 solution and presents it live at the next meeting.

Internal green light. LuxSci finalizes internal sign-off and sales alignment on its side.

TIMELINE

Six weeks, infra to onboarding

A working estimate for Phase 1 - firms up once source access is confirmed and the LinkedIn scoping pass (above) is resolved.

Week 1

Infra & access setup

Cloudflare Workers stood up, OAuth login configured; API tokens/credentials provisioned and verified across GA4, Salesforce, ZoomInfo & LinkedIn - including the 1-hour security & infrastructure session with LuxSci's team.

Weeks 2-3

Build

MCP tools per source, the orchestration layer, the Cloudflare D1 matching cache & weekly batch job, skills/brain content, and the mini admin panel.

Week 4

QA

End-to-end testing per source, guardrail & rate-limit checks, and a security pass against the CISO's requirements.

Week 5

Onboarding

Live sessions with the SDR/BDR team on using Claude for this, plus an admin-panel walkthrough for whoever owns access control.

Week 6

Launch

Buffer for fixes surfaced during onboarding, then handoff into live use.

VERTODIGITAL × LUXSCI · BUYING-SIGNAL AGENT · DRAFT ARCHITECTURE FOR REVIEW