The post has been translated automatically. Original language: Russian
We have rolled out the "Turnkey Business" section in Malik AI. Briefly: you describe an idea in one paragraph, eight agents take turns putting together a plan from it — from the founder's decision to the revenue model — and then using a separate button, the same plan is broken down into assumptions.
The product is in beta. Therefore, below is not a presentation, but an analysis of the decisions that we made during the assembly. I would have liked to read some of them myself six months ago, when we started.
Why do the agents take turns instead of running in parallel?
Parallel launch is faster and cheaper — eight calls at the same time, glued the results, done. That's how we started. And we got eight texts that don't know about each other: marketing advertises functions that the product agent has deleted from the MVP; sales count money that is not in the revenue model.
Now each agent receives the initial idea, all the ready-made documents of previous agents, and direct instructions not to repeat what has already been written. It's slower and more expensive. But the output is a coherent plan, not eight parallel opinions about the same business.
The second consequence of the same decision is that if the agent falls, the chain stops and shows at which step. We deliberately do not substitute a stub and do not continue without it — a company that is half assembled, but painted as ready, is worse than an honest stop.
The length of the entrance is a technical detail that breaks such chains.
We have a request length limit at the entrance: guest — 3000 characters, free account — 6000. Eight ready-made documents don't fit into anything.
The naive solution is to trim by the limit. In practice, this is the worst possible scenario: the model receives a text that is cut off in the middle of a word and reads it as a thought that the author has dropped. She begins to "finish writing" for the agent, instead of analyzing the plan.
What we did: we calculate the budget of characters, divide it equally between the stages, cut each one along the sentence boundary, put an abbreviation marker and write in plain text in the header to the model that it contains excerpts, not complete documents. The difference in response quality is noticeable to the naked eye — the model stops speculating and starts quoting.
Templates without fictional numbers
The section contains 11 industry blanks in 8 categories — coffee shop, store, agency, delivery, rental, restaurant, fitness, SaaS, logistics, tourism, courses. Each billet has 8 industry rules and 6 metrics within it, according to which decisions are actually made in this industry.
The main rule that we have established for ourselves is that there is not a single invented amount, rental rate, tax rate or payback period in the blanks. Neither "rent in the center is X tenge per square meter," nor "the margin in this niche is usually Y percent." Not because we were too lazy, but because the figure that the AI called in a confident tone lives longer than the slip next to it. A person will take it into account and will not remember where it came from.
Instead of a number, the blank tells you what number you need and where to get it. There is a separate check in the tests for this.: she crashes the build if a currency sign or percentage appears next to the amount in the template text.
And one more little thing that turned out to be important: the instructions compiled from the template are in an open text field, they are visible and can be edited. What is in this field is exactly what all eight agents will receive. There is no hidden system tool that "actually" solves it.
The button for which everything was done
When the plan is assembled, a separate button appears — "Strength check". She sends the assembled plan back to the model with one task: to disassemble it the way the investor will do it.
At the exit:
- The verdict is that the plan is verifiable or it is a beautiful text.
- A table of assumptions: the assumption itself (a quote from the plan, not a general phrase), the figure that solves it, the way to check this figure in a week, and the result in which the plan is dead.
- What the plan claims, but has not proven.
- Deathbed analysis — a year has passed, the business is dead, the most likely cause of death.
- The investor's first question is the most inconvenient one for this particular plan, and whether the plan answers it right now.
- A checklist of what needs to be checked before spending money.
There is deliberately no rating on a one-hundred-point scale. We removed it after we looked at what was happening to it: the person gets 74 out of 100, corrects the wording, gets 81 and leaves satisfied. Evaluation turns into something that is optimized instead of business. The list of assumptions cannot be optimized — you can only go and check it.
This is a separate button, not the ninth automatic step. First, it's another challenge to the model. Secondly, the moment when a person decides to submit his plan for analysis is the only one in which the result will be read at all.
What is important to say directly
Malik AI is a router for third—party provider models, not its own trained models. The section runs on top of our business mode engine (58 modes in 12 sections), with automatic switching between providers: if one is unavailable, the request goes to the next, and the response shows who exactly answered.
The section is in beta. The quality of the analysis depends on how detailed the idea is described: on two lines, agents begin to think, and it shows. Before posting, the section goes through 97 automatic checks — from "the template does not contain fictitious numbers" to "the section really opens from navigation" — but the checks catch regressions, and do not guarantee that the plan is good.
Why this post?
I want to discuss two things with those who do multi-agent things in practice.
First: how do you solve the problem of transferring context between agents when the total volume has long exceeded the request limit? We cut according to budget and proposals — it works, but it's rough. The intermediate summation of each stage seems to be more correct and at the same time more dangerous: the adder is another place where you can lose exactly the detail for which everything was started.
The second: how do you keep the model from inventing numbers in the subject areas? We currently have this rule in prompta, plus a test for template texts. We don't have any verification of the model's response itself, and I'm not sure if it's even possible cheaply.
If you try the section and see that the analysis has gone into general places instead of your plan, write down with what formulation of the idea it happened. This is the most useful bug report we can get.
Мы выкатили в Malik AI раздел «Бизнес под ключ». Коротко: вы описываете идею одним абзацем, восемь агентов по очереди собирают из неё план — от решения основателя до модели выручки, — а потом отдельной кнопкой этот же план разбирают на допущения.
Продукт в бете. Поэтому ниже — не презентация, а разбор решений, которые мы принимали при сборке. Часть из них я бы сам хотел прочитать полгода назад, когда мы начинали.
Почему агенты идут по очереди, а не параллельно
Параллельный запуск быстрее и дешевле — восемь вызовов одновременно, склеил результаты, готово. Мы так и начали. И получили восемь текстов, которые не знают друг о друге: маркетинг рекламирует функции, которые продуктовый агент вычеркнул из MVP; продажи считают деньги, которых нет в модели выручки.
Сейчас каждый агент получает на вход исходную идею, все готовые документы предыдущих агентов и прямую инструкцию не повторять уже написанное. Это медленнее и дороже. Но на выходе связный план, а не восемь параллельных мнений об одном бизнесе.
Второе следствие того же решения: если агент упал, цепочка останавливается и показывает, на каком шаге. Мы намеренно не подставляем заглушку и не продолжаем без него — компания, собранная наполовину, но нарисованная как готовая, хуже, чем честная остановка.
Про длину входа — техническая деталь, которая ломает такие цепочки
У нас на входе стоит ограничение по длине запроса: гость — 3000 символов, бесплатный аккаунт — 6000. Восемь готовых документов не влезают ни во что.
Наивное решение — обрезать по лимиту. На практике это худший вариант из возможных: модель получает текст, оборванный на середине слова, и читает его как мысль, которую автор бросил. Она начинает «дописывать» за агента, вместо того чтобы разбирать план.
Что сделали: считаем бюджет символов, делим его поровну между этапами, режем каждый по границе предложения, ставим маркер сокращения и в шапке прямым текстом пишем модели, что перед ней выдержки, а не полные документы. Разница в качестве ответа заметна невооружённым глазом — модель перестаёт домысливать и начинает цитировать.
Шаблоны без выдуманных цифр
В разделе 11 отраслевых заготовок в 8 категориях — кофейня, магазин, агентство, доставка, аренда, ресторан, фитнес, SaaS, логистика, туризм, курсы. У каждой заготовки внутри 8 правил отрасли и 6 метрик, по которым в этой отрасли реально принимают решения.
Главное правило, которое мы для себя завели: в заготовках нет ни одной придуманной суммы, ставки аренды, налоговой нормы или срока окупаемости. Ни «аренда в центре — X тенге за квадрат», ни «маржа в этой нише обычно Y процентов». Не потому что мы поленились, а потому что цифра, которую ИИ назвал уверенным тоном, живёт дольше, чем оговорка рядом с ней. Человек унесёт её в расчёт и не вспомнит, откуда она взялась.
Вместо числа заготовка называет, какое число нужно и где его брать. На это стоит отдельная проверка в тестах: она валит сборку, если в тексте шаблона появился знак валюты или процент рядом с суммой.
И ещё одна мелочь, которая оказалась важной: инструкция, собранная из шаблона, лежит в открытом текстовом поле, её видно и можно править. То, что стоит в этом поле, — ровно то, что получат все восемь агентов. Никакого скрытого системного промпта, который «на самом деле» решает.
Кнопка, ради которой всё делалось
Когда план собран, появляется отдельная кнопка — «Проверка на прочность». Она отправляет собранный план обратно в модель с одной задачей: разобрать его так, как это сделает инвестор.
На выходе:
- Приговор — план проверяемый или это красивый текст.
- Таблица допущений: само допущение (цитатой из плана, а не общей фразой), цифра, которая его решает, способ проверить эту цифру за неделю, и результат, при котором план мёртв.
- Что план утверждает, но не доказал.
- Предсмертный разбор — прошёл год, бизнес мёртв, самая вероятная причина смерти.
- Первый вопрос инвестора — самый неудобный по этому конкретному плану, и отвечает ли план на него прямо сейчас.
- Чек-лист того, что нужно проверить до того, как тратить деньги.
Сознательно нет оценки по стобалльной шкале. Мы её убрали после того, как посмотрели, что с ней происходит: человек получает 74 из 100, правит формулировки, получает 81 и уходит довольным. Оценка превращается в то, что оптимизируют вместо бизнеса. Список допущений оптимизировать нельзя — его можно только пойти и проверить.
Это отдельная кнопка, а не девятый автоматический шаг. Во-первых, это ещё один вызов модели. Во-вторых, момент, когда человек сам решает отдать свой план на разбор, — единственный, в котором результат вообще будет прочитан.
Что важно сказать прямо
Malik AI — маршрутизатор к моделям сторонних провайдеров, а не собственные обученные модели. Раздел работает поверх нашего же движка бизнес-режимов (58 режимов в 12 разделах), с автоматическим переключением между провайдерами: если один недоступен, запрос уходит следующему, и в ответе видно, кто именно ответил.
Раздел в бете. Качество разбора зависит от того, насколько подробно описана идея: на двух строчках агенты начинают додумывать, и это видно. Перед выкладкой раздел проходит 97 автоматических проверок — от «шаблон не содержит выдуманных цифр» до «раздел действительно открывается из навигации», — но проверки ловят регрессии, а не гарантируют, что план хороший.
Зачем этот пост
Хочу обсудить с теми, кто делает мультиагентные штуки на практике, две вещи.
Первая: как вы решаете задачу передачи контекста между агентами, когда суммарный объём давно перерос лимит запроса. Мы режем по бюджету и предложениям — это работает, но это грубо. Промежуточная суммаризация каждого этапа кажется правильнее и одновременно опаснее: суммаризатор — ещё одно место, где можно потерять именно ту деталь, ради которой всё затевалось.
Вторая: как вы удерживаете модель от выдумывания цифр в предметных областях. У нас это сейчас правило в промпте плюс тест на тексты шаблонов. Проверки самого ответа модели у нас нет, и я не уверен, что она вообще возможна дёшево.
Если попробуете раздел и увидите, что разбор ушёл в общие места вместо вашего плана, — напишите, с какой формулировкой идеи это случилось. Это самый полезный баг-репорт, который мы можем получить.
Share
