Audience Builder

Audience Builder turns a plain-English brief — "operations directors at multi-site veterinary groups in the Southeast" — into a list of reachable contacts, with the reasoning behind every inclusion on record.

It is an agent, not a query builder. It reads the brief, says back what it understood, and waits for you to agree before it spends anything. It then finds what is actually in the data, builds a candidate set, judges it against your criteria row by row, and delivers the people who qualify with their contact channels attached. Every step that changes the row count is recorded, so a result that comes in smaller than expected can be explained rather than argued about.

What lives where

How a build works

A build runs in one direction, and each stage exists because skipping it costs money.

1. The brief. You describe the audience. If the request is not an audience, the agent says so and stops rather than inventing one.

2. Criteria. The agent restates the brief as a numbered list of criteria and a diagram of the pipeline it intends to run. Each criterion is labelled with how it can be satisfied: directly from a column, derived from columns, judged by a model, fetched from the open web, or simply absent from the data. Criteria marked absent are the ones worth arguing with.

3. Approval. Nothing that builds a table or spends model tokens runs until you approve the criteria. Probing is exempt — the agent is allowed to find out what exists before asking you to commit to a plan. You can revise the criteria at this point, or later; work already paid for is carried forward rather than repeated.

4. The sample. Every build starts as a sample: a few hundred rows judged against your rubric, priced in cents. The point is to prove the pipeline before running it at scale. You see the actual rows, the accept rate, and the reasons behind individual verdicts.

5. The estimate. From the sample the agent projects the full result — how many contacts, within what range, at what cost and how long. The range is a real confidence interval, widened for the possibility that the rubric itself is wrong.

6. The full run. You commit to the estimate and the same pipeline runs against the whole population. Progress is reported against the workflow you approved, stage by stage.

7. Delivery and unlock. The result is packaged into tabs with contact channels attached. The build itself is billed as compute as it happens; the contacts are paid for once, at unlock. Payment clears first, then rows move into a shared contacts store owned by your account. Rows, export, and MCP reads only see what you have unlocked. Warehouse table names never leave the building.

Data Catalog

What a build can draw on — named the way tools and traces name it. Physical warehouse names never appear in the product; these catalog names are what you will see.

Funding and investors. Investor-per-round history (stages, amounts, exits, acquirers) and fund profiles (type, deal counts, deployed capital). Used when the brief is about who backed whom, VC-backed companies, or platform contacts at funds.

What lives on a contact row

Worth knowing before you brief — these are the families the graph actually carries.

Vocabulary

Brief — the audience, described the way you would to a person.

Criteria — what the agent understood, restated as a numbered list. Each criterion is tagged with how it can be satisfied: column, matched directly against the data we hold; derivable, calculated from the data we hold; judgeable, judged company by company by a model reading the evidence; external, researched from a public source on the open web; absent, not available — we hold nothing that answers this. Criteria marked absent are the ones worth arguing with before anything runs.

Sample — a few hundred rows judged against your brief, priced in cents. Every build starts here. The point is to prove the approach before spending at scale.

Estimate — the projected full result from the sample: how many contacts, within what range, at what cost and how long.

Unlock — paying for the finished contacts so the export is released. Compute is metered while the build runs; contacts are charged once, here.

Tab — one sheet of the deliverable, exportable as CSV.

Suppression — removing rows that appear on a list you supply, matched on any shared key.

Enrichment — matching your own records back to the graph, strongest identifier first.

Matching your records back

When you supply your own list, it is matched against the graph strongest identifier first. Each row is matched once, by the best tier that can reach it.

What it costs

Two things are billed and they behave differently.

Compute is metered as the agent works, drawn from a prepaid balance. Your balance tops itself up from the card on file before it runs out, so a build does not stop halfway. A sample costs cents; that is the point of it.

Contacts are $0.02 each. Approving a sample charges a capped preview of those contacts (enough to review, never the whole list) against your prepaid compute balance (the same drawdown that tops up from the card before it runs dry) and releases them into the Data tab. Unlocking the full audience under $5 of contact spend also draws that compute balance; larger audiences are charged once at unlock — before the export is released and after you have seen the estimate.

Channel validation is $1.00 per 1,000 lookups. A lookup is one channel on one row, so validating email and mobile on the same audience counts as two.

Page rendering applies when a source has to be opened in a real browser rather than fetched, which is a handful of pages in a run and none in most. It is billed per page — a fraction of a cent for an ordinary page, more for a site that actively resists being read — and metered with compute rather than billed separately.

Prepaid credit is sold in packs below face value. Buying a pack raises the same prepaid balance that metered compute and unlocks draw from — it is not a separate wallet. The discount steps with pack size: 5% at $100, 10% at $250, 15% at $500.

First call

Authenticate with a key we issue: Authorization: Bearer <key>. The key decides which account a request belongs to — no other header can change it. Keys are shown once at issue and stored only as a hash, so a lost key is replaced rather than recovered.

Issue one with ab keys new you@example.com. A server listening only on this machine skips auth; anything reachable from elsewhere requires a key on every route except this documentation.

The smallest useful call — brief an audience. It always starts as a sample and waits for you to approve the criteria before anything spends.

curl -sX POST https://<your server>/api/audiences \
  -H 'Authorization: Bearer <key>' \
  -H 'Content-Type: application/json' \
  -d '{"request": "Operations directors at multi-site veterinary groups"}'

Then read back what it understood and release it:

curl -s  https://<your server>/api/audiences/<id>/workflow \
  -H 'Authorization: Bearer <key>'

curl -sX POST https://<your server>/api/audiences/<id>/approve \
  -H 'Authorization: Bearer <key>'

Every route, with examples, is on the API reference.

From your own assistant

Drive a build from Claude, Cursor or ChatGPT instead of writing HTTP calls. Add this server to your assistant:

{
  "mcpServers": {
    "audiencebuilder": {
      "url": "https://<your server>/mcp",
      "headers": { "Authorization": "Bearer <key>" }
    }
  }
}

Your assistant gets the client's half of the engagement — brief, approve, follow, read the result, pay for it — with the same approval gates as the web app. It cannot start a full run against a misread brief on your behalf.

Ask it to read_documentation first.