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.
Synthetic datasets, computed when the site was built. Not client data, not a model-quality claim. External demo · opens in a new tab.
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.
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.
See the other four steps
-
Step 01 · Choose data
-
Step 02 · Read the assessment
-
Step 03 · Pick method and model
-
Step 05 · Export
- 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.
- Demonstrator
audiences.nofluffadvisory.com
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.
- GitHub
Engine and contracts
MIT-licensed: the router, the schemas, the conformance cases and the PowerShell check suite. Clone it and run the same checks.
Three verdicts.
No silent yes.
- ELIGIBLE
Every prerequisite for this task is satisfied by evidence on file. The task can run.
- PROVISIONAL
Nothing forbids it, but some evidence is missing. The decision names what is missing and how to supply it.
- BLOCKED
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.
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.
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
- 38 JSON Schema 2020-12 files, meta-validated
- Conformance
- 85 valid documents pass; 75 invalid cases fail for the stated reason
- Tests
- 333 unit and contract tests · Linux and Windows · Python 3.11 and 3.12
- Routing suite
- 12 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
Contracts first.
Code second.
- Engine
- Python 3.11 and 3.12 · locked dependencies · ruff · mypy
- Contracts
- JSON Schema 2020-12 · 38 contracts · 72 registered reason codes
- Router
- 27 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
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.