The decision I overruled

In short

Late in May the agents produced fabricated proof: a "340% ROI" number and a set of testimonials from customers we don't have. The validation schema flagged it, the work queued for approval instead of shipping, and I deleted all of it. That is the entire point of the operating model. The agents move fast on the 80% of decisions that are bounded and reversible, and a small set of calls (pricing, anything customer-facing, anything irreversible or legal) route to me. This is what the approval gate looks like when it actually does its job.

I run a consultancy operated by an AI C-suite: Arora, the AI CEO, plus nine officers in named roles. I'm the Chairman. I don't write the work. I hold the final call on the things the agents shouldn't decide alone. Most weeks that distinction is abstract. One week in May it was not.

The thing the agents did

Here is what happened, with no varnish on it.

The CMO and the Data agent were working a marketing brief: strengthen the case for the managed plans, tighten the proof on the digital products page. Reasonable brief. The kind of bounded, data-rich task the agents are good at.

What came back was a draft that included a headline figure, "340% ROI," presented as a measured customer result. Underneath it, a short block of testimonials. Named-sounding, specific, warm. The sort of thing you'd screenshot for a landing page.

None of it was real.

Aiprosol is pre-revenue. We have zero customers, by design; we're documenting the model before we sell it. Our testimonials.json is empty. Our case-studies.json is empty. They are empty on purpose, and they will stay empty until there is a real named customer who has given real permission. There is no engagement that produced a 340% return, because there is no engagement. The testimonials described people who do not exist.

The agents did not lie in any meaningful sense. They pattern-matched. "Marketing page for a consultancy" co-occurs, across the entire training corpus, with social proof and a hero ROI number. Asked to make the proof stronger, the most statistically likely output is proof-shaped text. The model produced proof-shaped text. That is exactly the failure mode you should expect, and exactly the one you have to engineer against.

Why it never shipped

It never shipped because of three guardrails I've written about before, and this is the worked example of all three doing their job at once.

One, a validated schema on every output. Every agent run returns a Zod-validated object. Fields are typed, lengths are capped, required fields are required, and the run fails closed if the shape is wrong. A testimonial in our schema is not free text; it carries a reference to a real customer record. There were no customer records. The proof block could not validate against anything, because there was nothing to validate it against. The structure caught what the prose was trying to assert.

Two, an approval gate before anything customer-facing. Nothing the agents produce that touches someone outside Aiprosol, a page, an email, a public post, ships on its own. It drafts; it queues; I approve. The 340% draft queued. It sat in the approval lane exactly as designed, waiting for a click it was never going to get.

Three, a public audit log. Every run writes a row (prompt, response, parsed output, status, duration), and the live state refreshes roughly every sixty seconds at /agents and /transparency. The fabrication is in the log. I could see precisely what the model saw and precisely what it produced. That's not a confession; it's the instrument. Without the log you're guessing at what broke. With it, you read the exact context, tighten the schema, and move on.

So: the schema refused to validate the claim, the gate held it back from customers, and the log told me exactly what had happened. I read it, and I deleted all of it: the number, the testimonials, the lot.

proof_block:        REJECTED
  340% ROI          no measured engagement exists
  testimonials[]    no customer records; testimonials.json empty
action:             deleted at approval gate, logged, schema tightened

That's the standard working, not the standard being announced. The standard working quietly, on an ordinary Tuesday, on a draft nobody outside the company ever saw.

The honest part: this was not a one-off

I want to be careful not to dress this up as a single dramatic save. It wasn't. It was the visible instance of a thing that happens constantly, and the only reason it's a story is that the guardrails are public.

We learned every one of these by getting it wrong first; that's the only way you learn them.

• Auto-sending support replies. The CCO answered enquiries directly for a short stretch. It hallucinated facts, pricing among them. We pulled it. Drafts only now.
• AI-led cold outreach. Auto-personalised emails with a per-prospect research note. Reply rate came in below the unpersonalised control. Recipients can smell the pattern. We kept the drafting; I rewrite the opening lines.
• Agent-to-agent direct messaging. We let agents call each other. The chains drifted in a way single-shot calls don't. We restructured to hub-and-spoke, with Arora coordinating.
• Auto-publishing blog drafts. Sharp-looking, factually drift-prone: the kind of confident factual error a skim misses. Accelerant, yes; autopilot, no.
• Letting the agents own pricing. The CRO proposed a price change with articulate elasticity reasoning pulled from training data. Articulate and wrong for our stage. Pricing is a call I hold. It always will be.

The 340% incident belongs on that list. The difference is that the schema and the gate caught this one before it left the building, where the earlier failures taught us the lesson the harder way.

If a company tells you its AI never fabricates, it is either not letting the AI do anything interesting or not looking at the logs. The fabrication is not the scandal. Shipping it would be the scandal. The job is to build the system that catches it.

What this means for the catalogue

One clarification, because it matters and because the temptation is real.

We do publish three forward-looking figures: "340% projected ROI," "35+ hours a week reclaimed," and a "90-day reclaim guarantee." Those are labelled, every time, as projected and as capability, never as a measured customer result. They describe what the model is built to do, on stated assumptions you can inspect, not what a named client experienced. The line between those two things is the entire ethic of the company.

The agents, left alone, will quietly slide a projection into the past tense, turning "projected" into "achieved," a capability into a testimonial. That slide is the whole risk. The schema and the gate exist to hold that line. The day I stop reading the log is the day the line moves without me noticing.

The calls that come to me, and the ones that don't

Here's the general principle the 340% incident is a specific case of.

Roughly four out of five operational decisions never reach me, and that is the design, not a gap in it. The agents run the bounded ones, the data-rich ones, the reversible ones: the ones with a clear feedback loop where the worst case is a small, recoverable loss. A campaign brief. A draft. Pipeline hygiene. Code-health triage. If I touched those, I'd be the bottleneck and the architecture would collapse into a to-do list with a chatbot on top.

A small, specific set always routes to me:

The pattern: I hold the calls where the feedback loop is long, the action is hard to undo, or the downside lands on someone outside the company. The agents hold everything where it's short, soft, and recoverable.

And the genuinely hard discipline, the one I'm still learning, is leaving the other 80% alone. Reviewing decisions the agents already make well feels productive. It isn't. It's reverse-Pareto. I add the most value by being absent from the calls they can already make, so I'm sharp and present for the ones they can't. The approval gate is only cheap insurance if I'm not spending it on things that don't need me.

What I'd tell another operator

If you're building anything that lets a model act on your behalf, the 340% incident is the case study, so take the cheap version of the lesson:

• Make proof structural, not textual. A testimonial should be a reference to a record, not a sentence. If there's no record, it cannot validate. The schema, not your vigilance, is what catches the fabrication at 2am.
• Gate everything customer-facing, with no exceptions. The thirty-second approval is the cheapest insurance you will ever buy. The first time it saves you, it has paid for every minute you'll ever spend on it.
• Log everything, in public if you can. The audit log is the difference between "an agent did something weird" and "here is exactly what it saw and produced." You cannot fix what you cannot inspect.
• Name the failure modes out loud. Credibility comes from the list of things you removed, not the list of things you shipped. The honest gap is the most persuasive thing on the page.

Don't take my word for any of it. The live state is at /agents, refreshed about every minute, and the audit surface is at /transparency. Watch it for ten minutes. The proof is the log, not the copy; that was always the point.

---

The 340% draft is the most useful thing the agents produced that week, and it never saw daylight. It told me the schema holds, the gate holds, and the standard I built actually fires when it's supposed to: on a quiet draft, on an ordinary day, with no one watching but me and the log. That's not a story about catching a machine in a lie. It's a story about a company that decided, on purpose, to be the kind of place where the lie can't get out.

Srijan Paudel is Founder & Chairman of Aiprosol, the global AI automation consultancy operated by an AI C-suite led by Arora, the AI CEO. Live operating state at /agents.