Close the month without the spreadsheet war.
AdTech is where our architecture runs in production. Reconciliation, trafficking, deal troubleshooting and traffic quality are high-volume, rule-bound and expensive to get wrong. We redesign them so agents do the matching and preparation, deterministic checks guard every action, and your ad ops team handles only the exceptions.
Six AdTech workflows that grow with headcount today.
Each of these runs every day or every month. In most ad operations teams the work is done by people moving data between the ad server, partner dashboards, billing and email. Here is what changes, what doesn't, and the check that guards it.
| Workflow | Manual today | AI-native version | Stays human | Verification check |
|---|---|---|---|---|
| Partner discrepancy reconciliation | Export ad server and SSP/DSP reports, match them in spreadsheets, email partners when the gap exceeds tolerance. | Agents pull reports by API, normalize them and match by date, placement and deal ID. Out-of-tolerance lines get a drafted dispute pack. | Sending disputes, agreeing credit notes, partner relationships. | Matched totals must equal both source reports. No invoice or dispute is drafted on unreconciled numbers. |
| IO-to-line-item trafficking and QA | Ad ops reads the insertion order PDF and keys flights, budgets, targeting and creatives by hand. | An agent parses the IO, proposes line items and runs pre-launch QA on creatives and landing pages. | Launch approval and any non-standard commercial term. | Every field is compared with the IO: budget, flight dates, geo, frequency caps, creative sizes. Any mismatch blocks launch. |
| Deal ID and PMP troubleshooting | Buyers report "the deal isn't bidding". Ad ops checks floors, seat IDs and targeting across several consoles over email and chat. | An agent reads bid logs and deal configuration (read-only), finds the likely cause and drafts the fix and the reply. | Applying configuration changes and agreeing commercial terms. | Read-only access to logs. Every proposed config change is a diff that a person approves. |
| Invalid-traffic review | Weekly review of vendor reports and manual blocklist updates, often after the money is spent. | Real-time rule and anomaly scoring on the bid path returns Clean, Suspicious or Blocked, with a plain-English reason. | Blocking a whole supply source or partner, and appeals. | Each verdict is reproducible from logged signals. Blocks above a set volume need sign-off. |
| ads.txt, sellers.json and supply chain hygiene | Occasional manual checks of publisher files, usually after a buyer complains. | Daily crawl of ads.txt and sellers.json, matched against your seller IDs and schain, with drafted publisher notices. | Contacting publishers and removing supply. | Every flagged line is checked against the live source file before a notice is drafted. |
| Pacing, reporting and client questions | Account managers pull daily pacing and build reports by hand to answer routine client questions. | A conversational analytics copilot answers from live metrics and campaign documents, with pacing alerts. | Rebudgeting, make-goods and client conversations. | Every number traces to a logged source query. The agent has no write access to budgets. |
Six numbers that show whether it worked.
The Audit measures these before anything is built. The Pilot is measured against the same numbers.
| Metric | Definition |
|---|---|
| Discrepancy rate | Revenue variance between your ad server and each partner's report, as a share of billed revenue. |
| Days to close partner billing | Working days from month end until every partner invoice is issued or disputed. |
| Trafficking error rate | Share of line items that need a correction after launch. |
| IO-to-live time | Hours from a signed insertion order to a campaign serving correctly. |
| IVT false-positive rate | Share of blocked traffic that review shows was legitimate. Blocking too much costs revenue too. |
| Ad ops hours per € of revenue | Operations workload against revenue handled. It should fall as volume grows. |
What can go wrong in AdTech, and the control for each.
Programmatic money moves fast. We name the failure first, then design the control and the way you would detect it.
| Failure mode | Control | How we'd detect it |
|---|---|---|
| Misconfigured line item overspends | Field-by-field check against the IO before launch, plus a hard spend cap the agent cannot change. | Pacing alert when delivery runs above plan in the first hours. |
| Invoice issued on unreconciled numbers | Invoice drafting is blocked until reconciliation passes the agreed tolerance. | Reconciliation status is logged per partner and visible before billing. |
| Legitimate traffic blocked | Large blocks need human sign-off. Every verdict is stored with its signals. | Sampled review of blocked traffic and tracking of partner complaints. |
| Deal silently stops bidding | Daily health check on active deals: bid rate, win rate and floor against expected ranges. | Alert when a deal falls outside its range, before the buyer notices. |
| Consent signal ignored | TCF consent strings are validated before data is used for targeting or reporting. | Count of consent-check failures per partner and per day. |
| Agent acts on a manipulated input | Typed intake for IOs and emails. Content is treated as data, never as instructions. Agents hold no platform write credentials. | Log of rejected inputs and blocked actions, reviewed weekly. |
Partner reconciliation, from diagnostic to pilot.
Illustrative example — not a client result. The numbers below are assumptions chosen to show the method and the arithmetic. Your Audit replaces them with measured values.
| 01 | Diagnostic | Suppose an SSP picks "monthly partner reconciliation" on the AdTech track. Its Snapshot might show a High leverage signal with Medium confidence, friction concentrated at the Verification stage, and Level 2 (workflow augmentation) as the indicated AI depth. What it can't know yet: real hours and the exception rate. |
| 02 | Audit | Suppose the Audit measures 60 partner reports a month at 2.5 hours each. That is 60 × 2.5 = 150 hours a month, about 0.9 FTE at 160 hours. It also finds that about 30% of partners fall outside the 10% discrepancy tolerance in a typical month. |
| 03 | Pilot | Suppose agents match the 70% in-tolerance partners and a person reviews each for 15 minutes, while the 30% out-of-tolerance partners take 1.5 hours each with a dispute pack already drafted. The Pilot measures whether that holds. |
| Line | Assumption | Hours per month |
|---|---|---|
| Baseline | 60 reports × 2.5 h | 150.0 |
| In tolerance, after | 42 reports × 0.25 h review | 10.5 |
| Out of tolerance, after | 18 reports × 1.5 h | 27.0 |
| After, total | 10.5 + 27.0 | 37.5 |
| Difference | 150.0 − 37.5 (about 0.7 FTE) | 112.5 |
At an assumed loaded cost of €55 an hour, 112.5 hours is about €6,190 a month. The Audit would also count what the hours don't capture: days to close, and discrepancies that were never disputed. It would also count the new costs: compute, maintenance and the time to review exceptions. If those cancel out the benefit, the recommendation is "don't proceed".
AdTech is where this already runs.
The same architecture behind this page runs in production for AdTech operators. Most engagements are confidential, so the case studies describe the problem, approach and outcome without naming accounts.
| Header bidding and SSP/DSP integration | OpenRTB-compliant supply and demand integrations, header bidding and marketplace transaction logic for international operators. |
| AdCP agent-to-agent negotiation | A proof of concept for campaign discovery, negotiation and activation between advertiser and publisher agents, logged at every step. |
| AdOps Copilot | Plain-English questions answered from live metrics and guideline documents, every answer traced to its source. Delivered in four weeks. |
| Real-time IVT detection | Rule-based scoring blended with anomaly detection on the bid path, returning a verdict without adding noticeable latency. |
Five AI plugins built on this architecture are live at reviveadservermod.com. Our applied AdTech working paper benchmarks the verification pipeline on 100,000 synthetic transactions. Those figures come from a synthetic workload, not a client deployment.
Questions ad ops leaders ask first.
Do you replace our ad server or SSP?
No. We work on top of the systems you run, through their APIs and exports. Agents get read access by default, and any write action passes a check and, where it matters, a person.
We run Revive Adserver. Is that an advantage?
It shortens the work. Our production plugins are built for Revive Adserver, so the integration points are known. Other ad servers and platforms work too, through their APIs.
Which workflow should we start with?
Usually the one with the highest volume and a clear tolerance rule, often partner reconciliation or trafficking QA. The free diagnostic helps you choose, and the Audit confirms it with measured data.
Find out which ad ops workflow is worth redesigning.
Start with the free diagnostic on the AdTech track. Move to the Audit only if the Snapshot points to something worth measuring.
| 01 | Free AI Operational Diagnostic | 10 steps, 8–12 minutes, AdTech / Programmatic track. Snapshot on screen and as a PDF. |
| 02 | Operational Leverage Audit, from $1,500 | Fixed fee, one workflow, 10–15 working days after data access. Measured baseline, benefit model with stated assumptions, go / no-go. |
| 03 | Pilot implementation, from $6,000 | Fixed scope. The workflow built and run in your environment, measured against the Audit baseline. Typically 4–8 weeks. |