# Agentic Audience Intelligence

Choose a dataset, take the recommended method and model, and build a scaled audience: look-alike, act-alike, propensity or a model you bring. Agents assess the data and rank the methods; a deterministic router decides each one first, so an audience is built only where the evidence allows. Try it on eight generated data types.

> Markdown twin of https://nofluffadvisory.com/building/audience-intelligence/ — text extracted from the page. Project registry: https://nofluffadvisory.com/building/

Audience builder · Agents recommend, the router decides

# Agentic Audience Intelligence.

Choose a dataset, take the recommended method and model, and build a scaled audience. Every method is decided first, with reasons, so nothing is modeled the data does not allow.

Build an audience ↗

Engine on GitHub ↗

Synthetic datasets, computed when the site was built. Not client data, not a model-quality claim. External demo · opens in a new tab.

- What it does
- Build an audience
- How it decides
- Bring your own model
- What is verified
- Stack
- Industry context
- **Status** — Demonstrator · live on synthetic data
- **Stage** — Founder · Built in public
- **Product** — Audience builder with a decision trail
- **Rule** — Agents recommend · the router decides
- **Engine** — Python · deterministic router
- **Demo** — Static · computed at build time
- **License** — MIT · open source

What it does

## One dataset. A scaled audience.

Bring a dataset and leave with an audience: the engine assesses the data, recommends a method and a model, and builds the audience at the reach you set. Before any of that runs, it answers the question every clean-room lawyer and data owner asks first: is this data allowed to do this specific thing, here, for this destination? It answers per method, with the evidence, before any score exists.

Agents read the source profile and propose what could be built: a seed-affinity look-alike, a behavioral-affinity act-alike, an aggregate report, a contextual cohort, or a registered model of your own. A deterministic router checks each proposal against policies, unit mappings, model registrations and thresholds, and returns a verdict with reasons. Only then does modeling run, and only where the verdict allows.

The modeling is machine learning, run by the engine rather than by the agents: k-means multi-prototype and centroid similarity for look-alikes, logistic-regression and gradient-boosted propensity models for outcomes, with fixed seeds and reported metrics. Agents choose what to propose; they never train or tune a model, so nothing an agent says becomes a fact nobody can audit.

> Agents propose. The router decides. People approve releases.

The operating rule

Build an audience

## Eight data types. Five steps to an audience.

The demonstrator’s workbench runs the real engine over eight generated datasets: the router decides every method, the eligible models are trained and compared on held-out records, and the results ship as static bundles. Nothing runs while you browse; the page filters what was computed, and each bundle carries the engine and snapshot hashes that produced it. Uploads and live runs come with a server version of the same engine.

- **01** — Choose data — Step 1 of the demonstrator: eight sample datasets as cards, each listing the methods it supports, its record count and a one-line description; Web and app events is selected.
- **02** — Read the assessment — Step 2: the assessment of the web and app events dataset, with what each record is, the seed list, behavior pattern and outcome label, the proposed methods, and a table of seven signals with missing rates.
- **03** — Pick method and model — Step 3: look-alike, act-alike and purchase propensity methods, each stamped ELIGIBLE, look-alike recommended; centroid similarity is the recommended model, with held-out recall at 1, 5, 10, 20 and 50 percent reach.
- **05** — Export — Step 5: a button to download the audience as a CSV file, with the row export verdict ELIGIBLE and its decision identifier.
- **Choose data** — Eight generated datasets, one per data type. None describes a real person, household, company or place.
- **Read the assessment** — What each record is, which signals it carries and how complete they are, any seed list, behavior pattern, outcome label or content brief, and which sensitive columns were excluded.
- **Pick method and model** — Every method carries the router’s verdict and its reasons, and the recommended one is marked. Candidate models are compared on held-out records; the best is recommended and can be overridden.
- **Set the reach** — Trade audience size for quality: held-out capture against random selection, lift, the score cut-off, composition against the pool and what sets the audience apart.
- **Export** — A decision of its own. Rows download in the browser where policy permits; the clean room only releases an aggregate report with small cells suppressed.
- **B2B accounts** — Look-alikes of closed-won customers and act-alikes of accounts researching the category. Propensity stays provisional: too few opportunities to train on.
- **Geography** — Postal areas like your best-performing ones. The audience is a set of areas, never a set of people.
- **Demographic and firmographic** — Look-alikes of webinar registrants. An inferred health attribute sits in the file and is excluded before any model sees it.
- **Interest and behavioral segments** — Mobile devices with provider interest segments and app behavior; look-alikes on seeds, act-alikes on behavior.
- **TV viewing (ACR)** — Households in a clean room. Models run inside; row export is blocked and only aggregates leave.
- **Web and app events** — All three: look-alikes, act-alikes, and an estimated chance of purchase within 30 days.
- **First-party CRM** — Look-alikes of top customers, a purchase propensity model, and your own registered model, checked like any other evidence.
- **Page content (URL)** — Pages that match a content brief, or pages like the ones where the last campaign performed best.
- **audiences.nofluffadvisory.com** — Demonstrator — Build an audience on eight generated datasets, then see how the router decided four more scenarios. Every verdict, model and score carries the engine and snapshot hashes that produced it.
- **Engine and contracts** — GitHub — MIT-licensed: the router, the schemas, the conformance cases and the PowerShell check suite. Clone it and run the same checks.

How it decides

## Three verdicts. No silent yes.

- **ELIGIBLE** — cleared — Every prerequisite for this task is satisfied by evidence on file. The task can run.
- **PROVISIONAL** — warm — Nothing forbids it, but some evidence is missing. The decision names what is missing and how to supply it.
- **BLOCKED** — licensed — A policy, grain or contract check is violated. No agent, ranking or retry can turn this into a yes.
- **Fitness is per task.** — A dataset is never “good” or “bad”. Its fitness is the set of decisions for the tasks someone actually asked for: the same TV-viewing data is blocked for row export and eligible for an aggregate report.
- **Violated beats missing beats satisfied.** — Each task is checked against the prerequisites its family needs. One violation blocks; one gap holds it provisional; only a clean sheet is eligible.
- **Silence is not permission.** — A source whose policy says nothing about an operation counts as missing evidence, never as a yes. Every contributing source must permit it; any prohibition wins.
- **Facts never come from agents.** — Agents read profiles and propose tasks, features and models. Policies, mappings, registrations and thresholds are documents with owners and validity windows. Agents can cite them; they cannot create them.
- **People approve releases.** — An eligible task can run. Releasing an audience is a separate, human-approved step, and the demonstrator activates nothing.

In the interface, a look-alike is seed affinity: how close an entity sits to a seed set. An act-alike is behavioral affinity: how closely its behavior matches a pattern. Neither is presented as a probability. Only a calibrated propensity model can say “estimated chance of [event] by [horizon]”. Training one is itself a task the router gates, and it stays provisional until the calibration evidence exists.

Bring your own model

## Your model, the same gate.

A model you bring is registered, not trusted. Its registration declares what it needs and where it may run, and the router checks those declarations like any other evidence. Remote inference is its own operation, so sending features to a model outside the data owner’s walls needs its own permission.

- **Required features** — What the model reads, checked against what the dataset carries
- **Grain** — The unit it scores, checked against the registered relationships
- **Score type** — Seed affinity, behavioral affinity or a calibrated probability
- **Validation** — Evidence bound to this model and its preprocessing
- **Population** — Where the evidence was gathered, and where it holds
- **Validity** — Effective dates; a lapsed registration stops the task
- **Rights** — Permitted uses and, for remote inference, recipient terms
- **Execution** — Where it may run: in place, in a clean room or remotely

Recommendations rank only the options that are eligible against the same objective. The requested task always stays visible, a ranking cannot override a verdict, and when costs are unknown the ranker says it cannot rank rather than guessing.

What is verified

## Software behavior, not market results.

This is a working engine, not a validated product. What has been checked is listed here, and so is what has not. In the demonstrator’s look-alike run, multi-prototype scoring finds more held-out seeds than a single centroid. That is a synthetic result: it shows the software behaves as designed, not that it would beat anything on real data.

- **Contracts** — JSON Schema 2020-12 files, meta-validated
- **Conformance** — valid documents pass; invalid cases fail for the stated reason
- **Tests** — unit and contract tests · Linux and Windows · Python 3.11 and 3.12
- **Routing suite** — development cases, passed by construction
- **AdCP boundary** — Adapter output validated against pinned AdCP 3.1.20 schemas
- **Not yet run** — Agent routing with a real model · real data · clean-room enforcement · live delivery

Stack

## Contracts first. Code second.

- **Engine** — Python 3.11 and 3.12 · locked dependencies · ruff · mypy
- **Contracts** — JSON Schema 2020-12 · contracts · registered reason codes
- **Router** — prerequisites · policy composition across lineage · decision validity windows
- **Modeling** — numpy · scikit-learn · k-means multi-prototype and centroid seed affinity with explicit abstention · logistic and gradient-boosted propensity
- **Metrics** — Held-out seed recall at reach · average precision · Brier score · log loss · calibration bins
- **Ranking** — Deterministic ranker over eligible options only; it cannot override a verdict
- **Workbench** — Eight generated datasets · evidence facts computed from the data · bit-identical across platforms
- **Demonstrator** — Bundles precomputed at build · dependency-free page · strict CSP · Cloudflare Pages
- **CI** — GitHub Actions on Windows · PowerShell check suite on every push

Industry context

## Before the vector, the permission.

Agentic advertising is standardizing how audiences travel between agents: IAB Tech Lab’s Agentic Audiences passes them as embeddings, and AdCP carries signals and activation between buyer and seller agents. Neither tells a data owner what their data is permitted to become. This engine is that missing step, upstream of the exchange: it decides what may be built, and its AdCP adapter builds signals only from release manifests, after people have approved them.

It sits beside the AdCP Signals Adaptor, which serves signals to buyer agents, and the AdCP Publisher Stack, which sells against them. This build is the part that decides, with reasons, which audiences should exist at all.

Talk data

## Sitting on audience data? Need to know what it may become before anyone models it?

Get in touch →