Main site

Advertising AI agent · Spend pacing

Spend-Pacing & Anomaly-Triage AI Agent

Watch spend against budget and flight, catch under- and over-pacing and cost breaks early, tell a real change from a reporting artefact, and escalate with evidence — a named owner decides whether money moves.

Typical delivery
4–6 weeks
Deployment
Your stack
Pause decision
Owner or pre-set
After launch
Agent Care

What this agent does

Watches the money, wakes the right person

In

  1. 01

    Read the released budget, the flight dates and the pacing target for every line in scope.

  2. 02

    Pull spend and delivery from each platform on a fixed interval, with the pull time recorded.

Reason

  1. 03

    Compare spend to date against the flight's own curve, not a flat line drawn through the budget.

  2. 04

    Separate a real change from a restated figure, a missing pull or the platform's own pacing rules.

  3. 05

    Group related signals into one incident, so a single upstream break is not seven separate alerts.

Decide

  1. 06

    Rank by the money at stake and the time already elapsed — under-delivery is ranked, not ignored.

  2. 07

    Escalate to the named owner with the evidence, the likely cause and the actions open to them.

Out

  1. 08

    Raise the incident on the rota and hold it open until a person records what they decided.

  2. 09

    Retain every alert, the data it fired on, what it was later confirmed to be, and who acted.

Product statement

The agent watches, classifies and escalates. A named owner decides whether to pause, move or leave money alone, and any automatic pause is a pre-authorised exception with a stated limit.

Example workflow

One anomaly, end to end

  1. 1Pacing checkedSpend to date against the released budget and the flight's own curve, on the interval agreed with the client
  2. 2Signal raisedAn over- or under-pace, a cost or delivery break, or a line that has stopped spending altogether
  3. 3Data tested firstWhether the figure has settled, whether a pull returned nothing, and what the platform is itself allowed to spend
  4. 4Incident assembledRelated signals grouped, the money at stake sized, the likely cause named and the actions open to the owner listed

No human action required

Stages 1 to 4 run without a person in the loop — the pull, the data test and the grouped incident are finished before anyone's phone rings.

5DecisionSplits on whether the change is confirmed and how much money is moving
Explained by the data

Closed with the reason recorded.

Real, and money is moving

Paged to the owner on the rota.

Named owner

The owner reads the evidence, the money at stake and what was ruled out, then decides whether to pause, move or leave it alone.

Pause · Adjust · Leave it

Decided — handed back

  1. 6Owner acts, agent followsOnly what was pre-authorised is applied; the line is watched until the next settled figure agrees
  2. 7Outcome evaluatedWhether the alert was real, how long detection took, what the owner did, and how many alerts closed as noise

Pre-authorised pauses

A pause covers one line, for a stated ceiling, and any owner can reverse it.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Pausing anything outside the pre-authorised lines.
    • Raising, lowering or moving a budget or cap.
    • Closing an anomaly as not worth acting on.
    • Muting or suppressing an alert for a client.

  • Automation boundary

    Agent acts unaided

    • ✓Read released budgets, flights and delivery from every platform in scope.
    • ✓Test whether a figure has settled before treating it as a change.
    • ✓Group related signals into one incident and size the money at stake.
    • ✓Escalate to the named owner with the evidence and the actions open to them.

    Write actions run only inside the approval boundaries agreed during implementation. A pause runs unattended only on lines the client authorised in writing, with a ceiling, a window and a reversal.

    • Changing a pacing threshold, baseline or alert rule.
    • Telling a client that spend or delivery went wrong.
    • Claiming a make-good or a credit from a platform.
  • Turning monitoring off for a campaign or a client.

Example output

One alert, annotated

Everything the agent raises is attached to the pull and the released budget it came from.

Pacing alert · single line item

Illustrative example
Line item
Paid social, one market
Flight
Day 6 of 14
Released budget
$120,000
Classification
Over-pacing, confirmed
Confidence
88%
Status
Paged to the owner

As received

The line, its flight and the budget released against it — nothing on this side is inferred.

Evidence used

  • Two pulls, both settled
  • Platform pacing allowance
  • Flight curve to date

Why it was raised

Past the allowance the platform grants itself, on a day that has already settled.

What the score decides

Whether the owner is paged now or reads it at the stand-up — not whether to pause.

Action

PauseAdjustLeave it

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 line, every interval

From the platforms and the budget record

03Triage

Test the data before raising it

Check whether the figure has settled, whether a pull returned nothing and whether the platform is inside its own pacing allowance, before anything reaches a person.

01Approved path

Take the watching off the team

Pacing is checked on an interval through the night and the weekend, so the first person to look is reading an assembled incident rather than opening a dashboard.

02Human review

Escalate with enough to act on

The owner receives the money at stake, the likely cause, what was ruled out and the actions open to them, so triage takes minutes instead of starting from nothing.

04

Build an evidence trail

Retain the alert, the data it fired on, what was ruled out, who was paged, what they decided and what it was later confirmed to be — on both paths.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Ad platforms

    • Google Ads
    • DV360
    • Meta
    • The Trade Desk
    • Amazon Ads
    • retail media

  • Budget & flight record

    • Media plans
    • flights and IOs
    • Order management
    • finance systems

  • Alerting & on-call

    • Slack and Teams
    • email
    • PagerDuty and Opsgenie
    • on-call rotas

Agent

Spend pacing & anomaly triage

  • Watches pacing
  • Tests the data
  • Escalates to owner

  • Warehouse & incidents

    • BigQuery
    • Snowflake
    • dbt
    • Jira and ServiceNow
    • incident records

  • 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 a signal and a pause

Each control wraps the one inside it. A signal clears every layer before anyone is paged, and the decision to stop spending sits outside all six.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeReverse a pause and hand watching back to the team on a rota.Roll back
L5TraceabilityRecord the alert, what was ruled out, who was paged and what they did.Record
L4Blast radiusA pre-authorised pause covers one line, to a stated ceiling and window.Limit
L3Named-owner gateNo spend is paused, raised or moved without the owner or a pre-authorisation.Gate
L2Materiality gateMoney at stake and elapsed time decide whether anyone is told at all.Rank
L1Settlement testNothing is raised on an unsettled figure or an empty pull.Test
Model coreSignal raised — the pacing or cost break, the money at stake and confidence
L1 – L2
Decide whether the signal is real
L3
Decides who may stop the money
L4 – L5
Keep any pause small and reversible
L6
Pulls automation back when signals degrade

How Nestack evaluates it

Evaluate the alerts it raised — and the ones it never sent.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the alert the owner on the rota reads

  1. E1Final-output evaluationWas the anomaly real, and was it classified correctly?
  2. E2Step-level evaluationDid it read the right budget, flight, currency and day boundary?
  3. E3Tool evaluationDid it pull the correct account, campaign and line, and nothing else?
  4. E4Alert precision and recallAre flagged anomalies real, and which real ones were missed?
  5. E5Slice evaluationHow does performance change across platforms, hours and client sizes?
  6. E6Business outcomeTime to detection, time to first action, and alerts closed as noise.

Floor — the money caught in time, in both directions

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 · Data pull

    1 mode

    • SP-01

      Real overspend seen too late

      Reporting lags the money by hours, and the flight is short.

    Stage gathers

    Spend, delivery and the budget released per line

  2. 02 · Detection

    2 modes

    • SP-02

      Planned peak paged as a break

      A planned promotion or seasonal shift reads as an anomaly.

    • SP-03

      Alert fatigue in the channel

      Overdelivery the platform allows is paged until nobody looks.

    Stage tests

    Spend to date against the flight's own pacing curve

  3. 03 · Classification

    1 mode

    • SP-04

      Raised on unsettled data

      The figure moves again after the incident is opened.

    Stage sorts

    Real change, reporting artefact or platform behaviour

  4. 04 · Escalation

    2 modes

    • SP-05

      Alert with nothing to act on

      Triage takes as long as investigating from scratch.

    • SP-06

      Nobody on the rota at 2am

      The spend runs on for hours until someone opens a laptop.

    Stage raises

    The incident, the money at stake and who is paged

  5. 05 · Change / Version

    1 mode

    • SP-07

      Threshold left behind by the budget

      The budget changed and the pacing baseline did not.

    Stage tracks

    Model, prompt, threshold and alert-rule changes

  • Sev-1 · money moves and nobody is told
  • Sev-2 · a real incident is buried or arrives late
  • Sev-3 · a false alert costs the team an hour
See the complete Advertising failure-mode catalogue

Affected slices

Most of the noise comes from a few cohorts

Alert precision can look acceptable in total while a handful of platforms, hours and account sizes produce most of the false alerts, most of the late detections and nearly all of the incidents nobody was paged for. Nestack reports performance by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Overnight and weekend windows5.2%2.8×Review
Platforms that restate late3.9%2.1×Review
Promotional and seasonal peaks3.0%1.6×Watch
Large steady always-on accounts1.4%0.8×Normal

Bar: failure-rate lift vs. steady-account baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

The alerts that never fired are the expensive ones

Precision is easy to see and recall is not. Every cycle re-reads the quiet periods as well as the loud ones, because a miss leaves no alert behind to review.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Alert precision, detection time or a missed incident moves on one platform or client.

  2. 02

    Diagnose

    Traced to the pull, the settlement test, a threshold, a baseline or the escalation rule.

  3. 03

    Improve

    The threshold, baseline or routing is changed, re-approved by the operations lead and version-linked.

  4. 04

    Verify

    Re-run against recorded incidents, including the ones nobody was paged for.

  5. 05

    Learn

    The miss becomes a regression case and the threshold enters the pacing runbook.

  6. Learn → Detect

    The return edge. A threshold is only as current as the budget behind it, so every cycle re-reads the thresholds against the flights running now.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, pulls and pacing arithmetic, detection and escalation, evaluation, on-call integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Monitoring discovery and automation-boundary definition.Week 1
  2. 02Budget, flight and pacing-target record.Week 1, Week 2
  3. 03Reporting API and data-latency assessment.Week 1, Week 2
  4. 04Scheduled pulls and day-boundary rules.Week 2
  5. 05Pacing arithmetic and allowance rules.Week 2, Week 3
  6. 06Anomaly detection and seasonality baselines.Week 3
  7. 07Settlement and restatement tests before alerting.Week 3, Week 4
  8. 08Alert grouping, severity and escalation policy.Week 4
  9. 09Precision, recall and detection-time evaluation.Week 4, Week 5
  10. 10Pre-authorised pause limits and reversal drill.Week 4, Week 5
  11. 11Warehouse, on-call and incident integration.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 client, one platformProductionProduction monitoring pipelineAdvancedMulti-client / overnight rota
Introduced at Pilot
Pacing checks against budget and flight✓✓✓
Delivery and cost anomaly detection✓✓✓
Settlement and restatement tests✓✓✓
Escalation to a named owner✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Alert grouping and severity policy—✓✓
Seasonality and promotion baselines—✓✓
On-call routing and incident records—✓✓
Precision and recall reporting—✓✓
Introduced at Advanced
Pre-authorised pause with stated limits——✓
Multi-client and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on the platforms and clients in scope, reporting latency, alerting and on-call tooling, pause authorisation and limits, 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. 01The budgets, flights and pacing targets in scope

    Budget, flight and pacing-target record

    Week 1

  2. 02Access to the platform reporting APIs you buy on

    Reporting API and data-latency assessment

    Week 2

  3. 03Your markets, currencies and reporting day boundary

    Scheduled pulls and day-boundary rules

    Week 2

  4. 04The promotions and seasonal peaks already planned

    Anomaly detection and seasonality baselines

    Week 3

  5. 05Who is on call, and who may pause spend today

    Alert grouping, severity and escalation policy

    Week 4

  6. 06Incidents you had, and the alerts you ignored

    Evaluation suite, regression cases and failure-mode testing

    Week 4

  7. 07What may be paused without asking, and up to what

    Pre-authorised pause limits, then the reversal drill

    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 evaluation slices and the first alerts reaching a live on-call rota.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Budgets, flights and pacing targets; who may pause spend

W2Platform pulls, day boundaries and reporting-latency limits

W3Pacing arithmetic, seasonality baselines and settlement tests

W4Alert grouping, escalation policy and the precision-recall suite

W5First alerts on a live rota, the pause drill and corrections

W6Production validation, threshold review and Agent Care handover

Reading the band
The pause limits and the reversal are drilled before any alert is allowed to stop spend, not after. The bars show that dependency, not a smooth ramp.
At the end of W6
Alerts have run on a live rota through at least one weekend, and every threshold has been re-read against the flights running now, 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 spend-pacing agent around your budgets and your rota.

Show us the last three pacing incidents you had, how long each took to notice and who was allowed to stop the spend. We'll replay those three against your own reporting latency and show you which ones this agent would have caught, and which ones it would still have missed.

Typical delivery
4–6 weeks
Deployment
Your buying and alerting stack
Pause decision
Named owner, or pre-authorised
After launch
Agent Care available

Nestack Agents · Spend pacing & anomaly triage

AGT-AM-10 · Agent Care available after launch

Build a spend-pacing 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.