The data foundation
for agentic AI.

For fifteen years, go-to-market data was built for a person looking at a screen. A rep saw a company name next to a pricing-page visit and applied judgment: that one is a customer, that one is a competitor, that one is worth a call. The data could be loose because the reader was not.

Agents remove that reader. A research assistant, an AI SDR, a routing workflow, or a copilot inside your own product consumes the payload directly, decides, and moves to the next record. Whatever the data implies, the agent will do — thousands of times a day.

A model supplies reasoning. The data foundation supplies the facts it reasons about. When the facts are vague, the agent is confidently wrong at scale.

That changes what “good data” means. Coverage still matters, but so does shape: whether a field is typed, whether a missing value is distinguishable from a zero, whether observation is separated from inference, and whether the agent can tell how fresh a fact is.

This guide is about building the right-hand column: a data foundation an agent can stand on. It covers the four layers of business context, how to hand them to a model without losing meaning, which interface fits which system, five reference architectures, the guardrails that keep autonomy safe, and how to evaluate the whole system on your own traffic.

Most agent projects that disappoint collapse these layers into one number. “Lead score 87” gives a model nothing it can explain, verify, or challenge. Four distinct layers give it something to reason with: this person (identity) works at a company inside our ICP (company), viewed pricing twice this week (activity), and has matched our category topics in three consecutive Orbit runs (intent).

Each layer answers a different question

Why the separation matters to an agent

• Explainability. An agent that cites “viewed /pricing twice; matched data warehouse migration in the last two runs” can be audited. An agent that cites a blended score cannot.
• Independent unknowns. Identity can be absent while company context is present. Intent can exist for someone who has never visited. Each layer needs its own empty state.
• Different permissions. A work email for sales follow-up, a hashed email for ad audiences, and company context for routing are different decisions with different owners.
• Different freshness. A visit from ten minutes ago and a topic match from last week’s run should not carry equal weight in a prompt.

Leadpipe Identification resolves eligible website visits into people and companies by matching deterministically against its own identity graph. The output is a person record — name, work and personal emails, phone, role, seniority, department, and employer — with on-site activity attached.

Deterministic identity is what makes autonomy safe

A probabilistic guess such as “someone from Acme, probably in marketing” is a useful hint for a human. For an agent it is a liability, because the agent will write to a real person on the strength of that guess. Deterministic identity means the person is resolved from a match rather than inferred, so the agent’s first fact is a fact.

Use the hash as your join key

Every visitor record carries the normalized primary email and its hashes: emailHash (SHA-256, also in emailHashes.sha256), emailHashes.sha1, and emailHashes.md5. The lowercase SHA-256 value ties the layers together — it is the visitorId for session summaries and the hashedEmail for Orbit topic history. Pass the hash between systems; pass the address only where a workflow actually needs to contact someone.

                        
                          {
  "email": "jordan.lee@northwind.example",
  "emailHash": "5f2b…c91e",
  "emailHashes": { "sha256": "5f2b…c91e", "sha1": "…", "md5": "…" },
  "businessEmails": ["jordan.lee@northwind.example"],
  "personalEmails": [],
  "phones": ["+1 555 0100"],
  "phonesDnc": false,
  "jobTitle": "Director of Data Engineering",
  "seniority": "Director",
  "department": "Engineering",
  "companyName": "Northwind Analytics",
  "industry": "Software Development",
  "companyEmployeeCount": 420,
  "companyTotalRevenue": null
}
                        
                      

Aliases resolve to one person

People use more than one address. The Data API represents identity aliases as one person, so an agent does not greet the same buyer twice under two emails. Hashes apply to the normalized primary email, not to every address in emails — when you join on a hash, join on that one.

Depth of record, by geography

Person-level identification is strongest on eligible US traffic. For traffic everywhere, IP to company returns stored company context for IPv4 and IPv6 addresses, so a visit from London or Singapore can still route to the right account. EU and UK traffic defaults to company level; person-level identification there requires affirmative consent. Design the agent to accept both depths of record and to act appropriately on each.

Identity says who. Activity says what they did — and on your own site, that is the closest thing to stated interest a buyer gives you before they fill out a form. Leadpipe returns activity in the same canonical visitor record as identity, so an agent receives both together.

Privacy-bounded session summaries

Agents rarely need a full clickstream, and you rarely want to give them one. GET /v1/data/visitors/{visitorId}/sessions returns one bounded record per session — start and end time, duration, page-view count, and path-only entry and exit pages — without detailed events, full URLs, query strings, or fragments. It is the right default for a model’s context window: enough to reason about engagement, nothing it does not need.

                        
                          {
  "sessionId": "ses_1vR8zPqY2dV5…",
  "version": "sv_8sH2mN6qR1vY…",
  "startTime": "2026-08-13T14:00:00.000Z",
  "endTime": "2026-08-13T14:14:00.000Z",
  "durationSeconds": 840,
  "pageViews": 4,
  "entryPage": "/pricing",
  "exitPage": "/thank-you",
  "updatedAt": "2026-08-13T14:15:00.000Z"
}
                        
                      

Three details that matter for agents

• version is a change detector. It changes whenever any field in the summary changes. Store it and re-run the agent only when it moves — cheaper and more consistent than reprocessing on a timer.
• asOf freezes the window. The first page of a traversal fixes meta.asOf, so a relative window such as 30d does not shift while you paginate. Include asOf in the agent’s context so it knows what “recent” meant.
• meta.coverage.partial is a fact, not noise. When it is true, the population does not fully cover the requested window. Carry that qualification into any report or summary an agent writes.

Carry your own context through the pixel

Append query parameters to the pixel script — a partner customer ID, a campaign, a region — and Leadpipe returns them in customAttribution on every visitor record and webhook delivery. For a multi-tenant agent, this is how a visitor arrives already labeled with the tenant it belongs to.

                        
                          <script
  src="https://leadpipe.aws53.cloud/p/YOUR-PIXEL-ID.js?partnerCustomerId=customer_123&campaign=spring-2026"
  async
></script>
                        
                      

Most research happens before a buyer reaches your site — on publications, communities, documentation, and comparison pages. Orbit is Leadpipe’s person-level intent product: a monitored network of 5M+ websites organized into 20,810 topics, with active audiences refreshed daily. Instead of an account-level “surge” flag, it returns people, the topics they matched, and how strongly.

How Orbit models intent

From topic to people

1. Find topics. Analyze a website, browse the catalog, or search it. Topic discovery is public, so an agent can explore your category before it has an API key.
2. Preview. Estimate audience size and inspect masked sample rows without saving anything.
3. Save the audience as draft or active. Active audiences refresh through scheduled daily runs.
4. Run. Queue a manual run with an Idempotency-Key, or let the daily refresh produce the next snapshot.
5. Read. Page through hydrated results — ordered by intent score, then topic overlap — check fill-rate stats, or export a CSV.

                        
                          import { Leadpipe } from "@leadpipe/client";

const client = new Leadpipe({ apiKey: process.env.LEADPIPE_API_KEY });

// 1. Find topics that describe your market
const topics = await client.intent.topics.search({ q: "data warehouse", limit: 5 });
const topicIds = topics.data.map((topic) => topic.topicId);

// 2. Save an audience with fit filters, then activate it
const audience = await client.intent.audiences.create({
  name: "Warehouse migration researchers",
  config: { topicIds, minScore: 70, filters: { hasBusinessEmail: true } },
});
await client.intent.audiences.update(audience.data.id, { status: "active" });

// 3. Wait for the snapshot, then read the strongest matches
await client.intent.audiences.waitUntilReady(audience.data.id, { timeoutMs: 600_000 });
const results = await client.intent.audiences.results(audience.data.id, { limit: 25 });
                        
                      

Where intent meets activity

The compound signal — researching your category and visiting your site — is available as its own set of operations, deduplicated by email hash:

The run-over-run dashboard is especially useful for agents. People added, people removed, and intent and topic movement are exactly the “what is new since yesterday” an agent needs to write a useful morning brief.

Many “hallucinations” in go-to-market agents are contract failures, not model failures. The model was handed a record with a blank title and asked for a personalized email, so it invented a title. It was handed a score with no explanation, so it explained it. The fix is rarely a better prompt. It is a better envelope.

Seven rules for agent-ready context

1. Separate facts by layer. Identity, activity, intent, and company go in distinct objects. Never merge them into one score before the model sees them.
2. Make unknown explicit. Leadpipe returns empty arrays and null rather than placeholders. Preserve that, list the missing fields, and instruct the model never to infer them.
3. Separate observation from inference. Facts come from Leadpipe; conclusions come from your agent. Store them in different places so a summary cannot be laundered back into a fact.
4. Timestamp everything. lastSeenAt, the traversal asOf, and the Orbit run date. “Recent” is meaningless to a model without a clock.
5. Keep provenance. Record which operation, pixel, segment, or run produced each fact, so every claim can be traced.
6. Send only what the job needs. A routing agent needs company and activity, not phone numbers. Fewer fields means less risk and lower token spend.
7. Use canonical names. Build on companyName, companyEmployeeCount, phonesDnc, and the other canonical fields. Legacy aliases exist for backward compatibility, not for new builds.

An agent-ready envelope

Here is one way to package a Leadpipe visitor for a model. It is an application-side shape you assemble from API or webhook data — not a raw Leadpipe response — and it makes every rule above visible to the model.

                        
                          {
  "subject": { "emailHash": "5f2b…c91e", "asOf": "2026-10-21T09:00:00Z" },
  "facts": {
    "identity": {
      "name": "Jordan Lee",
      "jobTitle": "Director of Data Engineering",
      "seniority": "Director"
    },
    "company": {
      "companyName": "Northwind Analytics",
      "industry": "Software Development",
      "companyEmployeeCount": 420
    },
    "activity": {
      "sessions": 3,
      "pricingPageViews": 2,
      "lastSeenAt": "2026-10-20T16:42:00Z",
      "landingPage": "/product/orbit",
      "utmCampaign": "warehouse-migration"
    },
    "intent": {
      "audience": "Warehouse migration researchers",
      "runDate": "2026-10-21",
      "topics": ["Data Warehouse Migration", "Cloud Data Platforms"]
    }
  },
  "unknown": ["phones", "companyTotalRevenue"],
  "provenance": {
    "identity": "GET /v1/data?email=…",
    "activity": "GET /v1/data/visitors/{visitorId}/sessions",
    "intent": "Orbit audience run, 2026-10-21"
  },
  "policy": { "allowedAction": "draft", "channel": "email", "approver": "account owner" }
}
                        
                      

MCP: give an agent the foundation directly

The official MCP server wraps the public Leadpipe APIs in a local server that MCP-compatible clients use over stdio. Install it with one command and your own API key.

                        
                          {
  "mcpServers": {
    "leadpipe": {
      "command": "npx",
      "args": ["-y", "@leadpipe/mcp"],
      "env": { "LEADPIPE_API_KEY": "sk_..." }
    }
  }
}
                        
                      

                        
                          codex mcp add leadpipe --env LEADPIPE_API_KEY=sk_... -- npx -y @leadpipe/mcp
codex mcp list
                        
                      

The server also ships guided prompts — discover-audience-topics, operate-saved-audience, and investigate-visitor-data — plus documentation resources (leadpipe://docs/auth, leadpipe://docs/workflows, leadpipe://docs/data-api) the agent can read before it acts.

REST: the full surface from your backend

Every API uses the base URL https://api.aws53.cloud and an organization key in the X-API-Key header. Keys belong in a backend or secret manager — never in browser code or a pixel URL. Machine-readable OpenAPI specifications are published for identification and intent.

                        
                          # Newest identified visitors, 50 per page
curl "https://api.aws53.cloud/v1/data?page=1" \
  -H "X-API-Key: $LEADPIPE_API_KEY"

# One person, with their session journey and summary
curl "https://api.aws53.cloud/v1/data?email=jordan.lee@northwind.example" \
  -H "X-API-Key: $LEADPIPE_API_KEY"

# Only visitors that match a saved segment
curl "https://api.aws53.cloud/v1/data/query" \
  -H "X-API-Key: $LEADPIPE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"segmentId": "YOUR_SEGMENT_ID", "page": 1, "limit": 50}'
                        
                      

Webhooks: event-driven agents

When the agent should start the moment someone is identified, use a webhook. Each one has an HTTPS destination, a segment, a pixel, and a trigger: First Match delivers once per qualifying visitor; Every Update keeps delivering as the record changes. Start with First Match on a narrow segment, make the receiver idempotent by upserting on the email hash, and watch delivery success before widening the segment.

Documentation your agent can read

Point a coding agent at the machine-readable entry points before it writes integration code: the documentation index, Leadpipe’s agents.txt operating brief, and the site index.

Control what is collected and processed

Suppression accepts up to 25,000 rules per upload, and replacing the list from your CRM each night keeps “never contact our customers” true without anyone remembering to update it. Suppression governs future processing; it is not a deletion request and does not recall records already delivered.

Decide what the agent may do

Start anything customer-facing at Draft. Move a workflow up a level only when its acceptance rate, measured in chapter 10, shows that people rarely change what the agent proposes.

Operate safely

• Keys. Organization-scoped and server-side. Regenerating a key invalidates the previous one, so update every backend that uses it. Never send an sk_ key as a Bearer token.
• Rate limits. Read the RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset headers and honor Retry-After on a 429. Do not reuse one endpoint’s allowance for another.
• Retries. Bound retries on reads. Orbit run creation accepts an Idempotency-Key. Do not automatically retry company lookups after an uncertain response — each company result uses allowance.
• Logs. Record method, path, status, and request ID. Strip keys and personal data from anything shared.
• Contact rules. A populated contact field is not proof of deliverability or permission. Honor phonesDnc, unsubscribes, and each channel’s policy.

Geography and privacy review

Person-level identification is strongest on eligible US traffic. EU and UK traffic defaults to company level, and person-level identification there requires affirmative consent. Give your privacy reviewer the actual installation scope, contact fields, and destination workflow, and request Leadpipe’s current privacy documentation and terms. Review email, advertising, and sales uses separately with the teams that own them.

Healthcare and other regulated industries

Healthcare technology vendors, suppliers, and service organizations use Leadpipe for commercial work: account research, business development, and marketing to the organizations they sell to. The data is business context — professionals and the companies they work for, what they read on your site, and the topics they research. It is not a clinical record, and it should never be joined with patient data or used in a clinical workflow.

• Define the commercial relationship the workflow serves before choosing data.
• Exclude patient-facing pages and portals with page targeting.
• Keep the agent’s outputs inside sales and marketing systems.
• Review the workflow with your compliance team before launch.

Results from someone else’s traffic say little about yours. What matters is whether, for your ICP and your workflow, the records are actionable and the people who own the next step accept what the agent produces.

Measure the data

Review a defined sample with the same pixel, period, and filters. For Orbit, run stats report field fill rates and the intent-score distribution for each completed snapshot.

Measure the agent

A 30-day rollout