The platform we run on

We built AI governance because our own pricing model demanded it. Then a freight brokerage needed it for something else entirely.

Part 1 — Origin

We didn't build guardrails on principle. We built them on arithmetic.

Bobos sells marketing at published, fixed prices. A first campaign from $750. A full team at $4,500 a month. No retainer creep, no scope negotiation, month-to-month.

That pricing model has an unusual property: it makes AI cost a first-order business risk rather than a line item. An agency billing hourly can absorb an agent that burns $40 producing a $12 deliverable — it shows up as margin. We can't. At our prices, a handful of runaway runs a week is the difference between a business and a hobby.

So the first thing we built was not an agent. It was the ledger.

Every agent call in our system writes one row: which agent, which model actually ran, tokens in and out, cost in dollars to four decimal places, start and finish to the millisecond, and which piece of work it belonged to. Cost attributes through one of 9 mutually-exclusive parent references, so a monthly cost-per-client or cost-per-workflow figure is a query rather than a reconstruction.

Then the ceilings. Every agent definition carries a hard per-call dollar limit, a soft warning threshold, and a timeout — in the configuration file, in version control, next to the prompt. Our weekly prospect-insight agent runs with a $0.0500 ceiling, a $0.0400 warning, and a 60-second timeout. The cost is checked the instant the call returns, and an overage hard-stops everything downstream. It does not quietly switch to a cheaper model and carry on, because a system that degrades silently costs more than one that fails loudly.

Then the parts that took longest and matter most.

32 recurring workflows, each registered with a blast-radius classification — whether it only reads, writes inside our system, or can reach the outside world. Anything in the last category needs a typed confirmation to run by hand. Every scheduled job takes a cross-process lock first, so a manual retry during a scheduled run cannot double-send.

Every agent and every specialist fleet is off until its identifier is provisioned, and every scheduled workflow that can reach a customer is off until someone explicitly enables it — so code ships continuously while capability activation stays a separate, reversible decision with a name attached to it. One workflow is deliberately exempt from that and cannot be switched off by configuration: the job that redacts personal data after 30 days.

And the one we're most attached to: in our campaign review fleet, the prompt tells the model it must never invent a finding. The code then independently drops any finding reference the model invented and re-appends any real finding it left out. The prompt states the rule. Something the model cannot reach enforces it.

The internal numbers

Every figure below is read from the live ledger when this page renders — a query, not an estimate. Where a metric is missing, the data to publish it honestly does not exist yet.

The weekly campaign review

33 completed reviews in the archive, at an average cost of $0.0664 per review.

What a review took in analyst-hours before automation was never instrumented — we can’t publish a before number we didn’t measure, so we publish what a review costs now.

The ledger itself

14,073 agent calls recorded to date. 577 of them are recorded as failed or skipped rather than completed — the ledger keeps those rows too. 0 exceeded their published cost ceiling; each overage hard-stops everything downstream of it.

Outreach drafts

143 held for human review · 9 approved · 0 rejected · 113 sent. Nothing sends without a person approving it.

Writes to client-owned properties

2 applied, every one preceded by a preview and a captured prior state. 0 rolled back — the number that proves the way back is real, not documentation.

None of this was built to sell. It was built because the alternative was going out of business.

Part 2 — Generalisation

Then a national freight brokerage asked for something that had nothing to do with marketing.

The client is a national freight brokerage. What they needed was not campaigns.

They needed to know which shippers were quietly losing carriers, before the shipper themselves knew. They needed RFP submissions reconciled against carrier and lane data, with the discrepancies surfaced as auditable findings rather than as a spreadsheet someone eyeballs. They needed trailer inventory tracked across yards, and load data turned into something a person could act on that morning.

We built it on the same platform. Not a fork, not a separate product — the same tenant model, the same cost ledger, the same human-approval gates, the same audit trail. 4 new agents on foundations that already existed.

A lane diagnostician that reads one shipper's facility data, lane patterns and carrier vetting records and emits a structured diagnosis. Deliberately not an email — a diagnosis object, which becomes the grounded input for everything downstream.
A qualification researcher that runs cheap, per prospect, at high volume. The first agent we moved to a small fast model specifically because the economics of the workload demanded it — a decision the ledger made obvious.
An opportunity ranker that produces a daily ranked shortlist. The first agent whose cost we attribute per batch rather than per record, which required a new parent reference in the ledger — a schema change of one column, because the ledger was designed to be extended.
An outreach drafter grounded on the diagnosis rather than on generic messaging, and gated three separate ways with a hard daily send cap. A draft with unresolved validation errors is never sent automatically, under any configuration.

The reason this took weeks rather than quarters is that none of the hard parts were new. Cost attribution, tenant isolation, human approval, rollback and audit were already solved — in a marketing context, for marketing reasons. Freight just needed different agents pointed at different data.

Accounts payable and receivable. Connected to QuickBooks. The agents look up records, draft invoices, draft bills, and produce reports. They cannot post anything. Every write-shaped tool returns a link for a person to confirm — the direct path isn't restricted, it isn't implemented.

A product migration. We moved a published Chrome extension — its own users, its own entitlements, its own usage metering — off a legacy PHP stack onto this platform with zero client breakage. That required reproducing the old system's response format byte for byte, including 7 distinct envelope shapes, verified by 35 golden fixtures replayed on every build. The cutover ran dual-write, then flipped, with a reverse-sync rollback window standing by.

That last one is the least glamorous and the most relevant to anyone with a legacy system they can't turn off. Which, in our experience, is everyone.

Part 3 — Compounding

One platform, not one build per client.

Most firms with proprietary tooling build it per client. That's defensible, and it forfeits the only real advantage of building a platform: nothing accumulates.

Ours is multi-tenant. 113 tables carry an explicit tenant scope, enforced by rules that fail our build if a query is missing its filter, and verified by a suite that runs 20 cross-tenant probes which must all come back empty before anything ships.

Which means hardening compounds. When one client's workflow exposed a way for a manual retry to collide with a scheduled run, we added a cross-process lock — and every workflow on the platform got it. When cost attribution needed to work per batch instead of per record for the freight ranker, the ledger gained a column and every future batch-shaped workload was already handled.

We can watch it happening in our own history. The pattern for adding a specialist to an analysis fleet is now a single registry entry, documented from the first instance forward, with the promotion notes still in the repository. The first fleet was a project. The latest addition was an afternoon.

Your fifth workflow costs less than your first because the 32 already running found the edges.

shipped migrations: 127shipped migrations
tenant-scoped tables: 113tenant-scoped tables
governed workflows: 32governed workflows
production agents: 12production agents
agent prompt specs: 34agent prompt specs
delivery patterns: 11delivery patterns
operational runbooks: 68operational runbooks
cross-tenant probes, all required to return nothing: 20cross-tenant probes, all required to return nothing

What we don't claim

This is enforced at build time and proven by tests — not by runtime row-level security. The runtime helper carries tenant context; it does not inject a filter, and it says so in its own source. Automatic injection is a later phase. Our public integration surface isn't open yet either: the authentication layer is built and tested, the client-facing tool interface isn't finished. And our two-person approval queue is enforced by the database but not yet operational — the constraints are real, the workflow through it isn't yet. We'd rather you read all of that here.

What this means for you.

You don't need our marketing agency. You need to know that when we say a workflow has a spend ceiling, a cost ledger, a human checkpoint and a way back, those are four things that already exist and have been running against real money — first ours, then a freight brokerage's, then a finance function's.

Start with what you already have running: $7,500, two weeks, and an honest verdict.