— Case studies

What the
work looks
like.

Three composite case studies drawn from AI transformation engagements across MediaTech, FinTech, HealthTech, RetailTech, ConsumerTech, and InsurTech.

Anonymized clients. Real outcome arcs. Real numbers.

40+Engagements
since 2023
6Industries
of depth
10–14Weeks, build
to production
3–4Engagements
per quarter

— On these cases

These are composite case studies: drawn from real engagement patterns but anonymized to protect client confidentiality. Metrics, timelines, and outcome arcs are real. Names, locations, and specific products are abstracted. If you'd like a reference call with a real client at your stage and vertical, we can arrange that during the Discovery phase. On our evidence ladder these are level 3 — demonstrated, composite.

— Case 01
FinTechSeries CFraud detection$80M ARRDiagnose + Build

Cutting fraud false-positives without raising the threshold for real fraud.

A Series C consumer payments platform was losing customers to fraud-system friction. The team had tried two rule engines and a vendor model. We rebuilt the detection layer in 14 weeks — false-positives dropped 41%, true-positive recall held flat.

— The constraint

The CFO's stated problem was "fraud is too high." That wasn't actually the problem. Fraud losses were within acceptable industry range — 14 basis points on transaction volume, against a 12bps target. The real problem surfaced in the customer support tickets: an outsized share of customer churn was tied to legitimate transactions being blocked. The fraud system was succeeding at fraud and quietly destroying the top of the funnel.

The Diagnose phase reframed the success metric: not "reduce fraud losses" but "reduce false-positives while holding true-positive recall constant." Once that was stated, the engineering team — who had felt blamed by the original framing — became active collaborators.

Two architectural decisions did most of the work. First, we replaced the binary block/allow decision with a four-tier confidence score — high-confidence fraud blocked, high-confidence-legitimate passed, and two middle tiers routed to either step-up authentication or human review. The middle tiers carried 22% of transactions previously blocked and converted 78% of them.

Second, we built a shadow scoring pipeline that ran the new model alongside the old one for six weeks before takeover. This gave the risk committee data to override on — they could see exactly which transactions the new model would have decided differently, and what the outcomes were.

The Meta3Agents infrastructure compressed the build phase considerably. The shadow-scoring orchestration, the feature store integration, and the human-review queue were configurations of existing capabilities rather than ground-up builds.

Before
14 bps
Fraud losses, with 8.2% false-positive rate
After (90 days post-launch)
13 bps
Fraud losses, with 4.8% false-positive rate — a 41% reduction

The headline number understates the impact. The downstream effect of unblocking 3.4% of transactions was a measurable lift in 30-day retention for new customers — about $4.2M in annualised retained revenue, against an engagement fee an order of magnitude below that.

Phase 01
Diagnose
3 weeks
Phase 02
Design
4 weeks
Phase 03
Build
7 weeks
Phase 04
Embed
4 weeks
"We'd been throwing models at this for two years. The thing that actually broke it open was a 30-minute meeting in week 2 where Liron asked what the customer support team was hearing. None of us had thought to look there."
— CTO · Series C consumer payments · Anonymized
— Case 02
HealthTechSeries BRadiology AI220 staffFull cycle

Patient triage that radiology trusted enough to actually use.

A Series B teleradiology platform had a working model and zero adoption. The radiologists ignored it. We didn't change the model — we changed how it asked. Time-to-triage on priority scans dropped from 37 minutes to 4. The model accuracy was the same throughout.

— The constraint

The engineering team had spent 18 months building a strong triage model. Sensitivity and specificity were genuinely competitive with published benchmarks. The problem was simpler and harder: the radiologists didn't trust it, and weren't using it. Adoption sat below 8%. The CEO was facing a board conversation about whether to sunset the entire initiative.

The Diagnose phase included four shadow sessions with active radiologists — sitting next to them while they worked. What surfaced wasn't a model problem. The interface was asking radiologists to defer to the AI. The interaction shape was wrong for the audience. Senior radiologists who'd been reading scans for 20 years don't defer to a model — they verify it.

We didn't touch the model. We rebuilt the interaction layer. The triage output stopped being a recommendation and became a queue ordering. The radiologist's screen showed scans ordered by AI-predicted urgency, with the prediction visible but no "you should do this next" framing. Authority stayed with the reader.

The second move was the disagreement loop. When a radiologist deprioritized a scan the AI had flagged urgent, the system asked one structured question: "why?" Five preset options plus a free-text field. Three months of disagreement data became the training feedback the team had been missing — and the radiologists, for the first time, felt they were improving the system rather than being measured by it.

By the time the Embed phase closed, adoption was at 89% and rising. The CEO's board conversation went from "sunset?" to "expand to four new clinical specialties."

Before
37 min
Time-to-triage on priority scans · 8% AI adoption
After (Embed phase, week 4)
4 min
Time-to-triage on priority scans · 89% AI adoption

The clinical impact mattered more than the operational one. In the four months following launch, the platform documented seven cases of pulmonary embolism caught at the triage stage that would, by their internal benchmark, have been delayed by 30+ minutes under the old flow. The CMO described that number as "the only metric I actually care about."

Phase 01
Diagnose
4 weeks · 4 shadow sessions
Phase 02
Design
5 weeks · with radiology team
Phase 03
Build
10 weeks
Phase 04
Embed
8 weeks · two pilot sites
"For the first 18 months we treated this as a model problem. It wasn't. The problem was that we were asking 50-year-old radiologists to take instructions from software, and they have correctly trained their entire careers to do the opposite. The fix was a UI decision."
— Head of Clinical AI · Series B teleradiology · Anonymized
— Case 03
RetailTechPre-IPODemand forecasting1,400 SKUsBuild + co-invest

Demand forecasting that survived a category collapse.

A pre-IPO specialty retailer had a working forecasting model — until the category it served collapsed during a regulatory shift. We didn't rebuild the model. We built a regime-detection layer that knew when the model was about to be wrong, and what to fall back on. Stockout days fell 23% the year following deployment.

— The constraint

The forecasting team had a respectable model — gradient boosted, well-featured, ~6% MAPE on stable categories. Then a category-wide regulatory change shifted demand patterns by 40% in six weeks. The model couldn't see the change coming and overstocked one direction while stocking out the other. $11M of inventory imbalance in a quarter.

The leadership team's initial framing was "the model isn't smart enough — let's get a better one." The Diagnose phase pushed back. No forecasting model can predict a regulatory shift it hasn't seen before. The right question was: how does the system know when its own predictions are about to fail?

We left the forecasting model untouched. We built a regime-detection layer sitting above it that monitored for distribution shift across 14 input signals — pricing elasticity, search volume, returns velocity, competitor stock-in indicators, regulatory news embeddings, and seven others. When the regime layer detected a structural break, it would degrade the model's prediction weight and route SKU-level decisions to a conservative envelope.

The second piece was the fallback envelope itself: not a worse model, but an explicit, simple rule-based system that the inventory team understood and trusted. When the AI couldn't see clearly, the system handed back to the humans on rails the humans had helped design.

This is also the case where the co-invest mechanism activated. The regime-detection layer was clearly productisable — it had value to other retailers facing similar volatility. We spun it out as a separate venture, with the original client as the anchor customer and a small equity stake retained.

Year before deployment
$11M
Annual inventory imbalance from the regulatory shock
Year following deployment
23% ↓
Reduction in stockout days · ~$3M working capital freed
Phase 01
Diagnose
3 weeks
Phase 02
Design
5 weeks
Phase 03
Build
9 weeks
Phase 04
Embed + spin-out
6 weeks
"The team kept asking 'what model do we need?' and Liron kept asking 'what does the model need to know about itself?' Once that question landed, the architecture wrote itself."
— VP Data & Analytics · Pre-IPO specialty retail · Anonymized

— If something here resonated

What's the problem
you'd want moved?

If one of these cases looked structurally like your situation, applications are open for next quarter's engagements. We read every one.