AI agent and automation case studies: numbers you can verify

We don't publish client names, domains or corporate details: external case studies run anonymised, and a named one requires the client's written consent. The numbers, however, are real: they come from marketplace settlement reports, logs, automated tests and reconciliations, not from pitch decks. Some of these are our own business — and there we also show what is still unfinished.

Case 01 / 07

Distributor of specialised livestock management software, around 100 farm clients

Challenge

A hundred clients kept asking the same questions about a complex foreign herd management system. Support could not scale, and the knowledge was scattered across documentation, email threads and training videos.

What we built

We assembled a digital knowledge corpus, including transcriptions of the training videos. Then we deployed a multi-tenant AI assistant: answers are built strictly from the corpus, every claim carries a source link, and when the data isn't there the assistant declines honestly instead of guessing. We added per-user conversation history, streaming output and a mobile version.

Outcome

  • A corpus of 236 documents and 1955 fragments, 8 thematic maps, zero broken links
  • 5 days from written specification to a working production domain
  • A hundred clients served by a single deployment: a hundred accounts, not a hundred installations
  • The system has been in production on a live domain since July 2026; where it is hosted and what data reaches the model provider are fixed in the contract

Stack: FastAPI, PostgreSQL (full-text search + vector index), Redis, React, nginx, Let's Encrypt

Case 02 / 07

Furniture supplier on a marketplace: a single console for the support team

Challenge

The backlog of unanswered buyer questions was growing faster than the team. Returns and reviews were handled by hand, with no roles, no response-time targets and no clarity on who owned what.

What we built

We built a customer enquiry platform: a register covering three enquiry types, response-time timers, role-based access, an automated return collector via the marketplace API, a resolution console, review disputes, Excel export and notifications. We also produced formal technical documentation and assembled a handover package.

Outcome

  • History migrated one to one: 149,191 orders, 111,406 messages, 54,976 reviews, 43 reply templates — nothing lost, nothing out of step
  • 749 automated tests green at platform transfer acceptance
  • Three independent quality passes, one of them a blind review by a different model family
  • Full round trip confirmed by a live answer delivered to a real buyer; a complete formal documentation set prepared to the national standard

Stack: FastAPI, PostgreSQL 14, Redis, React / Next.js, marketplace API, systemd, git-based deployment

Case 03 / 07

Advertising on a classifieds platform: the statistics that had been missing for years (the holding's own project)

Challenge

For years the furniture channel spent its advertising budget blind: impressions and spend came through as zeros. Internally everyone assumed the platform simply didn't hand that data over — and nobody had ever tested the assumption.

What we built

We went back to the platform's own documentation and found that our requests had been going to a deprecated API version for years — one whose schema has no impressions or spend at all. We rewrote the collectors against the current version, added wallet and call data, backfilled the history, put collection on a schedule, and added a watchdog that notices when a metric disappears instead of staying quiet.

Outcome

  • A 30-day backfill brought 108,649 impressions and 36,277 ₽ of spend into the system — where there had previously been zeros
  • The real cost of a contact finally calculated: 227 ₽ per contact at 3.74 ₽ per click
  • Proved on the data that the bid barely moves the number of contacts (correlation 0.02): raising it bought spend, not results
  • For the first time, the advertising budget decision rests on the platform's own figures rather than on an assumption

Stack: Python, FastAPI, PostgreSQL, platform statistics API, cron collectors, data watchdog

Case 04 / 07

Wildberries settlement reconciliation: 1,953,200 ₽ of understated income found (the holding's own project)

Challenge

Marketplace income was booked on a guess: the rule deducted a flat 25% commission and was labelled in the code itself as an estimate. Not a single one of the platform's actual settlement reports had ever been loaded into the database. Which left the owner's central question unanswerable: is this channel profitable or not?

What we built

We pulled the real settlement reports from the platform API and broke the money down component by component: commission, acquiring, logistics, storage, penalties, deductions. That exposed the root of the confusion — the seller portal's columns are calculated from different bases, and the buyer's discount is funded by the platform, not by the seller. We built an independent reconciliation against the portal and covered it with tests. Plan and code went through double-blind review by two different model families: three consecutive “red” verdicts, every one of them justified.

Outcome

  • Reconciliation against the seller portal closed at 0.00 ₽ — 15 reports, 12 settlement components
  • The forecast had understated income by 1,953,200 ₽ (21.7%) over seven months: a systematic error, never once erring the other way
  • Actual deductions run at roughly 13.1%, against the 25% hard-coded into the model
  • The channel proven profitable — roughly 1.73M ₽ net over seven months — overturning the earlier conclusion that it was losing money

Stack: Python, FastAPI, PostgreSQL, marketplace settlement API, cron synchronisation, automated tests and a reconciliation watchdog

Case 05 / 07

Marketplace content: 648 of 650 descriptions approved on the first submission (the holding's own project)

Challenge

A catalogue of 650 live furniture listings with no usable descriptions. Platform moderation rejected the texts without explaining why: the same rejection code every time, and no indication of what it objected to. Writing that volume by hand would have taken copywriters months.

What we built

We built an AI content pipeline and derived the moderation rule experimentally: we submitted trial listings and compared the accepted ones against the rejected ones until it became clear that the platform was rejecting the structure of the enumeration, not the words. We encoded that rule into a validator that checks every text before submission. Then we generated and uploaded descriptions across the whole catalogue, added rich content and grouped listings into collections.

Outcome

  • 650 of 650 descriptions written — 1.8M characters, median 2808 characters per listing
  • Moderation approved 648 of 650, with zero rejections
  • Rich content on 647 listings, median platform content rating 77.5
  • The moderation rule derived and now reused: one fact per sentence, at least 18 sentences, average length under 150 characters
  • Still in progress, and we don't hide it: 127 listings do not yet surface in the platform's search — that is the next stage

Stack: Python, generative content pipeline, text validator, marketplace API, PostgreSQL

Case 06 / 07

In-house product: a secure corporate messenger

Challenge

The holding needed an internal communication channel that could live inside its own perimeter: no public cloud, encrypted, with calls, and with full control over who gets in at all.

What we built

We developed a self-hosted messenger: encrypted messaging, two-factor authentication, invite-only access, one-to-one calls routed directly between devices and group calls through our own media server. After the first release the product went through cross-vendor review — two different model families reading the code blind to each other.

Outcome

  • Version 1.0.0 running inside our own perimeter since April 2026
  • Cross-vendor review found and closed 32 defects, 12 of them critical — the ones internal review had missed
  • Group calls for up to 5 participants through our own media server; one-to-one calls peer to peer between devices
  • Data and conversations are stored on the company's own server: there is no external cloud in the storage design

Stack: FastAPI, PostgreSQL, symmetric encryption, Next.js 16 / React 19, Tailwind 4, SFU media server, TURN

Case 07 / 07

Tools and equipment product line (the holding's own project)

Challenge

The line was selling on two marketplaces with no real analytics, no coherent brand and no website of its own. Nobody knew which items earned money and which merely occupied space.

What we built

We ran the full cycle: sales export analysis and per-item unit economics, rebranding, keyword research, a new website and deployment. Listing and scene content came from our own content factory.

Outcome

  • 77 SKUs analysed on unit economics: it became visible which items earn and which merely occupy the warehouse
  • The line's actual result calculated: 4.3M ₽ of quarterly revenue, 916K ₽ of profit, a 21.2% margin and a 92.7% return on the money invested
  • A keyword core of 110 search queries, plus a usability and conversion audit across 12 pages
  • The line's own website built and deployed to production

Stack: Vite, React, three.js / R3F, generative content pipeline, nginx

Recognise your situation?

We'll walk you through the project closest to your case from the inside — live, screen shared, no slides.

Request a walk-through