16 Impressions a Day: Field Notes from a Year of Deploying AI Agents into Real Businesses

On July 17th, a Google Ads campaign I run for a Phoenix flooring contractor served 16 impressions and spent $0. Not paused. Not disapproved. Serving — at sixteen impressions a day, in a metro of five million people.

Nothing in the dashboard tells you why. The answer was in the API: search_rank_lost_impression_share was sitting at ~90%. The campaign was on Maximize Conversions bidding with zero conversion history — and Google's smart bidding, given nothing to learn from, had quietly bid the account into oblivion. A cold-start death spiral: no conversions → no confidence → throttled bids → no traffic → no conversions.

The fix wasn't more AI. It was less. I flipped the campaign to Maximize Clicks with a hard CPC ceiling — dumb, bounded, deterministic — and raised the budget to give it room. Next day: 142 impressions, $83 spent, real clicks from real buyers. Roughly a 9× delivery recovery in 24 hours. The plan: collect 15–30 conversions on dumb bidding, then hand the keys back to the algorithm — this time with data to learn from.

Two days later, the same client's phone went silent all weekend. Last call Friday 12:24pm, next call Monday 6:49am. The ads were fine. The site was fine. The cause was a Google Business Profile listing that said "Closed · Opens 8 AM Mon" — so Google suppressed the call button for two days while the published site said "open 7–6 daily." Two days of weekend demand walked to competitors whose listings said open. The fix was a settings page, not a model.

I tell these two stories first because they're the actual job. For a year I've been building and operating an AI-agent platform for small service businesses — and the work that moves a client's revenue is this: read the telemetry, find the root cause, ship the boring fix, measure the recovery. The industry recently settled on a name for this job. It's called forward-deployed engineering.

The rest of this post is the system behind those stories — and the design decisions that let a solo-built platform survive contact with real customers.

The 48-hour flip (or: what a directional driller taught me about smart bidding)

Something the dashboard will never show you: Google's algorithm is two different animals before and after its first conversions land — and in my accounts, the flip is visible in the auction data within about 48 hours of conversions starting to flow.

Everyone's heard the folklore:

Restart your campaign — fresh ones perform better.

Here's what's actually happening: a fresh campaign gets exploratory reach while the algorithm buys a broad sample of auctions to find out what converts. Compare that honeymoon to a starved campaign that's already spiraled, and the restart looks like magic. It isn't. They're resetting the exploration, mistaking variance for improvement, and paying the learning tax again every time.

Before I wrote software I worked in the oil field, and the best systems lesson I ever got was watching a directional driller steer a bit two miles underground. Three things about that job:

He never knew where the bit was. Surveys come up every ninety feet — you steer on where the bit used to be, always. So the survey tools get calibrated before you spud the hole, because steering on corrupt data isn't steering; it's drilling blind with confidence.

The cheap decisions all happen early. You set your kickoff point and build your curve near the surface, where changing course costs almost nothing. Try to fix your angle two miles down and every correction is a dogleg — severe curvature the whole rest of the well has to live with.

And the bit behaves completely differently under weight. Too little and it skates across the formation and wanders — no amount of clever steering fixes a bit that isn't biting. But you don't slam the weight on either. You work it in — add some, feel the bit take it, add more.

Smart bidding is the same machine, and the doctrine falls straight out:

Root the campaign in solid telemetry before you spend a dollar. The algorithm's first 48 hours of learning are its survey data — if your conversion tracking is double-counting, missing, or lagging at launch, every decision it ever makes inherits that corrupt foundation. You cannot retro-fix learning that happened on bad signal.

You get about 48 hours of free reign. The early exploration window is when your structural choices — keywords, match types, bid strategy — get priced in cheaply. After the flip, every structural change is a dogleg: a partial reset of learning you pay for in performance.

After that, the job is signal density plus pulsed torque. Get every conversion counted and counted fast — server-side events, enhanced conversions, offline imports — because signal-per-unit-time is what tightens the loop. And feed budget in spurts rather than a flat ramp: a burst of spend is a burst of auctions is a burst of data, then let it settle, then pulse again. Working the weight in. (The pulses come after the flip, when the loop is tight enough to absorb them — never during learning.)

That's the spiral I opened with, in doctrine terms: a campaign launched without weight, on thin signal, that wandered until it stopped making hole. And it's why the rest of this post spends so much time on boring deterministic pipes. Google's bidder is an AI sitting downstream of your tracking infrastructure, exactly like my agents sit downstream of my event pipeline — and every AI in your system is only as smart as your dumbest pipe.

The system at a glance

The platform runs on GCP — Cloud Run for compute, Cloud SQL Postgres for durable state. At the top of the control plane sits a Claude Sonnet orchestrator; below it, sixteen specialized sub-agents; alongside it, an approval oracle whose job I'll explain in a minute, because it's not what you'd guess. Feeding everything: a deterministic event pipeline doing server-side tracking across Meta CAPI, GA4, GTM, and six ad platforms.

Scale honesty, because it matters: this serves a small fleet of paying SMB clients, and I own every layer of it — infra, pipeline, agents, deploys, and the 2am incidents. Small fleet, full custody. Everything below is running in production; where something is designed but not built, I say so.

1. Two planes, and the LLM is not in the hot path

When a lead submits a form on a client's site, that event never touches a model. It hits a server-side GTM container, gets validated, normalized, hashed, deduplicated against a window in Postgres, and fanned out to Meta CAPI and GA4 — all in deterministic code. Zero tokens. Zero latency lottery.

The oil field taught me to steer on lagged signal; real-time bidding infrastructure — where the hot path had a sub-5ms budget and anything probabilistic was a liability — taught me determinism. This platform is both lessons running at once: the data plane moves events — fast, cheap, boring. The control plane makes judgment calls — that's where the agents live. Most "agentic" platforms fail because they put an LLM where a switch statement should be.

2. The orchestrator has one job

The platform's tool registry holds about 134 tools. Nothing ever sees all of them. The orchestrator doesn't execute work — it delegates to specialists, and every specialist gets a scoped allowlist it cannot reach outside of: the researcher gets read-only tools, the media buyer gets its platform's tools, and a 134-way routing decision becomes a handful of small, bounded ones. The moment you ask "how does the model choose between 134 tools," you've already made the architectural mistake.

3. Guardrails that don't trust the model

Here's the part I'd underline twice. Agents in my system can propose external writes — send an email, change a campaign, push GTM tags — but the model cannot authorize one, no matter what it claims.

When a user confirms a write, the runtime — not the model — records a server-side approval: single-use, 60-second TTL, bound to the specific specialist the user approved. When the orchestrator then dispatches that specialist, the runtime checks the binding. If the model lies about having approval, there's no server-side record and the write is blocked. If a prompt injection tries to redirect an approval to a different action, the task binding doesn't match and the write is blocked. Below that sits a risk-tier policy — read → workspace_write → external_write → destructive — enforced server-side, plus hard budget ceilings on anything that runs on a schedule.

The principle: the model holds opinions; the runtime holds the keys. I learned to design this way from an embarrassing class of bug — error messages that referred to UI that didn't exist, which the model would then faithfully hallucinate workflows around. Everything a model reads is a prompt, including your error strings. Design accordingly.

4. Evals are deploy gates, not dashboards

Every production release runs a seven-layer pipeline: typecheck, credential scan, an LLM-driven security review of the diff, an eval suite diffed against a committed baseline, build/deploy, post-deploy security smoke, and a live canary against production. A regression in agent behavior blocks the ship the same way a failing unit test does.

The diff security reviewer is conservative and occasionally annoying — it has stopped two of my own changes that introduced model-controlled security decisions I'd convinced myself were fine. It was right both times. If your agents' behavior isn't gated in CI, you don't have an AI product; you have a demo with a billing page.

5. State lives outside the context window

Long workflows span hours and multiple agent instances. The thing that keeps this from dissolving is that project state never lives in any agent's context window. Every handoff writes to a persistent ledger — plain markdown: where the project stands, what the outgoing agent learned, what's signal, what's noise. Context windows die; the ledger doesn't. The model's memory is a cache. The ledger is the database.

6. The pixel is telemetry, not truth

Roughly half of my clients' traffic is iOS, where Safari actively degrades browser-side tracking. So the platform inverts the industry-standard setup: the browser pixel still fires, but it's a parallel telemetry stream. Everything that drives attribution and reporting flows through the server pipeline. Server-authoritative by design — iOS churn degrades a nice-to-have, not the numbers a client sees.

Downstream platform calls run behind a 3-second timeout: no retries, no blocking. Cost: up to ~5% cross-platform conversion drift. I accept that deliberately, because for local-service clients, attribution noise from iOS and consent gaps already exceeds it. The dead-letter recovery design exists on paper — failed sends to a Postgres table, retry worker with backoff, Meta CAPI accepts events seven days late — and I know exactly which client spend profile flips the switch to build it. Knowing where the reliability bar sits for your actual customer is a design decision too.

What breaks next

Three limits I know about:

The registry doesn't scale forever. At 134 tools, per-agent scoping works. At 300+, the scopes become their own management problem — versioning, capability discovery, automated scope audits I haven't built.

The dead-letter queue is designed, not built. Written down, trade understood, trigger condition defined. But designed and built are different states.

The approval oracle needs numbers. Today I can tell you it blocks unauthorized writes; I can't yet tell you its correction rate over time. Instrumenting that is next.

The bet

As models get better, the deterministic plane doesn't shrink — it grows, because the agents get better at writing deterministic paths that then run without them. That's what the bidding-flip story at the top actually was: judgment (diagnose the spiral, choose the strategy) followed by a durable, dumb, bounded mechanism that runs while the model sleeps.

The endgame isn't smarter agents in the loop. It's agents that graduate their own work out of it — and engineers who know which side of that line every piece of the system belongs on.

---

I build and operate this at nxflo, deployed into real businesses that have never heard the word "agentic" and just want the phone to ring. If you're shipping agents into production environments — especially the messy, human ones — I'd genuinely like to compare notes.