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

  1. 01

    Read the brand's suitability policy, its inclusion and exclusion lists, and the version each of them is on.

  2. 02

    Take the inventory as it arrives — domain, app, channel, page, video, podcast or retail-media placement.

Reason

  1. 03

    Classify content and inventory against the policy's categories and risk tiers, and record which tier it fell in.

  2. 04

    Keep the floor a brand will not fund separate from the tiers that this brand alone has chosen to avoid.

  3. 05

    Mark anything it could not read — wrong language, non-text format, thin page — as unclassified, not as safe.

Decide

  1. 06

    Propose pre-bid filters and post-bid flags, and hold every list change and category move for the policy owner.

  2. 07

    Route flagged placements, news and sensitive-event adjacency and unclassified inventory to human review.

Out

  1. 08

    Write approved list changes to the platforms that accept them, and report where ads ran and what went unread.

  2. 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

  1. 1Placement seenA bid request or a delivered impression on a domain, app, channel, video, podcast or retail-media placement
  2. 2Policy and lists readThe brand's suitability policy, its tiers, its lists and the version each is on, stamped with the time read
  3. 3Content classifiedCategory and risk tier against that policy, with the language, format and evidence the classification rests on
  4. 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.

5DecisionSplits on classification confidence and whose line the category sits on
Classified, inside the floor

Reaches the policy owner ready to apply.

Unclassified or on the brand's own line

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

  1. 6Lists and reports updatedOnly the list changes a person approved, then the where-it-ran report back to the client
  2. 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 back

Value

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

03Suitability policy

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.

01Approved path

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.

02Human review

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.

04

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

L6Rollback / safe modeReturn filtering to the buying team if evaluations or signals degrade.Roll back
L5TraceabilityRecord the policy version, the classification, its evidence and every override.Record
L4Over-block controlBlocks are sampled against human review before they widen across campaigns.Sample
L3Policy-owner gateNo boundary moves and no list change applies until a named owner clears it.Gate
L2Floor and tier splitThe safety floor stays separate from the tiers this brand alone avoids.Separate
L1Unread handlingWhat the classifier could not read is marked unclassified, never safe.Mark
Model coreProposal — classification, risk tier, confidence, and the filter or list change it implies
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

  1. E1Final-output evaluationDid the classification match a human review of the same placement?
  2. E2Step-level evaluationDid it read the current policy version, its tiers and the right lists?
  3. E3Tool evaluationDid the filter or list change reach the correct campaign and platform?
  4. E4False block and recallWhat was blocked that a reviewer would allow, and what adjacency was missed?
  5. E5Slice evaluationHow does performance change by language, format, publisher type and category?
  6. 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 →

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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
See the complete Advertising failure-mode catalogue

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
SliceFailure rateLiftLift vs. thresholdStatus
Identity and social-issue terms5.9%3.8×Review
News and breaking-event pages4.5%2.9×Review
Non-English pages and video2.9%1.9×Watch
Steady-state curated deals0.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

  1. 01

    Detect

    False blocks, missed adjacency or reviewer reversals move in one slice.

  2. 02

    Diagnose

    Traced to a list, a keyword, the classifier, the policy version or a vendor category.

  3. 03

    Improve

    The list, rule or boundary is changed, re-approved by the policy owner and version-linked.

  4. 04

    Verify

    Re-run against reviewed placements, including the ones a person reversed.

  5. 05

    Learn

    The reversal becomes a regression case and the boundary enters the policy record.

  6. 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

  1. 01Policy discovery and automation-boundary definition.Week 1
  2. 02Floor and tier definition with the policy owner.Week 1, Week 2
  3. 03Inclusion, exclusion and allow-list inventory.Week 1, Week 2
  4. 04Verification and classification vendor connections.Week 2
  5. 05Content and inventory classification logic.Week 2, Week 3
  6. 06Pre-bid filter and post-bid flag configuration.Week 3
  7. 07News and sensitive-event adjacency rules.Week 3, Week 4
  8. 08Flagged-placement review workflow.Week 4
  9. 09False-block sampling against human review.Week 4, Week 5
  10. 10Evaluation suite, slices and regression cases.Week 4, Week 5
  11. 11Where-it-ran reporting into the warehouse.Week 5, Week 6
  12. 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 tierPilotOne brand, one channelProductionProduction pre-bid controlsAdvancedMulti-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 priceFrom $5,000From $8,000Custom 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.

  1. 01Your suitability policy, and the person who owns it

    Policy discovery and automation-boundary definition

    Week 1
  2. 02Where the floor ends and your own line begins

    Floor and tier definition with the policy owner

    Week 1
  3. 03The inclusion, exclusion and allow-lists you run today

    List inventory, de-duplication and version control

    Week 2
  4. 04Access to your verification, DSP and reporting APIs

    Vendor connections and content classification logic

    Week 2
  5. 05The position you want to hold on news and live events

    Adjacency rules and flagged-placement review workflow

    Week 3
  6. 06Placements you regretted, and blocks you had to reverse

    Evaluation suite, false-block sampling and regression cases

    Week 4
  7. 07Named 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

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. 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

Build a brand-safety agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your setup

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.