Governed AI media buying

Every impression is a decision.

AdBid helps performance advertisers and agencies run governed, measurable media buying with AI agents that decide within budget, policy, and approval limits — unlike campaign dashboards and manual optimization.

Agent onboarding
AdBid.io · supervised agent · sandbox first
decision trace · camp_88f1sandbox
market openrtb 2.6 · exchange=fixture
warrant w_7f3a ✓ Ed25519 ceiling 2400 µ$ CPM
budget available 18.40 reserved 4.10
audience seg_high_intent consent ✓
decision bid 1860 µ$ pCTR 0.031 · floor 1200
state LIVE → SETTLING
receipt 0x8b70…c2f1
actor agent:plannerpolicy v14trace 9c2e…
53
MCP tools · normative catalog
95
REST operations · registry
71
canonical business objects
50
operating SOPs

01 / WHY NOW

Dashboards describe spend. They do not control it.

Programmatic buying already runs at machine speed. What is missing is not another analytics layer — it is an authority layer that can bound, record, and reconcile every decision a machine makes with money.

GAP / 01

The control gap

A dashboard shows what happened after the invoice. It cannot stop a bid that exceeds the envelope, and it cannot prove who authorized it.

Open →

GAP / 02

The agent gap

Agents can call APIs, but most systems have no way to distinguish a proposal from an execution — or to revoke one delegated credential without stopping the whole account.

Open →

GAP / 03

The proof gap

Attribution debates stall because modeled lift and observed incrementality are mixed into one number. The platform keeps them separate and labels both.

Open →

02 / STATUS QUO

The real competitor is the spreadsheet and the dashboard.

Teams rarely lose money to a missing algorithm. They lose it to disconnected approvals, unbounded automation, and numbers nobody can reconstruct after the invoice arrives.

JobStatus quoWith AdBid
Decide a bidA dashboard, a day-old export, and a rule someone remembersSigned warrant and policy check at bid time, with a receipt
Change a budgetA chat message and a direct editPreview, named approval bound to a hash, versioned apply
Explain spendSpreadsheet reconciliation and a best guessDouble-entry journal reconciled to provider invoices
Delegate to an agentA shared login with full account accessScoped, expiring credential; no self-approval; revocable
Prove a resultModeled lift presented as observedObserved, attributed, modeled and verified kept separate

03 / THE CHAIN

Signal, decision, warrant, receipt.

Four steps, one control model. The same operation is available to a human in the cockpit, a script over REST, and an agent over MCP — with the same policy check and the same receipt.

01 / SIGNAL

Observe

Market, audience, inventory, and creative signals arrive with provenance, freshness, and a privacy classification.

02 / DECISION

Decide

Forecasts and bid strategies produce a proposal. Deterministic limits apply before any model output is trusted.

03 / WARRANT

Authorize

A signed spend warrant binds tenant, campaign, ceiling, channel, expiry, and approval lineage. Agents never sign their own.

04 / RECEIPT

Prove

Execution emits a durable receipt and balanced journal entries. Reconciliation is a first-class operation, not a report.

04 / SURFACES

One control model, six surfaces.

Every module reads and writes authoritative services. A button in the cockpit and an MCP tool call land in the same command handler; only serialization differs.

OPERATE

Command

The operator cockpit: campaigns, budgets, approvals, inventory, spend, audit.

Open →

EXECUTE

Engine

OpenRTB bidding edge that consumes immutable, signed bidder snapshots.

Open →

THINK

Intelligence

Forecasts, causal measurement, and decision support with explicit uncertainty.

Open →

CREATE

Creative

Creative studio, experiments, and landing-page intelligence under review gates.

Open →

DELEGATE

Agents

MCP, A2A, WebMCP, CLI, and SDKs — all scoped and revocable.

Open →

GOVERN

Governance

Identity, policy, warrants, emergency stops, and evidence.

Open →

05 / STATE

Nothing is “done” because a job was queued.

An action succeeds only when the target acknowledges a matching revision and policy confirms the resulting state. Failures are visible, and the default for uncertainty is no-bid.

Every object carries an explicit operational state. A deployment that has not been acknowledged is not live; a settlement that has not reconciled is not closed. The UI shows the state rather than an optimistic summary.

The failure hierarchy is deliberate: cash and privacy first, then continuity of purchased delivery, then optimization, then UI convenience. If the authorization ledger is uncertain, new liability creation halts.

How conformance is tested →

Operational states

ADVISORYDRAFTAWAITING_APPROVALAPPROVEDDEPLOYINGLIVEPAUSEDFAILEDSETTLINGCLOSED

States are design tokens, not evidence of financial safety. A green state does not replace a receipt.

06 / HONESTY

What this site will not claim.

The specification is a target design. The repository contains prototypes, and several modules are explicitly not production-ready. Claims on this site are limited to what can be tested.

Status you can check

Version 1.0 is a sole-source specification. The current private repository has a Rust bidding library, an OpenRTB router, a Node control plane, and a 53-tool MCP registry — with known gaps: no production partner credentials, no independent certification, and an MCP handshake still on an older revision.

We publish the gap rather than paper over it. Release claims require reproducible tests and evidence.

Non-claims

  • No fabricated customer metrics or logos.
  • No invented exchange or data partners.
  • No “guaranteed ROAS” or performance promises.
  • No certification implied by a badge.
  • No agent authority inferred from a Markdown file.

Start with a sandbox, not a wire transfer.

The sandbox exercises the full authority chain — warrants, previews, approvals, receipts — against simulated providers. Production access is gated on verification, not on copy.