A system of eight AI agents told me what I didn't want to hear: the problem wasn't the product — I had stopped promoting it

Context

The product has a single founder and eight areas, each demanding daily attention. Unit economics. Funnel conversion. Cohorts and LTV. Referral mechanics. Customer support. Product decisions. Content. And on top of all that, coordination — because the areas are interlinked, and a decision in one breaks the metrics in another.

Hiring eight specialists for an early-stage product is out of the question: even part-time, each costs 60,000–90,000 rubles a month, which is half a million for a team there is no money to pay yet.

The alternative is to do it yourself. I tried. An honest estimate: walking through all eight areas and pulling them into one picture takes two to three days. Not hours — days. Which means in practice it happens once a month, once a fortnight at best. And a problem that appears on the 5th gets discovered on the 25th.

The scenario I wanted to learn to catch looked like this: marketing pours in traffic, conversion dips, acquisition cost climbs. Three facts living in three different places, each tolerable on its own. Only someone looking at all three at once can see “we're pouring money into a leaky bucket”.

Spoiler: that's not what the system found. It found something worse — more on that at the end.

Constraints

• Independence from my work machine. A closed laptop must not stop a single process. Everything lives on a server
• Visible spend per agent. With one shared key, there's no telling who is burning the budget and who should be moved to a cheaper model. So: a separate key for every agent
• No calls between agents. Eight processes calling each other over an API means race conditions, cascading failures and debugging that can't be reproduced. Exchange happens through files only
• Strict write permissions. Every agent reads everything but writes only to its own files. It never touches anyone else's — even when it sees an obvious error there, it reports it instead
• The off-the-shelf skill library didn't fit. The skills taken as a starting point were written for Western subscription SaaS. The product is a one-off gift purchase on the Russian market. Porting them as-is produced advice about churn and MRR for a product that has neither
• Reports must not turn into noise. Eight agents writing every day is a guaranteed way to stop reading them within a week

Solution

What you get

Every morning at 08:30, a short briefing arrives: what happened overnight, whether there are anomalies, how much was spent, what the main task of the day is. On a quiet day, it's three lines. In the evening, from 19:10 to 19:30, come the reports by area — each with its own number and its own worry.

Plus an investigation mode: ask any question in plain language, and the system digs through every area at once rather than just the one you happened to guess at.

The two or three days of manual analysis are gone. There are three lines in the morning instead.

How it works

A department of eight roles: an economist, a CRO, a data analyst, virality, customer support, a product strategist, a content marketer and a supervisor over all of them. Each owns its area and comes online as that area fills up with data.

There is one source of truth for everyone — an append-only events table where the bot records the entire funnel from questionnaire to delivery, including the traffic source. Nobody goes into anyone else's data directly: each agent reads the events, computes its own numbers and writes the result to its own file in a shared folder.

Staggering the reports by the minute isn't cosmetic. It sets the reading order and makes it instantly obvious if someone hasn't reported.

The supervisor is the most elaborate role and the main value of the design. It reads everything but writes only to its own files. Its job is not to retell seven reports but to find the links between areas that are invisible from inside any one of them. It resolves contradictions when two agents reach different conclusions from the same data. It checks that the others are alive by file modification times. It keeps track of spend. It catches anomalies — a delivered order with no payment, API spend climbing with no sales, referral fraud. And it finds the gaps: areas that formally nobody is responsible for.

Against noise there is a brevity standard and three priority levels — red pings immediately, without waiting for the evening.

Changes to agent behavior go in only through the control layer and are saved to an overrides file. Telegram is strictly an output channel. That's a deliberate restriction: the notification channel must not be the control channel, or the configuration spreads across chats and stops being reproducible.

Architecture

A file bus instead of inter-process calls. A shared folder with one file per area: economics, funnel, analytics, referrals, support, product, marketing, digest. One owner per file — write conflicts are impossible by construction, not by agreement.

A single record format across all agents — otherwise reading someone else's files turns into parsing.

The supervisor as the single entry point. It maintains the project overview file that any new agent or human comes to in order to understand the current state.

Heartbeat by file timestamps rather than a separate protocol: if a file hasn't been updated, the agent is considered down.

Separate keys per agent plus spend tracking. Models are matched to roles: the supervisor runs on the most capable one, the rest on cheaper ones. Hence the spread in spend: $3 out of $4.50 in a week goes to the supervisor alone.

A skill layer: the library is localized into Russian and reworked from subscription logic to one-off purchase logic before being installed on an agent.

Stack

Outcome

The system runs autonomously. The internal running cost of my own loop is about 2,000 ₽/mo in model spend, two thirds of which goes to the supervisor — and that's the right split: the one who pulls the picture together should think the most. As a service — with a dedicated server, set-up for your product and ongoing support — the whole fleet of 8 agents costs 45,000 ₽/mo.

But the main result turned out not to be the savings.

One morning the briefing reported: zero sales, zero bot launches, no anomalies, zero spend. Last sale — five days ago. And then the line this whole thing was built for:

“Not an anomaly but the crux: marketing has been silent since 17 July — zero posts, no traffic into the bot, hence no sales. There is no leaky bucket — the bucket is empty.”

The supervisor didn't start optimizing conversion. It didn't propose an A/B test. It didn't generate a chipper report on a funnel of three orders. It looked at every area at once and named the real cause: the product isn't selling because it stopped being promoted. And it set the task of the day — start publishing according to the content plan; fourteen posts are ready and waiting.

A specialist inside a single area won't see that. A conversion specialist will fix conversion. An analyst will look for trends in three sales and honestly write that there isn't enough data. You can only see it from above — and that is exactly what the eighth agent, the one that computes nothing itself, is for.

What I'd do differently

• The file bus should have been the choice from day one. The temptation to do it “properly”, with services between agents, was strong. Eight processes calling each other are impossible to debug. One owner per file removes a whole class of problems architecturally, not through discipline
• The ban on silently fixing someone else's work turned out to matter more than autonomy itself. Without that rule, an agent that spots an error in a neighbouring area starts “helping”, and a week later nobody knows who computed what
• Eight reports a day means zero reports read. The brevity standard and priorities didn't come at once — they came after it became clear that without them the system turns into spam you stop opening. The usefulness of a multi-agent system is limited not by the quality of the agents but by the discipline of their output
• Launching all eight at once was a mistake. Three of them worked in areas with no data yet and produced correct but empty reports. The right way is to switch an agent on once its area has something to say
• Off-the-shelf skills don't port between markets mechanically. Localizing into Russian is the smaller part of the job. The bulk of it is reworking the monetization logic
• The notification channel must not be the control channel. Changes only through the control layer; the messenger is strictly for output

Where next

People also look at

Need a loop that looks at your business as a whole and tells you the truth rather than what you'd like to hear?

Get in touch — we'll work out what can be automated in your case.

I reply the same day, usually within a couple of hours.