Advertising AI agent · Publisher yield
Publisher Yield & Supply-Chain Integrity AI Agent (Sell-Side)
Keep authorised-seller records accurate across every property, watch for inventory represented by parties who shouldn't be, and prepare floor and yield changes with their evidence — a named ops lead publishes every change.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Ops-lead approval
- Pre-publication
- After launch
- Agent Care
What this agent does
Checks the record, not the decision to publish it
In
- 01
A seller file is pulled from every property — ads.txt, app-ads.txt and the ad server's record.
- 02
The SupplyChain object is read alongside it, as the payment path it shows and nothing more.
Reason
- 03
A declared seller is checked against the domain's own file and that counterparty's sellers.json listing.
- 04
A mismatch — a cloned file, a stale domain, an unlisted reseller — is flagged with its evidence.
- 05
A floor or yield change is drafted with the fill, price and reader trade-off it is projected to cause.
Decide
- 06
A direct-sold order is checked against ad-server delivery before any yield change is proposed.
- 07
Every flag, mismatch and floor change is routed to the named ops lead, never resolved alone.
Out
- 08
The file checked, the mismatch found and the ops lead's decision are retained against the property.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent checks records and prepares evidence with the trade-off attached; the named ops lead decides what publishes, because the reader isn't in the auction.
Example workflow
One change, signal to publish
- 1Signal receivedProperty refresh, floor-change request, direct-sold order or a spoofing alert
- 2Evidence assembledSeller files, sellers.json entries, delivery data and floor history, each with its source
- 3Change draftedRecord correction, floor or yield adjustment, flagged mismatch and confidence
- 4Controls appliedCross-file checks, trade-off log, spoof-pattern checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing changes at any of them — the agent recommends, and the ops lead's lane opens at the confidence gate.
Goes to the ops lead to approve.
Adds a second review first.
Ops-lead review
The change is held with its evidence, its flagged mismatches and the confidence.
Approve · Edit · Escalate
Approved — published live
- 6Live systems updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedRecord accuracy, flag outcomes, floor performance and post-publish corrections
Edits
Every ops-lead edit is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Publishing any change to a live seller record.
- Changing a floor price or yield rule.
- Blocking or terminating a buyer or reseller.
- Accepting or rejecting a direct-sold order.
Automation boundary
Agent acts unaided
- ✓Cross-check every property's authorised-seller file.
- ✓Read the SupplyChain object as payment-flow evidence, never as full technical custody.
- ✓Name the MFA taxonomy and version behind any classification it reports.
- ✓Flag a record mismatch or yield trade-off for the ops.
Any write happens inside the boundaries agreed at implementation, never ahead of approval.
- Asserting that inventory is fraudulent or spoofed.
- Committing to a remedy outcome in the Google ad-tech case.
- Adding a new authorised reseller to the file.
- Changes to taxonomy definitions, floor policy or approval rules.
Example output
One seller-file check, annotated
Everything the agent flags is attached to the record it was drawn from.
Publisher-yield output · single property
Illustrative example- Property
- Mid-tier sports domain
- Finding
- Reseller present in ads.txt but absent from its own sellers.json listing
- Record status
- sellers.json: absent
- Evidence source
- This week's file crawl
- Confidence
- 88%
- Attribution
- Ops-lead name on file
As received
Taken from this week's ads.txt crawl and the counterparty's sellers.json — nothing on this side is written by the agent.
Records checked
- Live ads.txt crawl
- Counterparty sellers.json
- SupplyChain payment path
Why it's flagged
The ads.txt file matches and a person still decides and it is logged..
What the score decides
Below the configured threshold the flag picks up a second review before it reaches the ops lead.
Action
ApproveEditEscalateValue
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 property
From the seller-record feed
Cross-check every property's file
Cross-check each domain's ads.txt against every counterparty's sellers.json entry.
A file is not a guarantee
ads.txt and sellers.json let buyers cross-check who may sell your inventory — nothing in either file stops a bad actor from cloning it wholesale onto a lookalike domain.
Send review to the flagged mismatches
Cloned files, unlisted resellers and floor changes are marked, so the ops lead's read starts where risk concentrates.
Build an evidence trail
The record, the source it was read from and the ops lead who published it stay on the domain.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Ad server & inventory
- Google Ad Manager
- Prebid
- Xandr
- Equativ
Seller-record files
- ads.txt
- app-ads.txt
- sellers.json
- SupplyChain
Programmatic demand
- SSP and exchange feeds
- Direct-sold order data
Agent
Publisher yield & supply-chain integrity
- Reads the file
- Flags the mismatch
- Holds for the ops lead
Ops workflow
- Ticketing
- approval tools
- Slack
- email escalation
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 record
Each control wraps the one inside it. What the stack does not catch is named in the map below it.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a flag may stand
- L3
- Puts the change in the ops lead's hands
- L4 – L5
- Keep the record and the source behind it
- L6
- Falls back to reporting only when signals degrade
How Nestack evaluates it
Evaluate the checking workflow — not only the final flag.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the record buyers see
- E1Final-output evaluationDid the flagged mismatch match the live seller-record files?
- E2Step-level evaluationDid the agent use the current file, taxonomy version and floor history?
- E3Tool evaluationDid it read the correct property and the correct counterparty file?
- E4Confidence calibrationDo low-confidence flags actually attract more ops-lead escalations?
- E5Slice evaluationHow does accuracy change across specific property types?
- E6Business outcomeHow many flags needed an ops-lead correction after publish?
Floor — the outcome the publisher answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, mapped to where the agent introduces each one.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- SY-03
Cached file snapshot
The seller file read is a cached copy, not this domain's live version.
Stage gathers
Seller files, sellers.json entries, delivery data and floor history
02 · Reasoning
2 modes
- SY-04
Cross-taxonomy MFA claim
An MFA clearance from one vendor's taxonomy is reported as if every taxonomy agrees.
- SY-06
Payment path read as full trail
SupplyChain data is read as the technical path, not just who gets paid.
Stage proposes
Record mismatch, evidence read and confidence
03 · Tool / write
2 modes
- SY-02
Parse failure misread
A sellers.json fetch error is treated as proof a partner is unauthorised.
- SY-05
First-price model, hybrid path
A floor model trained on first-price data runs unadjusted against a second-price path.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- SY-01
Trade-off omitted
A floor or fill recommendation reaches the ops lead with no reader-experience trade-off attached.
Stage returns
The record and flag the ops lead approves
05 · Change / Version
1 mode
- SY-07
Silent taxonomy drift
An MFA taxonomy or model version update widens what the agent will flag as a match.
Stage tracks
Model, MFA taxonomy version and it is logged.
- Sev-1 · change published outside the boundary
- Sev-2 · a wrong flag reaches the ops lead
- Sev-3 · file degrades, flag routes to review
Affected slices
Network health can hide one weak property
A network-wide record score can look clean while a handful of properties carry most of the defects. Nestack reports the record-defect rate by property, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Newly acquired or migrated domains | 7.6% | 3.9× | Review | |
| Inventory resold through intermediaries | 5.1% | 2.9× | Review | |
| App and CTV properties | 3.4% | 1.8× | Watch | |
| Owned-and-operated web domains | 1.9% | 0.8× | Normal |
Bar: record-defect rate lift vs. the owned-and-operated baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
The loop closes on a case, not a fix
A cycle closes when the spoofed listing is a case the next release has to survive. That suite is what the next file published is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Record-defect rate rises in a property slice.
- 02
Diagnose
The seller record that was still correct last quarter is checked against every property until one domain explains it.
- 03
Improve
The fix ships against a version, with the domains that exposed it attached.
- 04
Verify
Release is held until the affected listing cases pass again.
- 05
Learn
The case joins the permanent suite and the seller rules move with it.
Learn → Detect
The return edge. The next check runs against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, checking workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Ad-ops discovery and boundary definition and it is logged..Week 1
- 02Ad-server, SSP and file-host assessment.Week 1, Week 2
- 03Seller-file and floor-policy rule mapping and rule mapping.Week 1, Week 2
- 04Record intake and property normalisation.Week 2
- 05Cross-check logic and evidence binding.Week 2, Week 3
- 06Confidence scoring and mismatch routing.Week 3
- 07Ops-lead approval workflow.Week 3, Week 4
- 08Ad-server and SSP integration.Week 5
- 09Authorised-seller regression cases.Week 4, Week 5
- 10Guardrails and publishing controls.Week 4
- 11Domain-trail instrumentation.Week 5, Week 6
- 12Deployment, documentation 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 property, one server | ProductionProduction ad-server access | AdvancedMultiple properties / brands |
|---|---|---|---|
| Introduced at Pilot | |||
| Checks against your files and rules | ✓ | ✓ | ✓ |
| Ops-lead approval | ✓ | ✓ | ✓ |
| Record-accuracy baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by property | — | ✓ | ✓ |
| Escalation workflow in your tools | — | ✓ | ✓ |
| Approved record updates | — | ✓ | ✓ |
| Ad-server integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-taxonomy MFA rules | — | — | ✓ |
| Multi-stage ops approvals | — | — | ✓ |
| High request volume | — | — | ✓ |
| Multi-property seller controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls 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 property list and current seller-file setup
→Property ingestion and record mapping
Week 102Representative seller-file history
→Cross-check baseline and evidence binding
Week 203Your floor policy and approved change rules
→Floor-policy and approval-boundary mapping
Week 104Access to relevant APIs, feeds or exports
→Ad-server and SSP assessment, then integration setup
Week 205Records you would not want published
→Spoofing cases and failure-mode testing
Week 406What no listing may assert
→Confidence scoring, mismatch routing, guardrails and approval controls
Week 307Named ops leads to review flags
→Ops-lead approval workflow, then pilot 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
Each band covers the weeks the work really takes, which is why week 5 carries evaluation and pilot together.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Ad-ops discovery, floor-policy mapping and the automation boundary
W2Source integration and the cross-check baseline
W3Checking workflow, confidence logic and approval controls
W4Evaluation suite, guardrails and failure-mode testing
W5Ad-server integration, pilot properties and targeted corrections
W6One reporting cycle run under the ad-ops lead, then Agent Care handover
- Reading the band
- A bar spans only the weeks its work is named in — the week 5 overlap is real, not padding.
- At the end of W6
- Validation closes on live domains, and Agent Care picks up monitoring.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Advertising AI agent
Build a publisher-yield agent around your ad-ops workflow.
Show us your properties, your seller-file setup and who signs off on changes. If a property's record has drifted from what its resellers report, we'll map the check, set the automation boundary and name what stays with the ops lead.
- Typical delivery
- 4–6 weeks
- Deployment
- Your ad server and SSPs
- Ops-lead approval
- Pre-publication
- After launch
- Agent Care available
Nestack Agents · Publisher yield & integrity
AGT-AM-13 · Agent Care available after launch