Nestack Agent Care
Industries / Advertising & Marketing / Publisher yield agent

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.

4–6 weeksTypical delivery
Your stackDeployment
Pre-publicationOps-lead approval
Agent CareAfter launch

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

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

5DecisionBranches at the confidence threshold
High confidence

Goes to the ops lead to approve.

Low confidence

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 required8 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 boundaryAgent 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 propertyIllustrative example
Property
Finding
Record status
Evidence source
Confidence
Attribution
Mid-tier sports domain
Reseller present in ads.txt but absent from its own sellers.json listing
sellers.json: absent
This week's file crawl
88%
Ops-lead name on file
As receivedTaken 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 flaggedThe ads.txt file matches and a person still decides and it is logged..
ActionApproveEditEscalate
What the score decidesBelow the configured threshold the flag picks up a second review before it reaches the ops lead.

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value landsValue 01 – 04
Every propertyFrom the seller-record feed
03Checking

Cross-check every property's file

Cross-check each domain's ads.txt against every counterparty's sellers.json entry.

01Approved path

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.

02Human review

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.

04Build 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 & inventoryGoogle Ad Manager · Prebid
Xandr · Equativ
Seller-record filesads.txt · app-ads.txt
sellers.json · SupplyChain
Programmatic demandSSP 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 workflowTicketing · approval tools
Slack · email escalation
Observability & evaluationOpenTelemetry · 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 defenceInward → L1 · closest to the model
L6Rollback / safe modeFall back to reporting only when evaluation or production signals degrade.Roll back
L5Version monitoringTrack changes to the model, prompt, taxonomy version and seller-file rules.Track
L4TraceabilityRecord the file checked, the mismatch found, the evidence and the ops lead's decision.Record
L3Ops-lead approvalHold the change for the named ops lead; it governs publish, not whether the record is accurate.Gate
L2Policy guardrailsTest every change against configured floor limits and seller-file rules; a failure returns it.Restrict
L1Confidence thresholdsRoute low-confidence matches and floor changes to a second ops review.Require review
Model coreRecommendation proposed — record check, floor evidence and confidence
L1 – L2Test whether a flag may stand
L3Puts the change in the ops lead's hands
L4 – L5Keep the record and the source behind it
L6Falls 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
Depth of coverage ▼
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 lifecycleDirection of processing →
01 · Retrieval1 mode
SY-03

Cached file snapshot

The seller file read is a cached copy, not this domain's live version.

Stage gathersSeller files, sellers.json entries, delivery data and floor history
02 · Reasoning2 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 proposesRecord mismatch, evidence read and confidence
03 · Tool / write2 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 writesOnly where write access and approval policy allow it
04 · Output1 mode
SY-01

Trade-off omitted

A floor or fill recommendation reaches the ops lead with no reader-experience trade-off attached.

Stage returnsThe record and flag the ops lead approves
05 · Change / Version1 mode
SY-07

Silent taxonomy drift

An MFA taxonomy or model version update widens what the agent will flag as a match.

Stage tracksModel, 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 aggregateIllustrative example
SliceFailure rateLift Lift vs. thresholdStatus
Newly acquired or migrated domains7.6%3.9× Review
Inventory resold through intermediaries5.1%2.9× Review
App and CTV properties3.4%1.8× Watch
Owned-and-operated web domains1.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 stagesSwitchback — the path turns at Improve and returns at Learn
01Detect

Record-defect rate rises in a property slice.

02Diagnose

The seller record that was still correct last quarter is checked against every property until one domain explains it.

03Improve

The fix ships against a version, with the domains that exposed it attached.

04Verify

Release is held until the affected listing cases pass again.

05Learn

The case joins the permanent suite and the seller rules move with it.

Learn → DetectThe 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..
02Ad-server, SSP and file-host assessment.
03Seller-file and floor-policy rule mapping and rule mapping.
04Record intake and property normalisation.
05Cross-check logic and evidence binding.
06Confidence scoring and mismatch routing.
07Ops-lead approval workflow.
08Ad-server and SSP integration.
09Authorised-seller regression cases.
10Guardrails and publishing controls.
11Domain-trail instrumentation.
12Deployment, documentation and Agent Care handover.
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 priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild 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 bringWe build with it
01Your property list and current seller-file setup Property ingestion and record mappingWeek 1
02Representative seller-file history Cross-check baseline and evidence bindingWeek 2
03Your floor policy and approved change rules Floor-policy and approval-boundary mappingWeek 1
04Access to relevant APIs, feeds or exports Ad-server and SSP assessment, then integration setupWeek 2
05Records you would not want published Spoofing cases and failure-mode testingWeek 4
06What no listing may assert Confidence scoring, mismatch routing, guardrails and approval controlsWeek 3
07Named ops leads to review flags Ops-lead approval workflow, then pilot and production validationWeeks 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 W1W2W3W4W5W6
Discovery W1
Build W2 – W3
Evaluate W4 – W5
Pilot & Launch W5 – 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 bandA bar spans only the weeks its work is named in — the week 5 overlap is real, not padding.
At the end of W6Validation closes on live domains, and Agent Care picks up monitoring.
DurationSix-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.

Nestack Agents · Publisher yield & integrityAGT-AM-13 · Agent Care available after launch