A first agent worth building: the revenue incident agent
Revenue is 18% below expectations at 10:30. A good agent does not guess “CPMs are down”: it tests every cause with evidence. A first use case that creates value while staying read-only.
Where should a publisher start with agents? We usually recommend a revenue incident agent. The business value is obvious, the task needs several systems, and it can start in read-only mode: you get value without letting the agent change anything in production.
Agent or plain automation?
Not everything needs an agent. If a rule can be written down, classic automation is better: export a report every morning, send an alert above a threshold, stop a process at a campaign’s end date. An agent becomes useful when the task means combining sources, interpreting context, choosing between tools, forming hypotheses and adapting the path. Explaining a drop in revenue is exactly that kind of task: traffic, fill rate, CPM, SSPs, Prebid, consent and recent changes all have to be correlated.
The aim is not to make everything agentic. Keep probabilistic reasoning for the steps that need it, then hand calculations, checks and critical writes back to deterministic services.
10:30, revenue is down 18%
Display revenue across the network is 18% below the expected curve. The wrong reaction is to conclude that CPMs are falling and recommend higher floors. The right one is to break revenue down and test each possible cause:
- Compare with the same time slot yesterday, a week ago, and a seasonal baseline.
- Break revenue into traffic × ad requests per session × fill rate × CPM, and measure each factor’s contribution.
- Slice by site, device, country, format, ad unit, demand channel and bidder.
- Check recent changes: front-end releases, consent platform, Prebid configuration, ad server, SSPs, CDN.
- Check vendor incidents and API or JavaScript errors.
- Rank hypotheses by evidence, not only by plausibility.
- Estimate the hourly cost of the incident.
- Propose a reversible action, and state the level of authorisation it needs.
| Hypothesis | Expected signal | Source | Possible action |
|---|---|---|---|
| Traffic drop | Sessions and page views fall | Analytics, CDN | Alert editorial and tech; no yield change |
| Consent issue | Consent rate changes abruptly | Consent platform, telemetry | Roll back the consent configuration after validation |
| Bidder timeout | Timeouts rise, bid rate falls | Prebid events | Disable the bidder or adjust its timeout, per policy |
| Market CPM drop | Requests and fill stable, CPM down | Ad server, SSPs | Analyse demand; avoid overreacting |
| Broken ad unit | Requests collapse on one template or ad unit | Ad server, front-end telemetry | Roll back the release or fix the placement |
The whole sequence takes about three minutes: check data freshness, then traffic, consent, the ad server, Prebid, the SSPs and the change log, then rank and decide.
What a useful answer looks like
A useful conclusion is not “revenue is probably down because of Prebid”. It reads more like this:
Traffic is stable (+0.7%) and consent is unchanged. Ad server requests are stable, but bidder X’s bid rate fell from 31% to 8% at 09:52, while its p95 timeout rose from 680 ms to 1,420 ms. Other bidders are stable. Estimated impact: €420–510 per hour. A configuration change for bidder X was deployed at 09:47. Confidence: high. Proposed action: roll back to configuration version N, then observe for 15 minutes.
Every statement is tied to a metric, a period, a source and a timestamp. Without that chain of evidence, the agent tells a plausible story that nobody can act on.
A ten-step pattern for every use case
- Observe: collect data with its timestamp, source and freshness.
- Understand: normalise metrics through the semantic layer.
- Hypothesise: list several possible causes instead of jumping to one.
- Verify: query the sources that confirm or rule out each one.
- Recommend: propose an action with expected impact, confidence and evidence.
- Simulate: test it on history or in a sandbox where possible.
- Approve: apply the autonomy policy: automatic, human approval or forbidden.
- Act: call a controlled business tool, never write directly from the model.
- Verify after acting: check that the change had the expected effect.
- Learn: keep the operational result, not an unverified “belief” of the model.
From diagnosis to autonomy
- Phase 1: the agent only explains.
- Phase 2: it opens an incident automatically, with the evidence attached.
- Phase 3: it may run a reversible action from an allowlist, such as temporarily disabling a clearly failing bidder, for a limited time.
- Phase 4: it checks the effect itself and rolls back if the KPI does not recover within the expected range.
Each step up requires measured results in shadow mode: the agent watches production and logs what it would have recommended or done, and those decisions are compared with what people actually did and with the real outcome. That is how you measure accuracy, stability, false positives and value without operational risk.
The first twelve months
- Months 0–3, make the system observable. Name a sponsor and a product owner. Pick three use cases, for example revenue incidents, media planning and reporting. List sources, APIs, logs, documents, owners and restrictions. Write the dictionary of the 20 to 30 critical metrics. Set up an AI gateway, logging and a non-production environment. Build the first read-only tools, and define the benchmark and acceptance criteria before the proof of concept.
- Months 4–6, reliable assistants. Agents stay read-only. The goal is cited, reproducible diagnostics, and measuring their quality. Start the structured product catalogue and a first internal version of the advertising API.
- Months 7–9, simulation and approvals. Add the policy engine, approval workflows and a few non-critical actions: tickets, CRM drafts, proposal generation, tests in a controlled environment. Shadow mode becomes systematic.
- Months 10–12, first controlled production. Move a small number of actions to approved execution, only if benchmark, security and rollback are satisfactory. Possibly open a first sales agent to a few authenticated partners.
The business case
Build it agent by agent, not on token counts. For a revenue incident agent: incidents per year × average time to diagnosis × hourly revenue at risk × recoverable share, plus the ad-ops time saved, minus the cost of platform, models, integration, maintenance, monitoring and supervision. For a sales agent, the variables are time to proposal, handling capacity, conversion rate, average deal size and additional long-tail revenue.
If you would like to assess where your organisation stands, write to us.