Build and maintain the media plan, set up buys, propose budget shifts and pacing changes, and reconcile delivered against billed — inside spend limits a named buyer set and can revoke.
Read the approved plan, the flight dates, the committed IOs and the budget released against each line.
02
Pull spend and delivery from every platform in the buy, in the plan's currency and day boundary.
Reason
03
Compare planned against delivered against billed, line by line, and name where the gap came from.
04
Set the platform's own numbers beside the measurement the client decides on, and flag disagreement.
05
Draft a reallocation, bid or pacing change with the limit it consumes and its reversal written first.
Decide
06
Hold anything that breaches a committed IO, a market minimum, a change window or a spend limit.
07
Route every release of new spend and every shift across a client or flight to the named buyer.
Out
08
Apply released changes on the platform, one line at a time, and write the same change to the plan.
09
Retain the state it replaced, the approval, the change made and the reversal path for every action.
→Product statement
The agent proposes and executes inside limits a person set. It does not release spend, and no shift it recommends moves money until a named buyer approves it.
Example workflow
One reallocation, end to end
AgentHuman
1Plan and flight in viewThe approved plan, the flight dates, the committed IOs and the budget released against each line
2Delivery pulledSpend, impressions and pacing from every platform in the buy, in the plan's currency and day boundary
3Variance readPlanned against delivered against billed, line by line, with the platform's numbers set beside independent measurement
4Change draftedThe shift, bid or pacing change, the limit it consumes, the IO it touches and the reversal that puts it back
No human action required
Stages 1 to 4 run without a person in the loop — the delivery pull, the variance read and the drafted change are finished before the buyer is asked to look at anything.
5DecisionSplits on the size of the shift and the limits it touches
Inside every limit
Reaches the buyer ready to release.
Breaches a limit or a commitment
Held with the breach named, nothing applied.
Named buyer
The buyer checks the shift against the plan, the committed IO and the client's mandate, then releases the spend.
Release · Amend · Send back
Released — handed back▼
6Applied and watchedOnly on the lines the buyer released; spend and pacing are checked against the plan on a fixed interval
7Outcome evaluatedPlan-versus-delivered variance, guardrail breaches, reversal time and reconciliation against what was billed
Reversals
Every change carries the state it replaced, and the time taken to put it back is counted.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Releasing spend against a new flight or client.
Moving budget between clients, markets or committed IOs.
Raising any total budget, cap or daily limit.
Cancelling, pausing or short-rating a committed IO.
Automation boundaryAgent acts unaided
✓Read the plan, the committed IOs and delivery from every platform in the buy.
✓Reconcile planned against delivered and billed, and name where the gap came from.
✓Draft a reallocation with the limit it consumes and the reversal that puts it back.
✓Hold anything that breaches a limit and route it to the named buyer.
Write actions run only inside the approval boundaries agreed during implementation. Releasing spend and touching a committed IO are not among them.
Changing a bid strategy, target or pacing mode.
Making any change outside the agreed change window.
Turning on a platform auto-feature that re-spreads budget.
Changing the spend limits, guardrails or approval thresholds.
Example output
One line in the plan, annotated
Everything the agent proposes is attached to the plan line and the delivery it came from.
Reallocation output · single line itemIllustrative example
Line item
Flight
Released budget
Proposed shift
Confidence
Status
Online video, one market
Day 19 of 30
$180,000
Reallocate within IO
71%
Held for the buyer
As receivedThe plan line and the budget released against it — nothing on this side is inferred.
Why it is heldEfficient in the platform's own numbers, flat in the client's measurement.
ActionReleaseAmendSend back
What the score decidesHow closely the buyer reads before releasing — not whether the shift is the right call.
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 line in the planFrom the approved media plan
03Plan of record
Keep the plan as the record
Every platform change is written back to the plan it came from, with the limit it consumed and the state it replaced.
01Approved path
Cut the gathering before the decision
The delivery pull, the currency and day-boundary conversion and the variance read are done before a person opens the plan, so the buyer decides rather than gathers.
02Human review
Show the disagreement before money moves
Where the platform's own numbers and the client's independent measurement point different ways, the shift is held and both are put in front of the buyer.
04Build an evidence trail
Retain the state replaced, the limit consumed, who released it, the change applied, the reversal path and what was finally billed — on both paths.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Buying platformsGoogle Ads · DV360 · Meta The Trade Desk · Amazon · Retail media
Planning & order managementMedia plans · flowcharts IOs and POs · Order management
Aggregate plan-versus-delivered variance can look acceptable while a few platform and market cohorts carry most of the guardrail breaches, most of the reversals and nearly all of the reconciliation rework. Nestack reports performance by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Cross-market multi-currency buys
6.1%
3.4×
Review
Retail-media and closed platforms
4.5%
2.5×
Review
Final week of flight
3.2%
1.8×
Watch
Single-platform steady buys
1.3%
0.7×
Normal
Bar: failure-rate lift vs. steady-buy baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
The proof arrives after the money has gone
A wrong shift spends in real time; the invoice that settles it lands weeks later. Every cycle is dated twice — when it ran, and when billing confirmed it.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Variance, a guardrail breach or a reversal moves on one platform or market.
02Diagnose
Traced to the plan read, the day boundary, a limit or the measurement it trusted.
03Improve
The limit, rule or measurement source is changed, re-approved by the buyer and version-linked.
04Verify
Re-run against held-out changes from that platform, including the ones that were reversed.
05Learn
The reversal becomes a regression case and the limit enters the buying runbook.
Learn → DetectThe return edge. Every cycle re-checks against what was finally billed — a change that looked right on the day can still be wrong on the invoice.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, plan and delivery data, limits and proposals, evaluation, reconciliation, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Workflow discovery and automation-boundary definition.
02Plan, flight and committed-IO model.
03Platform and DSP API assessment.
04Currency and time-zone normalisation.
05Delivery ingestion and variance against plan.
06Reallocation, bid and pacing proposals.
07Spend limits, change windows and blast-radius rules.
08Named-buyer release and approval workflow.
09Buyer-agreement and guardrail evaluation.
10Reversal path and safe-mode drill.
11Order-management and billing reconciliation.
12Observability, deployment and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal 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 platform, one clientProductionProduction platform integrationAdvancedMulti-market / multi-platform
Introduced at Pilot
Plan and delivery reconciliation✓✓✓
Variance and pacing reporting✓✓✓
Reallocation proposals✓✓✓
Named-buyer release✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Spend limits and change windows—✓✓
Released changes on platform—✓✓
Committed-IO and minimum checks—✓✓
Reversal path and safe mode—✓✓
Introduced at Advanced
Multi-market and multi-currency——✓
Cross-client and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on the platforms and markets in scope, managed spend, order-management and finance integrations, spend limits and 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
01The plans, flights and committed IOs in scope→Plan, flight and committed-IO modelWeek 1
02Access to the platform and DSP APIs you buy on→Platform and DSP API assessment, then delivery ingestionWeek 2
03Your markets, currencies and reporting day boundary→Currency and time-zone normalisationWeek 2
04Who may release spend, and up to what→Spend limits, change windows and blast-radius rulesWeek 3
05The measurement you actually decide on→Measurement sources, and the rule that holds a shift when they disagreeWeek 3
06Reallocations you made, and ones you refused→Evaluation suite, regression cases and failure-mode testingWeek 4
07Named buyers, and the invoices to reconcile against→Named-buyer release workflow, then billing reconciliationWeeks 5–6
Nothing else is requiredDeployment, 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 buyer-agreement evaluation and the first changes applied to live budget.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Plans, flights and committed IOs; who may release spendW2Platform APIs, delivery ingestion and currency normalisationW3Variance read, reallocation proposals and spend limitsW4Buyer release workflow, the reversal drill and evaluation suiteW5First released changes on live budget, and targeted correctionsW6Billing reconciliation, production validation and Agent Care handover
Reading the bandThe reversal path is built and drilled in week 4, before a single change touches live budget in week 5. The bars show that dependency, not a smooth ramp.
At the end of W6Changes have run under named-buyer release and reconciled against what was billed, then Agent Care takes over monitoring.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Advertising AI agent
Build a media-buying agent around your plan and your limits.
Show us one client's plan, the platforms it runs on and who is allowed to release spend today. We'll take one flight end to end, agree the limits and the reversal, then scope from there.
