Advertising AI agent · Brand safety
Brand-Safety & Suitability AI Agent
Maintain the inclusion and exclusion lists, classify inventory against the suitability policy a person set, filter pre-bid and report where ads ran — the brand owns the policy and every category boundary.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Policy sign-off
- Named owner
- After launch
- Agent Care
What this agent does
Applies the policy, does not set it
In
- 01
Read the brand's suitability policy, its inclusion and exclusion lists, and the version each of them is on.
- 02
Take the inventory as it arrives — domain, app, channel, page, video, podcast or retail-media placement.
Reason
- 03
Classify content and inventory against the policy's categories and risk tiers, and record which tier it fell in.
- 04
Keep the floor a brand will not fund separate from the tiers that this brand alone has chosen to avoid.
- 05
Mark anything it could not read — wrong language, non-text format, thin page — as unclassified, not as safe.
Decide
- 06
Propose pre-bid filters and post-bid flags, and hold every list change and category move for the policy owner.
- 07
Route flagged placements, news and sensitive-event adjacency and unclassified inventory to human review.
Out
- 08
Write approved list changes to the platforms that accept them, and report where ads ran and what went unread.
- 09
Retain the policy version, the classification, its evidence and every block, allow and reviewer decision.
Product statement
The agent applies a policy a person set and surfaces what it could not classify. It does not decide where a category boundary sits, and it guarantees nothing.
Example workflow
One placement, end to end
- 1Placement seenA bid request or a delivered impression on a domain, app, channel, video, podcast or retail-media placement
- 2Policy and lists readThe brand's suitability policy, its tiers, its lists and the version each is on, stamped with the time read
- 3Content classifiedCategory and risk tier against that policy, with the language, format and evidence the classification rests on
- 4Filters and flags proposedPre-bid filters, post-bid flags and list additions or removals, with anything it could not read marked unclassified
No human action required
Stages 1 to 4 run without a person in the loop — the classification, the filter proposal and the list difference are finished before anyone is asked to read anything.
Reaches the policy owner ready to apply.
Held with the reason named, not applied.
Policy owner and account lead
The policy owner decides where the category boundary sits and clears every list change; the account lead signs the report that goes to the client.
Approve · Move the boundary · Send back
Approved — handed back
- 6Lists and reports updatedOnly the list changes a person approved, then the where-it-ran report back to the client
- 7Outcome evaluatedFalse blocks against a human-reviewed sample, missed adjacency, and classifier accuracy by language
Boundary moves
Every category boundary a person moves is recorded against the policy version.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Setting or moving a suitability category boundary.
- Adding a publisher to an exclusion list.
- Removing a publisher from the inclusion list.
- Blocking a news outlet or a whole section.
Automation boundary
Agent acts unaided
- ✓Classify content and inventory against the policy's categories and tiers.
- ✓Mark what it could not read as unclassified, and say why.
- ✓Propose pre-bid filters, post-bid flags and list changes for approval.
- ✓Assemble the where-it-ran report and flag adjacency for review.
Write actions run only inside the approval boundaries agreed during implementation. Moving a category boundary and blocking a publisher are not among them.
- Widening a keyword block across live campaigns.
- Changing the policy version a campaign runs on.
- Clearing a flagged placement as acceptable.
- Signing the where-it-ran report sent to a client.
Example output
One placement, annotated
Everything the agent proposes is attached to the placement it judged.
Suitability output · single placement
Illustrative example- Placement
- News site, in-article video
- Language
- Non-English video
- Policy
- Read today
- Classification
- Death, injury or conflict
- Confidence
- 61%
- Proposed action
- Held, not blocked
As received
The placement, the language and format handed to the classifier, and the policy version it was judged against.
Evidence used
- Page text and transcript
- Publisher on inclusion list
- Policy tier, dated
Why it is held
The category is on this brand's own line, not the floor — and that line is a person's call.
What the score decides
It decides whether a person reads it first, not whether the content was safe.
Action
ApproveMove the boundarySend backValue
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value lands
Value 01 – 04
Every placement, every campaign
From bid requests and delivery logs
Apply this brand's own line
Classify against the client's own suitability policy and tiers, dated and versioned, with the floor kept separate from what this brand avoids.
Take the list work off the buyer
The classification, the list difference and the filter proposal are done before a buyer opens the platform, so the hour goes on the boundary rather than the spreadsheet.
Surface what it could not read
Inventory in a language or format the classifier is weak on is marked unclassified and sent to a person now, instead of scoring as low risk and running while the report says it was read.
Build an evidence trail
Retain the policy version, the classification and its evidence, every block, allow and unclassified call, every boundary a person moved, and the accreditation each vendor actually holds — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Verification & classification
- IAS
- DoubleVerify
- Zefr
- Peer39
- contextual classifiers
DSPs & pre-bid controls
- DV360
- The Trade Desk
- Amazon DSP
- Platform suitability controls
Lists & supply path
- Inclusion and exclusion lists
- deal IDs
- Publisher allow-lists
- ads.txt
Agent
Brand safety & suitability
- Reads the policy
- Classifies inventory
- Proposes filters
Inventory & reporting
- Curated deals
- retail media and CTV
- Reporting warehouse
- client dashboards
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and the filter
Each control wraps the one inside it. A classification clears every layer before a filter applies — no layer makes the classifier complete.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Decide what a classification may claim
- L3
- Decides who moves a category boundary
- L4 – L5
- Keep over-blocking and the trail visible
- L6
- Pulls automation back when signals degrade
How Nestack evaluates it
Evaluate what was blocked — not only what ran.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the filter and the where-it-ran report the client sees
- E1Final-output evaluationDid the classification match a human review of the same placement?
- E2Step-level evaluationDid it read the current policy version, its tiers and the right lists?
- E3Tool evaluationDid the filter or list change reach the correct campaign and platform?
- E4False block and recallWhat was blocked that a reviewer would allow, and what adjacency was missed?
- E5Slice evaluationHow does performance change by language, format, publisher type and category?
- E6Business outcomeBlocks a person reversed, and the publishers a list cut off from revenue.
Floor — the inventory the brand actually funded
Failure modes
Where each failure originates in the agent
Seven failure modes plotted against the five stages of the agent lifecycle.
Agent lifecycle
Direction of processing →
01 · Policy & lists
1 mode
- BS-01
Policy version applied late
A boundary the client moved is not live yet.
Stage gathers
The policy, its tiers, the lists and their versions
02 · Classification
2 modes
- BS-02
Journalism blocked on a keyword
The word is present; the reporting is defunded.
- BS-03
Identity vocabulary read as risk
A community's own words are scored as unsafe content.
Stage classifies
Category, risk tier, confidence and the evidence
03 · Filter / write
2 modes
- BS-04
Adjacency the brand cared about
Inside the floor, outside the client's own line.
- BS-05
Made-for-advertising cleared
It clears the category check and nobody meant to buy it.
Stage applies
Only the filters and list changes a person approved
04 · Reporting
1 mode
- BS-06
Unread inventory reported clear
Non-English and audio never got a reading.
Stage returns
The where-it-ran report the client and the lead read
05 · Change / Version
1 mode
- BS-07
Vendor taxonomy shifts unseen
A vendor redefines a category and the policy does not.
Stage tracks
Model, prompt, policy-version and taxonomy changes
- Sev-1 · the brand funded what it excluded
- Sev-2 · legitimate inventory is blocked
- Sev-3 · spend lands where no one looked
Affected slices
A block rate in total does not say who was blocked
A policy can look correct in aggregate while a few cohorts — news pages, non-English inventory and identity vocabulary — carry nearly all the blocks a reviewer would reverse. Nestack reports performance by slice, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Identity and social-issue terms | 5.9% | 3.8× | Review | |
| News and breaking-event pages | 4.5% | 2.9× | Review | |
| Non-English pages and video | 2.9% | 1.9× | Watch | |
| Steady-state curated deals | 0.9% | 0.6× | Normal |
Bar: false-block lift vs. curated-deal baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
Nobody is updating the categories you inherited
The shared category definitions were written by a group that has closed. They live on inside vendor tools, so a cycle that never re-reads them drifts.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
False blocks, missed adjacency or reviewer reversals move in one slice.
- 02
Diagnose
Traced to a list, a keyword, the classifier, the policy version or a vendor category.
- 03
Improve
The list, rule or boundary is changed, re-approved by the policy owner and version-linked.
- 04
Verify
Re-run against reviewed placements, including the ones a person reversed.
- 05
Learn
The reversal becomes a regression case and the boundary enters the policy record.
Learn → Detect
The return edge. Each cycle re-dates the lists and re-reads the vendor categories, because nobody outside your policy record keeps them current.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, policy and lists, classification and filtering, evaluation, reporting, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Policy discovery and automation-boundary definition.Week 1
- 02Floor and tier definition with the policy owner.Week 1, Week 2
- 03Inclusion, exclusion and allow-list inventory.Week 1, Week 2
- 04Verification and classification vendor connections.Week 2
- 05Content and inventory classification logic.Week 2, Week 3
- 06Pre-bid filter and post-bid flag configuration.Week 3
- 07News and sensitive-event adjacency rules.Week 3, Week 4
- 08Flagged-placement review workflow.Week 4
- 09False-block sampling against human review.Week 4, Week 5
- 10Evaluation suite, slices and regression cases.Week 4, Week 5
- 11Where-it-ran reporting into the warehouse.Week 5, Week 6
- 12Observability, deployment and Agent Care handover.Week 6
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel
Final scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
| Capability✓ in scope · — not at this tier | PilotOne brand, one channel | ProductionProduction pre-bid controls | AdvancedMulti-market / multi-channel |
|---|---|---|---|
| Introduced at Pilot | |||
| Policy and tier configuration | ✓ | ✓ | ✓ |
| Content and inventory classification | ✓ | ✓ | ✓ |
| Inclusion and exclusion list management | ✓ | ✓ | ✓ |
| Named policy-owner sign-off | ✓ | ✓ | ✓ |
| Baseline evaluation | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Pre-bid filters on approved platforms | — | ✓ | ✓ |
| Flagged-placement review workflow | — | ✓ | ✓ |
| False-block sampling against human review | — | ✓ | ✓ |
| Where-it-ran reporting and observability | — | ✓ | ✓ |
| Introduced at Advanced | |||
| News and sensitive-event adjacency rules | — | — | ✓ |
| Multi-language and enterprise controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on the channels and platforms in scope, the number of suitability policies, verification vendors, review controls, reporting depth and deployment requirements.
- Separate from build
- Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bring
We build with it
01Your suitability policy, and the person who owns it
→Policy discovery and automation-boundary definition
Week 102Where the floor ends and your own line begins
→Floor and tier definition with the policy owner
Week 103The inclusion, exclusion and allow-lists you run today
→List inventory, de-duplication and version control
Week 204Access to your verification, DSP and reporting APIs
→Vendor connections and content classification logic
Week 205The position you want to hold on news and live events
→Adjacency rules and flagged-placement review workflow
Week 306Placements you regretted, and blocks you had to reverse
→Evaluation suite, false-block sampling and regression cases
Week 407Named policy owners and reviewers
→Review routing, where-it-ran reporting and production validation
Weeks 5–6
Nothing else is required
Deployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy. Week 5 carries both the false-block sampling and the first filters applied to a live campaign.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Policy in scope, where the floor ends and who owns the line
W2Vendor connections, list inventory and the classification baseline
W3Pre-bid filters, post-bid flags and news adjacency rules
W4Review workflow, false-block sampling and evaluation slices
W5First filters applied under approval and targeted corrections
W6Where-it-ran reporting, production validation and Agent Care handover
- Reading the band
- The false-block sample and the review workflow are built in week 4, before a filter touches a live campaign in week 5. The bars show that dependency, not a smooth ramp.
- At the end of W6
- Filters have run under a named owner's approval and a blocked sample has been read back by a person, then Agent Care takes over monitoring.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Advertising AI agent
Build a brand-safety agent around your own suitability policy.
Show us the policy you run today, the lists behind it and the last few placements you had to explain to a client. We'll run one channel through classification and read a sample of what your lists block against a human review, so you see both sides of the error before anything is scoped.
- Typical delivery
- 4–6 weeks
- Deployment
- Your ad and verification stack
- Policy sign-off
- Named owner, always
- After launch
- Agent Care available
Nestack Agents · Brand safety & suitability
AGT-AM-07 · Agent Care available after launch
