DEV Community: Maksim Ilin

AI adoption in a company: where to start when nobody knows where to start

Maksim Ilin — Sun, 01 Nov 2026 22:50:34 +0000

In Russian we gave this process an ugly word, iiizatsiya, built the same way as computerisation, and we know how it sounds. But it says straight away what it is about: AI comes into a company the way computerisation once did. Not as a separate project with a slide deck and a contractor, but as a change in how people do their work. In English we will call it AI adoption. What AI native means and why it is not the same as saying we use AI, we covered in the first article. This is the practical part, for the owner of a small company who has no IT person but does have the question we hear word for word: where do we even start?

We think that within three or four years the answer to that question becomes a market of its own. A telling story: a friend of ours, one of the founders of a large online school, sold it a few years ago and now runs a small AI agency of one or two people, telling companies what to adopt and where to begin. The demand is there because almost nobody knows the first step. Below is our version of that first step, and we begin with a mistake we have seen many times.

The mistake everything starts with

Picture a small company where an accountant comes in two days a month. The owner decides: the operations are routine, I will build a bot and it will replace the accountant. He builds it, and the bot does not work, and not because it is bad: the owner simply does not do this job every day and does not know what it actually consists of, which documents arrive mangled, what the bank is really asking, where the numbers disagree. The accountant knows, but nobody invited her to the project. And a product nobody corrects every day does not improve.

Hence the first rule, more important than all the others: the assistant is corrected and improved by the person who does the work, not by a contractor, not by the IT person, and not even by the owner unless the owner does that process personally. An employee like that can only be replaced by another employee like that. But that employee can build an assistant for themselves, if someone nearby walks them through the first step and takes over the part nobody likes doing.

Step 0. Who does what

The owner picks a process and gives the person responsible for it two hours a week to tinker with the agent. Without those two hours nothing happens, and this is the most common reason pilots die.

The person who does the process builds the agent. It sounds frightening until you see that the first agent is a chat with a role, an instruction and materials. One of us walked a psychologist with no technical background through it in a three-hour call, and she kept using it afterwards.

A consultant is needed for three things: to go through the first step together, so the person sees that it works and does not quit on day two; to take over everything manual and unloved, registrations, tokens, access, connecting to Telegram or the website; and to be reachable in the first week, when something breaks. Further down we say plainly what that costs.

Step 1. One process that repeats every day

There are three criteria: the process repeats every day, not twice a month; the input materials already exist, documents, correspondence, standard questions, a price list; and a person can check the result without getting into the technology.

Good candidates: answering the same customer questions, first-pass sorting of incoming enquiries, preparing estimates and quotes from a price list, answering from internal documents. Bad candidates: come up with our marketing, analyse our business, and generally anything that cannot be checked in five minutes.

Our own example looks like this: the School of Great Books has transcripts of several open meetings. People arrive in the Telegram channel and ask the same questions: what is this, how does it work, who is it for, where do I start. The process repeats every day, the materials are there, and the school's founder checks whether an answer is right in a minute. That is the first agent we are building now.

If you cannot pick a process, there is an AI readiness audit for exactly that: one or two days of review, and at the end two or three candidates with an estimate, and an honest answer that AI is not needed here yet, if that is the case.

Step 2. The first agent in a chat, in one evening

Open Claude or ChatGPT. Create a project, which is a folder. Put the materials in it: transcripts, the price list, instructions, examples of good answers. Start a chat inside the project and write it an instruction in ordinary words: you answer questions about the school, only from these materials, and if the answer is not in them you say so and offer to put the person in touch with a human.

Then the most important part: ask it ten real questions that customers ask, not invented ones, taken from your correspondence. Where it answers wrong, fix the instruction or add material. That is all there is to improving an assistant: not training a model, but editing the instruction and the materials. The project and the chat with a role take three minutes to create, the ten questions take an evening.

Do not start with servers, your own models and a Mac mini. We managed to look up Mac mini prices before we had built a first agent, and that was a mistake in the order of operations. Your own server and your own model are the next question. The first one is: does the agent answer ten real questions correctly.

Step 3. Put the agent where the people are

While the agent lives in your chat it helps only you. For it to answer customers it has to be where the customers are: in a Telegram bot, on the website, in the CRM.

This is where the one part that really is manual shows up. For Telegram it means going to BotFather, answering two questions (the bot's name and its address), copying the token and handing it to whoever will assemble the bot. Registrations, email accounts, passwords, tokens and access are things nobody likes doing, with AI or without it, and they stay manual in every project. We consider this the biggest headache of every rollout, and it is exactly the part that makes sense to hand to a consultant.

After that the bot can be assembled in one conversation with Claude Code or Codex, if you have a subscription, by voice or by text. GitHub is not required for this, and that is a frequent question. What is required is the token and a description of what the bot should do, the same thing you already wrote in the instruction to the agent.

Step 4. Correct it every day

The agent does not learn by itself, and this is worth understanding before you start. The model it runs on does not change from your conversations: tomorrow it is exactly the same as today, and it does not remember yesterday's mistakes unless you wrote them into the instruction. Learning happens when a neural network is trained or fine-tuned, and none of that is happening to your agent. The only things that change in an agent are the things you change: the instruction, the materials in the project, the examples of good and bad answers.

So the agent gets more accurate exactly as fast as the person who does the process looks at its answers and edits the instruction. Two weeks of such editing, in our experience, give more than a month of development without a user, because the mistakes are found on real questions rather than invented ones.

What to count after two weeks to know whether it works: how many manual steps disappeared, how much time goes into checking answers, which mistakes repeat, and whether the person can stop the agent without a technician. More on evaluating a pilot in the article on AI agents for business.

The mistakes we have seen most often

The first two are described above: replacing a person with a bot instead of helping the person build an assistant, and building something nobody uses every day. The second one kills a project in about a month, and it is not noticed right away: the bot is up, it seems to work, it is just that nobody opens it.

The third is subtler, and it is about the consultant rather than the client. It feels as though once you have handed over the knowledge the person will manage alone and you are out of work. In practice it is the other way round: once you have taught ten people to launch agents, they stay on the first-level questions while you move on to the second level, and they keep coming back with new questions. So after the handover the consultant's work does not end, it changes: instead of the first launch he handles the second-level questions. Until recently one of us was afraid of exactly the opposite.

Two more we see in others: starting with infrastructure, a server, a model, parameters, when the first question is quite different, does the agent answer ten questions from the correspondence correctly; and waiting for the perfect version, although a rough one that is already in use will get further in a month than a perfect one sitting in a folder.

What it costs

Subscriptions: if you already pay for ChatGPT, you already have Codex, it is included, you only need to install the app on your computer. One of us had paid for ChatGPT for a long time and found this out only recently. Claude with a subscription works too. A Telegram bot is free in itself, hosting for it costs a few euros a month.

Time: one evening for the first agent in a chat, then two hours a week from the person who does the process.

The consultant: with one of the authors, Maksim Ilin, it works like this: the first step is free, a twenty-minute call on which you pick the process and agree what the first working version looks like. There is a button for a company and a button for a person starting from zero on the home page of ilinmaks.com. After that the prices are public: a readiness audit from 450 euros, an agent for one process from 1,500 euros with a first working version in two weeks.

What comes next

The first bot built this way is for the School of Great Books, and it is being built by the school's founder, not by a developer. When the bot has worked its first week and answered its first real questions, a link to a case study with numbers will appear here: how many questions, how many edits to the instruction, what had to be done by hand.

Dmitry Merkulov, co-founder of the School of Great Books. Maksim Ilin, AI engineer and AI consultant.

Originally published at ilinmaks.com.

AI native: what it means and why the word artificial gets in the way

Maksim Ilin — Sun, 01 Nov 2026 22:49:03 +0000

The competition of the next few years will not be between artificial intelligence and people. It will be between people who use AI and people who do not. Plenty of people say this now. We tested it on people we know, and the picture turned out harsher than we expected.

One of us has a friend who opened a small IT company in a provincial town. We built him a website in twenty minutes, live on a call, then there was a second call, and the advice was a single sentence: sign up for ChatGPT and start there, everything else can wait. Three months passed. He still has not signed up. He pays for a CRM, calls clients the old way and has no idea what the tool he was shown can do. He is not stupid. In his picture of the world this is not a tool yet, it is something from the news. And there are more people like him than it seems from inside our bubble, where everyone is already vibe coding.

Who stays, and who stops understanding

Shoes make a good analogy here. There are very good Italian boots for three hundred euros, factory made, excellent production. And there are boots for a thousand from a craftsman who keeps a small workshop, refuses on principle to grow and gives a lifetime guarantee. Both are professionals, just of different kinds. Programmers will go the same way: the exceptional ones will stay and keep writing code by hand, with AI next to them. And the many who never figured it out will stop understanding what is happening in their own profession.

Companies without AI will not disappear either. For a long time we both assumed IT companies without AI would simply fold, but no: they will compete the way a corner shop competes with a supermarket chain, by being open until eleven and selling cigarettes one at a time. Here is an example a friend from a large online school gave us: for six months he asked his developers to fix a bug in their software, then he opened the code in Claude himself, asked it to find the bug, got the answer in a minute and forwarded it to the developers. Nobody hunts for bugs like that by hand anymore when AI is available: the model gets through in a minute what takes a person weeks. That is the difference between a company where AI is built into the work and a company where it only exists on paper.

The word that spoils everything

In Russian, our first language, AI is called iskusstvennyi intellekt, and the adjective iskusstvennyi carries a sense of fakeness, as in artificial leather or an artificial smile. Half of the Russian-language arguments about whether this is real intelligence and whether it understands anything grow out of that one word.

In English the word is different. Artificial is the antonym of natural: not fake, but made by hand. In that sense glasses, the alphabet and plumbing are artificial, and nobody calls them unreal. The word also carries the root art: skill, craft, the kind of work where you have to think first and then make something. Russian has no good word for this, and we did not invent one. But keeping the difference in mind helps: the subject is not an imitation of intelligence, it is a tool somebody made, and it works with text, code and decisions.

AI native: built in, not kept separate

Native means built in, at home, part of the place. An AI-native company is not the one with a ChatGPT subscription in the IT department. It is a company where AI sits inside the daily work: in taking enquiries, answering customers, preparing quotes, going through documents. It is no longer a separate project with its own budget and contractor, it is part of how people do their jobs.

The test is simple: ask who in the company corrects and improves the AI assistant. If the answer is the contractor, or the IT guy when he has time, that is not AI native yet. If the answer is Anna from the enquiries desk, whose agent has been answering routine questions for three months while she keeps adjusting it, that is it.

For the Russian market we proposed a word of our own, iiizatsiya, built the way computerisation was built, and it is as clumsy as it sounds. In English we will simply say AI adoption. Whatever the word, it describes the process honestly: AI comes into a company the way computerisation once did, not as a project but as a change in how work gets done. We think that within three or four years this becomes a market of its own, because most companies do not even know where to begin. The phrase AI consultant is understood today about as well as Telegram channel was understood ten years ago. There is no point waiting until everybody gets it, it pays to stake out the ground before others do.

Why vibe coding does not replace the programmer

We arrived at the main idea of this article through a mistake we have seen many times, in others and in ourselves.

Picture a small company where an accountant comes in two days a month. She closes the books, reconciles documents, answers the bank's questions. The owner looks at this and thinks: the operations are routine, I will build a bot and it will replace the accountant. He builds it, the bot turns out fine, and it still does not work, because the owner does not do this job every day and does not know what it actually consists of: which documents arrive mangled, what the bank is really asking, where the reports disagree with reality. The accountant knows all of it, but nobody invited her to the project.

The conclusion is plain: an employee like that can only be replaced by another employee like that. The right move is different: the accountant herself, with a guide beside her, builds her own assistant. She knows what it has to be able to do, she will see where it goes wrong, and she will fix the instruction. The assistant does not learn on its own: the model it runs on does not change from your conversations, only the instruction and the materials you gave it change. So the assistant gets more accurate exactly as fast as the person doing the work corrects it. A product nobody corrects does not improve, it just sits there.

That is also the real meaning of vibe coding: not a replacement for the programmer, but an extension of a function the person already understands well. The accountant extends accounting, the school administrator extends student intake. If it were a replacement for the programmer, the vibe coder would remain a programmer, just with a different tool. Instead he becomes someone else: a person who keeps several agents and runs them like a small company.

The words themselves will keep changing. Andrej Karpathy coined the term vibe coding in early 2025, and it meant exactly that: a programmer coding in a relaxed way, trusting the model and not reading every line. A programmer friend with fifteen years at a large telecom told us recently that the term is already dated, nobody says it anymore, now it is agentic and AI native. Fine, the word will change and the substance will stay: what began as relaxed programming grew into something else, where you no longer need a programmer, you need a person who knows their own process and can set a task.

What an agent is, without the jargon

Strictly speaking, the industry calls an agent a system that acts rather than just answers: it calls tools on its own, opens websites, writes to a database, takes several steps in a row until it reaches the goal. For a first step that strictness is unnecessary. In the everyday sense, any new chat in Claude or ChatGPT that you have given a role, an instruction and materials is already the seed of an agent. Tell it: you are a marketer, answer like one, and you already have something to work with. A project is a folder: inside are the materials and several chats like this. Where to put it later, in a Telegram bot, on the website, in the CRM, is a separate question, and it gets decided once the agent in the chat is already answering correctly.

Creating a project, naming it and starting a chat with a role in it takes three minutes. We have tried this with people who have never written a line of code. What stays manual is the registrations: go to BotFather, answer two questions (the bot's name and its address), copy the token. We consider this the least loved part of every AI project, and it is the part that never goes away.

What we are doing about it ourselves

The first agent built on this logic is in progress now: a bot for the School of Great Books that answers newcomers from the transcripts of several open meetings and offers to help them pick a group. It is being built not by a developer but by a co-founder of the school, because only he knows what newcomers actually ask. When the bot has worked its first week, we will describe it with numbers: how many questions, how many edits to the instruction, what had to be done by hand.

How to choose the process, who should do it, what stays manual and what it costs, we cover in the second article, on AI adoption in a small company. And on the home page of ilinmaks.com there are two free twenty-minute calls: one for a company, the other for a person starting from zero.

Dmitry Merkulov, co-founder of the School of Great Books. Maksim Ilin, AI engineer and AI consultant.

Originally published at ilinmaks.com.

I put my own face on the front page. How I launched Likeness House

Maksim Ilin — Fri, 09 Oct 2026 16:30:28 +0000

On 8 October Likeness House was a plan in a document. On 9 October it had a name, a domain, a site in English and Russian, a client account and an admin panel. This note covers what Likeness House is, why I started with my own portrait, and how the site is put together.

What Likeness House is

Likeness House builds your digital twin around your memories, voice, appearance and way of thinking. The events that shaped you. The decisions you made. The stories you have only ever told out loud. You choose what goes in and what stays private. The idea is to preserve something of yourself in history, in a form you and the people you choose can return to and speak with.

Imagine your twin years from now. You add a memory, a conversation, a new chapter of your life. Its portrait looks back at you. You hear your own voice. As technology advances, the ambition is for it to draw more closely on the way you think, become your personal assistant and carry out tasks for you. A digital presence that can travel through time, for as long as people and technology keep going. That is the future I am building toward.

The work begins with the material you choose to share. For the Portrait package, we plan ten to twelve hours of interviews and thirty stories for your review. You approve what enters the archive and how your voice and portrait are represented. Your words and decisions form the basis of the twin's answers. Original recordings stay separate from generated responses, so there is a record to check them against.

Why I started with my own portrait

I started with my own portrait. The face on the home page is mine, made of points of light. It gives a visible form to what I want to build: a digital copy with a person's memories, voice and way of thinking.

That choice makes the project personal. I want to preserve my own experience too.

A portrait that looks back

The portrait is not a video. It is a 2.5D relief of my face drawn as thousands of points in WebGL. It gathers when the page opens, blinks, breathes and follows the cursor. The eyes move on their own, and the head turns a little on the neck, the way a person turns toward a voice. A few seconds after the cursor stops, it looks straight ahead again.

On a phone there is no cursor, so the portrait drifts slowly by itself. There is a pause button, and the animation stops when it scrolls out of view, to reduce battery use.

The engine started in Pulsara, my voice assistant, and grew into a desktop portrait for this project. For the web I tuned the point density, warmed the colours and made it light enough to run on a phone.

What the client sees

Three packages, with prices on the site:

Portrait: €15,000, then €290 a month. Interviews, thirty stories, the voice, the portrait of light and a printed book.
Legacy: €30,000, then €490 a month. Twenty-four hours of interviews, sixty stories, access for up to ten people.
Private: from €60,000, then from €990 a month. Installed on the client's own hardware.

The prices are public. A client should know the number before the first call.

A request needs no registration. A private account lets the client follow requests submitted while signed in: received, consultation, proposal, agreement, complete. Messages to me go from the same page. Guest requests stay with me for follow-up by email.

Behind it sits an admin panel in Russian. I see every request there, change its status, keep notes the client never sees, and reply. The reply shows up in the client's account.

How it is built

No framework and no dependencies. A small Node.js server renders both languages on the server, so search engines read the English and the Russian pages in full. I learned that lesson on a robot catalog where Google could read one language out of four.

Passwords are hashed with scrypt, sessions live in HttpOnly cookies, and forms are checked for origin, rate-limited and carry a trap for bots. The site runs on Railway with a persistent volume, at likenesshouse.com. A shared link shows a large preview banner in messengers.

The code was written with AI coding assistants under my direction and review: Codex built the portrait engine, Claude built the site.

What I held to

Every text went through a check for AI clichés. There are no placeholders, no coming-soon blocks and no testimonials, because there are no clients yet to quote. The buttons have sharp corners. The tone is quiet on purpose: we take on a small number of twins each year, and the site says so in one line.

What comes next

The site is open for private consultations. Telegram already notifies me about new requests and registrations. Email delivery through Resend is the next integration; the site currently queues outgoing messages on its persistent storage. Next come the first client interviews.

To see the portrait move, open likenesshouse.com on a computer and move your mouse.

Originally published on ilinmaks.com.

How I built Dantiva and AONETHA: one sentence in, a video out, and the first paying customers

Maksim Ilin — Thu, 08 Oct 2026 19:37:58 +0000

I built Dantiva and launched it. It already has paying customers and a monthly subscriber, and it now also has an international twin, AONETHA, with card payments. This is a short case study about how the product is put together, what the first payments looked like, and how the two versions split the work. The 3D video below was made in Dantiva itself.

The 47 second 3D video made in Dantiva: watch it on my site.

What the product does

You type one sentence and get a video, an image or a text back. That is the whole interface. There is no separate product for each format: the same prompt field handles all three, and the result comes back in the same place where you typed it.

What is inside

Video generation runs on Veo from Google. Images run on Nano Banana. On top of the models sits my own layer: the account, the balance, the entry points and the delivery of results back to the user. Dantiva and AONETHA share this engine.

Two versions, two markets

Dantiva at dantiva.com is the Russian-speaking version. It works on the website, in a Telegram bot and in a Telegram mini app, and one account covers all three, so the balance is the same wherever you open it. Payment is in Telegram Stars and rubles.

AONETHA at aonetha.com is the international version. It is a web product, and payment goes through Stripe in dollars, euros and pounds, by card. The Telegram entry points and ruble payments stay on the Dantiva side; AONETHA keeps the same generation engine without them.

The first payments

The first one-time purchase came in on September 17. Four days later, on September 21, the first monthly subscription arrived. So the service now has its first paying customers and its first subscriber. I am not going to put a number on it, because the number is small and the point is different: the product went from an idea to something a stranger pays for.

How this video was made

The 47 second 3D video at the top of this post was made in Dantiva itself.

Where to look

The international version is at aonetha.com, the Russian-speaking one at dantiva.com. The story of the first customer and the September product update is in the earlier post on this blog, and the case study is in the portfolio on this site. If you want to try it, write to me on LinkedIn and I will add some free generations to your account.

Originally published on ilinmaks.com.

A tiny world with no rewards. What minimir is testing, and why a first null result still counts

Maksim Ilin — Wed, 07 Oct 2026 17:31:06 +0000

I built a small world on a computer to look at one question: where does wanting come from? This is minimir, my artificial life experiment, and this is where it stands after the first measurement.

The 42 second video with the experiment, the two worlds and the first result: watch it on my site.

What lives in the world

The creatures in minimir are very simple. They look for food, burn energy as they move, reproduce and die. Each one is driven by a tiny neural network, and that network passes to the offspring with mutations. Over many generations the population changes on its own, through nothing more than who survives long enough to reproduce.

There is one thing I deliberately left out. I do not give the creatures rewards or goals. Nobody tells them that food is good or that dying is bad. If anything that looks like a drive shows up, it has to come from the setup itself, from selection and from what a creature can sense.

The question

The question is narrow on purpose: does something like a desire appear if a creature can feel itself?

To test that, I run two worlds that start from the same ancestor. In the first world, a creature knows how much energy it has. In the second world, a creature receives the same kind of numbers, in the same place in its inputs, but the numbers belong to a different creature. It is like watching a neighbour's fuel gauge instead of your own. Everything else about the two worlds is identical.

If sensing yourself matters, the two populations should drift apart in how they behave. If it does not, they should look the same.

What the first measurement showed

The first tests have not shown a difference. There is a signal, and it gets lost in the noise. That is the whole result so far, and I am writing it down exactly like that in the observation journal, rather than rounding it up to a finding.

Why a null first result is still a result

A first measurement that shows nothing clear tells me three things. The instrument works end to end, from the two worlds to the comparison. The effect, if it exists, is small enough that the current setup cannot separate it from noise. And the next step is to change what gets measured and how much of it, rather than to tell a better story about the same data.

That is a normal place for an experiment to be after one pass. The temptation in a public project is to publish only when something clicks. I would rather publish the first pass as it is, because the journal is more useful when it shows the misses as well as the hits.

What comes next

The next experiments build on the work of Gregory Bateson, Evald Ilyenkov and Lev Vygotsky. Each of them, in a different way, looked at how a mind grows out of relations with an environment and with others rather than appearing fully formed inside a single head. I am designing the next round of worlds around those ideas.

How the video was made

The 42 second video is pixel art. The clips were animated in Dantiva, my own video service, and the English voice is a clone of my own.

Where to look

The observation journal is open at minimir.ilinmaks.com. The case study is in the portfolio on this site, and the code is on GitHub.

Originally published on ilinmaks.com.

My Lovable site looked finished. Google could read one language out of four

Maksim Ilin — Sat, 03 Oct 2026 23:12:07 +0000

I often say that Lovable is great for the first version of a website. On RoboHub, a robot comparison catalog I built last week, I saw exactly where that first version ends, so here is the breakdown: what Lovable did well, what I had to redo, and how long it took.

What the first version had

Lovable built the catalog in a few hours. Filters by category, payload and runtime, a page for every robot, a comparison table that highlights the best values, a quote form, four languages. Good enough to show a client.

The problems showed up when I asked what a search engine would see. The whole point of the site is search: someone types which robot to buy and lands on a comparison. There were several issues.

The language lived inside the page, not in the address. The switcher changed the text but the URL stayed the same. For Google that is one page in one language. The Russian, German and Chinese versions did not exist for search, even though users could see them.

No sitemap, no structured data. A sitemap tells a search engine which pages exist. Structured data tells it that a page is a product with a price and a maker. Without it, rich results and AI search answers are harder to get into.

The data looked right but was wrong in places. A London startup was listed as Russian. Two robots that are not for sale had prices. Prices in rubles had no source. None of this breaks the site, but for a catalog that wants to be trusted it is worse than any bug.

What I changed

Data first. I built a dataset of 106 models from open sources and added a link and a date to every price. If there is no number, the site says so. Only 51 models turned out to have a public price, and that became content in itself: a buyer should know a warehouse robot cannot be bought in one click, only by quote.

Then I wrote a staged brief for Claude Code and gave it the repository. Lovable and GitHub stay in sync, so Claude Code's changes appeared in the Lovable project right away, and reached the live site only when I pressed Publish. That works as a safety switch: until I check a stage, the live site does not change.

What Claude Code did:

a separate address for each language (/ru, /de, /zh) with hreflang tags
a sitemap with 912 addresses, product and breadcrumb markup
category pages and head-to-head comparison pages
a five-question robot finder
free-license photos from Wikimedia Commons with an authors page

How long it took

One week from idea to the published version. The first Lovable version took a few hours of that. Most of the time went into market research, the dataset and checking each stage.

What to take from this

If you build a Lovable site that has to bring traffic from search, check three things before launch. Does every language have its own address. Is there a sitemap and structured data. Where do the numbers on the pages come from. The first two take a day to fix. The third takes the longest, and nobody will do it for you.

The catalog itself is still unfinished: the quote forms do not send anywhere yet and 88 of the 106 models have no photo. The full story of the project is in the RoboHub case in my work section.

Originally published at ilinmaks.com.

Dantiva got its first paying customer. Then the product changed again

Maksim Ilin — Sat, 03 Oct 2026 23:05:37 +0000

Two days ago I published a technical account of building Dantiva and wrote that paid demand had not been confirmed. That sentence is already out of date.

The first confirmed purchase arrived on 17 September. On 21 September a customer bought the first monthly Start subscription through the Telegram Mini App. These are small transactions, not traction disguised as a chart. But they change the project. Dantiva is no longer only a system that can accept money. Someone chose to pay for it.

That same day the product changed more than it had in the previous week.

From generator screens to one workspace

The first interface was organised around features. There was a screen for generation, another for templates, another for the library. It worked, but each task felt like moving between small tools.

The new interface is organised around the work itself. History and projects sit on the left, the result and prompt are in the centre, and model settings are on the right. Both side panels collapse. The same structure becomes a single-column flow on mobile. A result stays visible while the next prompt is prepared, and generated files still go to the shared library.

The light theme is now the default, with a dark theme available from the same account. This was not a coat of white paint. Contrast, field borders, previews, sticky controls and the mobile generation button all had to survive both themes.

The small prompt box also needed work. Placeholder copy that looked like an ordinary sentence was not enough. It now has a visible label and instruction: enter text and describe what should be created. Model selection also explains what the chosen model is good at, how long it usually takes, and what it costs before the user starts a paid job.

An LLM studio inside the same product

Dantiva started with images and video. It now also has a text workspace powered by Gemini.

The LLM studio has separate chats, search, model selection, a system prompt, project context and server-side history. A conversation can be attached to the same project as its images and videos. At launch it is deliberately narrow: text only, no pretend file analysis, voice mode or local model that is not actually connected.

There are three available Gemini routes. Requests have per-user and global daily limits, and they do not spend the image and video balance during the launch period. A text reply and an eight-second video do not cost the provider anything like the same, so folding them into one counter would only make the pricing harder to explain later.

A second provider, without a second wallet

The larger technical change was adding OpenRouter for image generation and editing. Dantiva now offers two GPT Image 2.5 options:

Flare is the faster default for modern image generation, prompt following and edits where faces or objects should remain recognisable.
Sunburst is the more precise option for difficult details and careful editing, and usually takes longer.

Both cost 300 Dantiva tokens per image at the current medium quality, with one result and up to four references including the source image.

The difficult part was not the API request. It was deciding which money is allowed to pay for it.

Google-backed generations can use the existing product rules, including some grants and issued access. OpenRouter is a direct external cost. GPT Image therefore uses purchased tokens only: an active subscription, a top-up or a one-time paid pack. Welcome tokens, partner bonuses, the old balance, administrative access and issued unlimited access cannot fund it.

There is still one account and one wallet. The server selects eligible paid buckets, reserves 300 tokens atomically, and records the original buckets. A duplicate callback cannot charge twice. If the provider fails, the exact buckets are restored once. An uncertain timeout is not retried automatically, because a hidden second paid request is worse than an explicit failure.

None of this shows up in a model demo, and most of it exists only because the money is real.

The first payment changed the questions

Before the first purchase, the main question was whether the whole path worked: sign in, choose a product, pay in rubles, receive a fiscal receipt, credit the correct wallet and use the balance on the website or in Telegram.

Now the questions are different. What was the customer trying to make? Why did the Mini App feel trustworthy enough to pay in? Do they return? Which model produces something they keep rather than merely test?

I am not publishing customer identity or presenting two payments as product-market fit. The useful fact is narrower: the commercial path has been used by a real customer, including the monthly subscription path in the Mini App.

Building from Croatia, for more than one market

Dantiva began with a practical Russian-speaking use case: access from Telegram, ruble payments and a receipt, without asking the user to solve foreign-card infrastructure first. The underlying product is broader. Its interface already has Russian and English modes, its infrastructure runs on Google Cloud, and its provider layer is no longer tied to one model family.

I have also sent two applications to Croatian innovation initiatives. One went to the BIRD incubator, for Dantiva together with its international build, AONETHA at aonetha.com: the same product aimed at Western markets, where payments are not connected yet. The second is for our other project, evidentio.eu. An application is not an award and I will not write it as one. It is a useful next step: the product now has to be understandable outside the context in which I built it.

That means explaining the actual innovation clearly. It is not that I trained a foundation model. I did not. The value is in the product layer around the models: one workflow across web and Telegram, a shared account and ledger, projects and reusable references, local payments, provider-specific economics, and release discipline when paid jobs can fail.

What the current version proves

Today Dantiva can:

run text, image and video workflows in one project space;
use Google Veo and Gemini alongside GPT Image through OpenRouter;
keep one account, library and balance across the website, bot and Mini App;
charge in rubles through YooKassa and deliver a fiscal receipt;
reserve, capture and refund tokens without charging a duplicate request twice;
keep free access useful while preventing it from silently spending money on a provider that is not grant-funded.

It does not prove repeat retention, a stable acquisition channel or product-market fit. Those are the next tests.

Building the first version told me the system could be assembled. The first customer told me that someone can walk the whole path without me standing behind them: sign in, pay, get the receipt, spend the balance. What I want next is a second purchase that surprises me less than the first one did.

If you are building an AI product with several providers, paid jobs and more than one interface, I would be glad to compare implementation notes. The model call is still the easy part.

Originally published at ilinmaks.com.

The model is the easy part. What building Dantiva taught me

Maksim Ilin — Sat, 19 Sep 2026 18:35:10 +0000

Dantiva turns a photo into a short video. You pick a template, upload a picture, and a few minutes later you get an eight second clip with sound. It runs on Google's models, it lives on a website and inside Telegram, and it is my first product that takes real money from strangers. This is what the build looked like from the inside, including the parts that went wrong.

What it is

Under the hood there are two Google models. Veo 3.1 makes the video, in a Fast and a Lite variant. A Gemini image model makes and edits pictures. A third Gemini model rewrites the user's prompt before it goes to the video model, because most people type three words and expect a movie.

Around those calls is everything that makes it a product rather than a demo: accounts, a balance in tokens, templates, a library of results, projects, a legal center in two languages, an admin panel for support and refunds. That second layer took most of the time. The first Telegram bot, in July, was a single API call to Veo on Cloud Run with all state kept in memory. It worked. It could not be sold.

Why this niche

The audience is Russian speaking people who want a video with themselves in it: a birthday greeting, a trend from their feed, a new avatar. The tools they would normally use are behind a foreign card and a VPN. Paying in rubles, from a Telegram account, with a proper receipt, is the one advantage I can prove today. Everything else about the segment is still a hypothesis, and I try to write it down that way. Paid demand is not confirmed yet. Payments have been live since early September and subscriptions since the 18th, so the next few weeks are the test.

Three front doors

There are three ways in: the website at dantiva.com, a Telegram bot, and a Telegram Mini App that opens inside the bot. They share one account and one token balance.

That last sentence cost me a month. Each surface has its own way of knowing who you are. The site uses Google sign in or email with verification. The bot knows your Telegram ID. The Mini App gets a signed payload from Telegram. All three have to resolve to the same wallet, and a purchase made in one place has to show up in the other two within seconds. Every feature now gets a parity check across all three before release, because the first time I skipped it, the bot had templates the site did not.

I still do not know which door converts best. The bot is where people arrive, the site is where the bigger packs are, and the Mini App sits in between. I will only find out from purchase data, not from opinions.

The ledger is the actual product

Generation costs real money on every call, and a call can fail halfway. So the balance is not a number you subtract from. It is a ledger: reserve tokens when a job starts, capture them when the video arrives, refund them if the provider fails. Every job has an idempotency key, so a double tap on a slow connection does not start two generations. There is one welcome grant per device, a daily ceiling, and a limit on jobs running at the same time, because free tokens on an open internet get farmed within hours.

On September 19 the ledger reminded me why the UI is not allowed to have opinions. Some users have unlimited access: friends, testers, partners. The server checks that list before touching any wallet, and it did so correctly. But the Mini App rendered the launch screen twice. The first pass set the status to unlimited. The second pass overwrote it with the subscription wallet. So a person with unlimited access saw a balance of 25 paid tokens and an offer to buy a plan. Nothing was charged. It still looked like a broken promise. The fix was a priority rule in the interface and two regression tests that render the screen twice on purpose. The server was never the problem, and that is the point: the money logic belongs in one place, and the screens only display it.

The rename I refused to finish

The project has had three names. It started in July as Project Aurora, an internal codename. Then it became Synora. Then Dantiva, which is the name on the domain and in every customer facing string.

Inside the code it is still Synora. The environment variables start with SYNORA_, the device header is X-Synora-Device, the Cloud Run service and the task queue carry the old name. I wrote a rule into the cutover document that forbids renaming them. A rename touches secrets, deployment configuration, the queue, the header every client sends, and the Telegram configuration, all at once, for zero user value. Users never see it. The day I break production for a cosmetic change is the day I deserve to lose the users. So the mismatch stays, and it is documented.

Pricing, three times

The first prices were token packs at 449, 1590 and 3890 rubles. Then 490, 1690 and 3990, after a review of the provider's actual prices. Then, on September 18, subscriptions: Start at 199 rubles for 1400 tokens, Author at 499 for 4200, Pro at 999 for 10080, with smaller top ups from 99 rubles. An eight second Fast video with sound costs 140 tokens, so the cheapest plan is about ten videos a month. Renewal is manual for now, until the automatic payment is approved by the payment provider.

The honest footnote: generation is currently subsidized by a Google Cloud grant. At Google's list price an eight second clip costs roughly 80 rubles to produce. The catalog is normalized to a gross margin of around 30 percent at real provider prices, so the plans are meant to survive the grant. Whether they do is a question for November, when the grant runs out.

Where it is actually stuck

All the templates start from a photo of a person. Google Veo blocks image to video with recognizable people. It is a separate filter, it cannot be switched off, and there is no allowlist for it. I found this out after the template catalog was built.

So the main feature the product was designed around does not work on the main model. Text to video works. Image generation works. Animating your own face does not. I have spent the last week comparing alternatives that accept a photo without a video consent recording: Kling through fal.ai, Runway's Gen-4 Turbo, Seedance through BytePlus. Each has its own price per second, its own payment path, and its own rules about Russian users and Russian cards. None is connected yet. The plan is to run paid video through whichever one passes a small test, keep Google for everything it does well, and charge separate token rates per model inside the same balance.

I could hide this. It would be a bad idea, because the first person who tries the product finds it in two minutes.

What I would do differently

I would test the provider's content policy on the exact use case before building a whole template catalog around it. I would write the ledger first and the screens second, instead of the other way around. I would pick the final name before the first deployment. And I would ship subscriptions earlier: a 199 ruble monthly plan tells you more about demand than three sizes of one time pack.

What is next

A second video provider behind the same token balance. Automatic renewal once the payment provider approves it. A small set of interviews with people who actually paid, so the segment stops being a hypothesis. And a decision by November on whether the economics hold without the grant.

I built most of this with AI coding assistants doing the typing and me doing the deciding, the testing, and the reading of every audit document. If you are building something similar and hit the same walls, write to me. I would like to compare notes.

Originally published at ilinmaks.com.

I'm not an engineer. I fine-tuned my own language model on a MacBook Air

Maksim Ilin — Wed, 16 Sep 2026 04:34:12 +0000

Not long ago I didn't know what the word deploy meant. Now there's a model running on my laptop that I trained myself. Here's how it went, where I got things wrong, and how good-looking numbers almost fooled me.

Why

I have a personal AI assistant called Pulsara. It runs on external models, and at some point I asked myself what happens if those models get shut off, get more expensive, or just get worse. The assistant stops working and there's nothing I can do about it.

So I wanted a model of my own. It lives on my computer, and nobody can switch it off from outside.

The second goal was more interesting. I didn't want the model to know what's inside books. I wanted it to know how to read. Adler and Van Doren's How to Read a Book describes a method: first figure out what kind of text it is and what it says in one sentence, then break down its parts, terms and arguments, and only after that argue with it. Knowing a book means you can retell it. Owning the method means you can work through a text you've never seen. I wanted the second one.

The setup

A MacBook Air M5 with 16 GB of memory. No server, no GPUs.

The biggest thing that fits is Qwen3 with 8 billion parameters in compressed form, 4.4 GB. Anything larger won't fit, because training needs memory too. I didn't retrain the whole model. I trained a small add-on on top of it (the technique is called LoRA). The base model stays frozen and only a set of small extra matrices changes.

My first day wasn't spent training. It was spent getting anything to install at all. My Mac's terminal turned out to be running in compatibility mode for old Intel chips, and the library I needed simply wouldn't install there. Tutorials don't mention things like that.

The data

I put together 576 training examples. About 150 on the method itself, 160 walkthroughs of texts in different genres, 120 on behavior (for example, what to say when asked whether it has read a book), and 110 ordinary conversations with no Adler at all.

That last group mattered. Without it, the model started applying the method to a request for coffee brewing tips.

Four attempts

Version one was cautious, and the result was weak: 13 out of 35 method markers on my test questions. The model recognized Adler's name but analyzed texts its own way.

In version two I changed two settings at once. Training collapsed halfway through, and I never found out which change killed it. Since then I change one thing at a time.

Version three scored 27 out of 35. The method started carrying over to unfamiliar texts. But the model confidently claimed to have read books it had never been shown, and passed judgment on things it hadn't seen.

For version four I didn't touch the settings at all. I only added 74 examples on holding back judgment. It scored 33 out of 35, and the false claims about reading went away. At that stage the data mattered more than the parameters.

Where the numbers lied

33 out of 35 looked like a win. Then I sat down and read the answers myself, on real books the model had never seen: Eric Berne and a recent issue of Harvard Business Review.

It was a different picture. The model summarized the main ideas fairly well, but it added details that weren't in the text. About an experiment in one article, it wrote that half the participants worked with AI and half without. The article said nothing of the kind. It also promised to come back with a report in a week, even though it has no memory between conversations.

My automated check looked for signs of the method in each answer: did it name the type of text, did it state the main idea in one sentence. It could see the form. It never checked whether the content was true.

There were worse traps. The server that serves the model was silently dropping my add-on and answering with the untrained model. No error, no warning, and the answers looked fine at a glance. I only caught it because I compared the server's answers word for word against saved ones. Later I found that the model with the add-on merged into its weights answers differently from the same model with the add-on kept separate. Merging compresses the weights again, and part of the training gets lost.

What I learned

Training a model on a laptop is doable today, and it isn't the hard part. The hard part is finding out what it actually learned.

A metric you keep adjusting starts showing you what you want to see. So now I write the exam questions before the model answers them and keep them separate from the training material.

A small model picks up manner and working order well. It doesn't get smarter: 8 billion parameters after training are still 8 billion.

About me: I wrote the code together with AI assistants. I couldn't write it at that level on my own. My part was deciding what to test, not trusting pleasant numbers, and reading the answers myself.

What's next

The next version is about accuracy: grounding answers in quotes from the text and not adding things that aren't there. After that I'll connect it to Pulsara.

If you're building something of your own with AI without an engineering background, tell me where you got stuck. I'd like to compare notes.

Originally published at ilinmaks.com.

The AI job market in 2026: who gets hired, what they earn, and which roles are fading

Maksim Ilin — Sun, 13 Sep 2026 20:24:44 +0000

In September 2026 I pulled together what the major sources say about the AI labor market: LinkedIn, the World Economic Forum, Stanford AI Index, PwC, Lightcast, Indeed, Bain and Levels.fyi. I needed it for my own decisions, both where to go next and what to offer clients. Here is the short version, with numbers and links.

The one-paragraph summary: AI Engineer is the most hired role, Research Scientist at a frontier lab is the most prestigious, and the fastest-growing niches are agentic systems and Forward Deployed Engineering. Prompt engineer is fading as a job title, entry-level hiring got harder, and half of all AI postings sit outside IT departments.

Demand: the numbers to start from

The share of US job postings that require AI skills reached 2.5% in 2025. That is up 55% in a year and roughly a million postings, according to Lightcast data in the Stanford AI Index 2026. PwC counts differently in its AI Jobs Barometer 2026, looking at postings for AI specialists, and gets 68.9% growth in 2025 against 8.6% for the market as a whole.

The most useful number is also from PwC: the wage premium for AI skills within the same occupation reached 62%. A year earlier it was 56%. Lightcast gets a lower figure with its own method, 28% or about 18,000 dollars a year, but the direction is the same.

Demand is running well ahead of supply. Bain projects that by 2027 the US will have more than 1.3 million AI jobs and about 645,000 people to fill them, so half stay open. Germany looks worse: 190,000 to 219,000 jobs for 62,000 people.

The roles that get hired most

Putting the LinkedIn, WEF and Robert Half rankings next to posting data gives this order.

AI Engineer. Number one on LinkedIn Jobs on the Rise in the US two years running, number one at Robert Half. About 1,550 new US postings a week, median 176,000 dollars. This is the engineer who puts LLMs into products: RAG, agents, fine-tuning, evaluation.
Machine Learning Engineer. The most common AI title in Europe, 64% of all AI engineering postings. WEF expects the number of AI and ML specialists to grow 82% by 2030.
Data Scientist. On the WEF forecast it is the fastest-growing job of all, up 113% by 2030. But postings are up 15% over three years while pay is down 3%. The role is being redefined toward ML and LLM work.
AI Consultant and AI Strategist. Second on LinkedIn two years in a row. People entering the role have a median of eight years of experience, most often from product management.
Research Scientist. From 12th place in 2025 to the top five in 2026. Demand sits in labs and Big Tech.
Agentic AI Engineer. The skill "agentic AI" went from 0.06% to 0.23% of US postings in a year, up 280%, about 90,000 postings.
Forward Deployed Engineer. Postings up more than 1,000% year over year, per Lightcast data in Fortune. This is the engineer who goes to the customer and wires AI into their real processes.

After that come data and infrastructure engineers, AI Product Managers (about 714 new US postings a week), MLOps, AI security, solutions architects, Head of AI and Chief AI Officer, AI governance specialists for the EU AI Act, and at the bottom of the pay scale, annotators and model trainers.

A note on the CAIO. NewVantage and Wavestone report that 38.6% of large companies now have a Chief AI Officer, up from 11% in 2023. A small business cannot afford that seat, which is where fractional AI leadership comes in.

Prestige: who is at the top and what it costs

The top of the market is small. Estimates cited by Fortune and Metix put the number of people who can build frontier models at 500 to 1,000 worldwide, with acceptance rates below 1% at OpenAI, Anthropic and DeepMind.

The money matches. Median Research Scientist pay at Anthropic is around 746,000 dollars a year on Levels.fyi data, OpenAI L5 around 1.15 million, DeepMind L6 between 750,000 and a million. In summer 2025 Meta was poaching researchers with packages of 200 to 250 million dollars over four years, and OpenAI answered with retention bonuses to about a thousand employees.

A PhD is not required, which breaks the usual picture. Per Metix, only 16% of technical staff at OpenAI and Anthropic hold a doctorate. At Meta it is 60%. The two most sought-after labs hire for work, not for the degree.

Where people move is telling too. Zeki data in Fortune puts arrivals to departures in 2025 and 2026 at 22 to 1 for Anthropic, 5.7 to 1 for OpenAI, 3 to 1 for Meta and about 2 to 1 for DeepMind.

The tier below, 300,000 to 800,000 dollars, is senior and staff ML in Big Tech, engineering roles at the labs, and Forward Deployed Engineers at OpenAI and Anthropic. Only then comes the "normal" market: an AI engineer in the US at 146,000 to 189,000, a median of 70,000 euros in Germany, 111,000 francs in Zurich.

Europe: the demand is outside tech

Indeed Hiring Lab data for the first quarter of 2026 puts AI at 4.2% of all postings in Germany, 3.3% in France, 2.7% in the UK, 2.2% in the Netherlands. More than half of those postings, 59% in Germany, are outside technology occupations. In Germany, PwC counts seven "AI user" roles for every "AI developer" role.

Europe also has the widest gap between demand and supply. Interface, using Lightcast and Revelio data, finds roughly one candidate per vacancy at mid level and fewer than half a candidate per vacancy for advanced roles.

What is fading

Prompt engineer as a title dropped out of the list of roles companies plan to hire in Microsoft's 2025 Work Trend Index, after being on it in 2024. In AI Engineer postings the skill "prompt engineering" appears 8.9% of the time, RAG 13.6%. The skill stayed, the job dissolved into other roles.

Entry level got harder. Stanford Digital Economy Lab updated its research on ADP payroll data in August 2026: employment of 22 to 25 year olds in AI-exposed occupations now trails the rest by 19%. A year earlier the gap was 13%. Older workers in the same occupations are growing, so this is a tilt toward seniority, not a shrinking market. Only 3% of ML engineer postings and 2% of AI Product Manager postings are entry level.

What I take from this

Half of AI postings in the US, and 59% in Germany, are outside IT departments. The growth is not in people who build models. It is in people who put AI into marketing, sales, support and paperwork. That is exactly what working with small and mid-size businesses looks like: find the process where AI pays off, build the agent or the integration, and get it to the people who will use it.

Gartner also expects more than 40% of agentic AI projects to be cancelled by the end of 2027. The market pays a premium for agents and buries almost half of them at the same time. The difference between the two halves is usually whether someone looked at the process and the data before the build started.

The full study, with tables by role, skill and region and a section on where the sources disagree, is a separate report. Write to me if you want it.

Originally published at ilinmaks.com.

A RAG chatbot on your company knowledge base: what it is and when it pays off

Maksim Ilin — Sun, 13 Sep 2026 19:46:34 +0000

The request I hear most often this year sounds the same every time: "We want a bot that answers from our documents and does not make things up." The technical name is RAG, retrieval-augmented generation. Below, without jargon: what it is, who it pays off for, what your company needs to bring, and where these projects break.

RAG in plain language

A language model answers from memory. It read the internet up to some date and knows nothing about your returns policy, September price list or warehouse manual. Ask it directly and it will either admit it does not know or confidently invent something.

RAG changes the order. First the system searches your documents for the passages that relate to the question. Then it hands them to the model with the question and asks it to answer only from them, naming the source document. The model still writes the text, but the source of facts becomes your files, not its memory.

To the user it looks like a chat. To the business it is a way to give people hundreds of pages of documentation without making them read those pages.

The citation in every answer is not decoration. It is the main mechanism of trust.

Why RAG is in 13.6% of postings and vector databases in only 4.5%

In a sample of 903 US AI Engineer postings (Glassdoor, April 2026), RAG is required in 13.6% of ads. That is more often than agents (10.6%) and prompt engineering (8.9%). Vector databases, usually called the heart of RAG, appear in only 4.5%.

The gap between those numbers shows where the work actually is. A database for semantic search can be stood up in a day, and there are plenty of ready options. The hard part comes before and after.

Documents. Three versions of the same policy in different folders, scanned PDFs, tables that lose their structure when copied.
Chunking. How to split a document so a rule and its exception do not land in different pieces.
Permissions. Who is allowed to see which documents, and how to carry that into search.
Evaluation. How to tell that the bot answers correctly rather than just confidently.

In my review of the AI job market in 2026 I quoted the KORE1 survey: employers name building evaluation systems as the number one skill, not choosing a database. For RAG that is doubly true.

Who it pays off for

Not every company needs a bot on its documents. It pays off where there is a lot of text and many repeated questions about it.

Support with a big FAQ. Hundreds of articles, agents answering the same questions, first response measured in hours.
Internal policies and manuals. A new hire spends weeks asking colleagues where things are. HR and accounting answer the same questions about leave and expenses.
Sales teams with a catalog. Thousands of SKUs, specifications, compatibility, regional terms. A rep digs through ten files while the customer waits.
Agencies with an archive of proposals. Past pitches, case studies, estimates. A new proposal is assembled from old ones, if they can be found.

The common trait: the answer already exists in the documents, but finding it costs more than asking a person.

Twenty pages of documentation and five questions a day do not need a bot. One FAQ page will do.

What the company needs to bring

I raise this in the first meeting, because it matters more than the choice of model.

Current documents. The bot answers from what it was given. If a policy is out of date, the bot will confidently relay it, with a precise citation.
An owner for updates. A named person responsible for keeping the base current. Without one the system degrades within a quarter.
A list of questions with correct answers. Fifty or a hundred real questions from customers or staff, and what counts as a right answer. Without it nobody can say whether the bot got better or worse after a change.

The third item gets the most resistance and delivers the most value. A couple of days with support logs or email threads is enough to assemble it.

Where these projects break

Four typical failures, each with a defense.

Stale documents. The bot cites last year's price list. Defense: an update owner, and the document date shown in the answer so the user sees how fresh the source is.

Answering outside scope. A customer asks about the legal consequences of terminating a contract, and a bot built on delivery documents tries to answer. Defense: scoped retrieval and a hard rule: if the documents do not contain the answer, say so and hand over to an operator.

Leaking documents. The bot answers a customer with a passage from an internal manual listing cost prices. Defense: permissions enforced at the retrieval level, not in the prompt. The model must never see a document the user may not see.

Hallucinated citations. The model cites a section that does not exist. Defense: citations are generated by the system from the retrieved passages, not written by the model, plus an evaluation set that tracks such cases.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. From what I have seen, document projects die for the same reasons, and almost always nobody built an evaluation set before starting.

A realistic timeline

A pilot on one set of documents takes two weeks. One source (say, the support knowledge base), one scenario (answers for customers or staff), an evaluation set of 50 questions, handoff of hard cases to a person. After two weeks you have a working version to show the team and measure.

Other sources and permissions for several roles come in the second stage. I would not try to cover everything at once: every new source brings its own document quality problems.

How this fits my services

I build this kind of bot under the "AI inside your existing product" service, from 1,200 EUR. That covers RAG, LLM features and integrations into what you already run: a website, a CRM, a support portal, an internal tool. If it is unclear whether the company has suitable documents and a process, start with an AI readiness audit from 450 EUR.

If staff or customers keep asking the same questions about your knowledge base, send me a short brief: what the documents are, who asks, how many questions per week. I will tell you whether it is worth doing and how long it would take.

Originally published at ilinmaks.com.

How much does it cost to implement an AI agent in 2026

Maksim Ilin — Thu, 10 Sep 2026 19:35:34 +0000

"How much does an AI agent cost" is the question I hear more than any other. The honest answer: from about fifteen hundred euros for a narrow process to hundreds of thousands of dollars a year if you hire a team. The difference is not the model. It is what exactly you are buying.

What drives the cost

Five factors I assess in every request, and a sixth that everyone remembers last.

The process the agent takes over. Replying to standard emails and running a full order cycle (find the customer, check stock, issue an invoice, notify the warehouse) differ in effort several times over. More steps and a higher price per mistake mean a higher cost.

Number of integrations. Every system the agent connects to (CRM, accounting, email, warehouse, payments) is a separate connector, separate access rights and separate ways to break. An agent with one integration and an agent with five are different projects.

Data quality. If message history, documents and reference lists are tidy, the work moves fast. If the product catalog exists in three versions in Excel, the first days go into cleaning it up. That has nothing to do with AI, but without it the agent will make mistakes.

Guardrails and evaluation. A test set of real examples, rules about what the agent may not do, thresholds below which it hands the case to a person, a log of actions. In the KORE1 survey for 2026, employers named building an evaluation harness the top skill of an agentic engineer, and it is a visible share of the budget.

Hosting and the model. Beyond one-off development there are monthly costs: calls to the language model API and the server the agent lives on. More on that below.

And the sixth: maintenance. Models get updated, the CRM changes its API, the business gets a new type of request. An agent nobody looks after degrades within a few months.

What the alternatives cost

Market figures as of September 2026.

Freelance. According to Upwork data from May 2026, AI engineers charge 35 to 60 USD per hour, ML engineers 50 to 200. In my experience an agent for one process takes from a few dozen to a couple of hundred hours, so the range is wide. The main risk is not the rate but that you become the project manager: spec, acceptance, quality control.

In-house engineer. The KORE1 survey puts the base salary of an agentic engineer in the US at 155,000 to 210,000 USD for mid level, 210,000 to 290,000 for senior and 290,000 to 360,000 and above for staff. That is 15 to 20% more than a comparable ML engineer, before taxes, bonuses and equity. For a company with one or two processes to automate, that hire will not pay off. In Europe there are fewer than 0.5 candidates per advanced AI vacancy, according to Interface, so the search alone takes months.

AI governance consultant. Day rates of 800 to 2,000 USD, according to an analysis of EU AI Act job postings. Needed if your product falls under the regulator's requirements. This is not legal advice: a lawyer should confirm the obligations for a specific product.

A scoped project. My format: an AI readiness audit from 450 EUR, AI inside an existing product (RAG, LLM features) from 1,200 EUR, an agent for a business process from 1,500 EUR, an MVP from 1,700 EUR. First working version for a narrow process in two weeks. The price grows with integrations and process complexity, but scope and deadline are fixed before the start.

Rates, salaries and why agentic engineers command a premium are covered in my review of the AI job market in 2026.

Timeline

For a narrow process the first working version appears in two weeks. By working version I mean an agent on real data, with an evaluation set, connected to at least one live system, already used by at least one employee.

Then two to four weeks of shakedown: reviewing the cases where the agent got it wrong, extending the test set, tuning thresholds. Then a decision on whether to extend to neighboring processes.

Projects with three or more integrations and messy data take longer. I prefer to say so during the audit rather than in week three.

Monthly running costs

I will not quote numbers here, because they depend on volume and on the model, and provider pricing changes every few months. What matters is the structure:

Model calls are billed by the amount of text in and out. An agent that reads long documents costs more than one that answers short emails. Long instructions in every request cost money too.
Not every task needs the most expensive model. Classification and field extraction often work on cheap models; a strong model is needed on one or two steps.
Hosting for a single-process agent is usually small, comparable to a SaaS subscription. It gets expensive at thousands of requests per hour.
A spending cap is mandatory. An agent stuck in a loop overnight can eat a month's budget.

I include an estimate of expected usage in the audit, because for some processes it is tokens, not development, that decide whether the agent pays off.

What a cheap agent really costs

The temptation is understandable: take a no-code builder, sketch a prompt, connect email and launch in a couple of days. Sometimes it works. More often the demo impresses, then in production the agent answers wrong in some cases, and nobody knows which, because there is no test set. Someone edits the prompt, something else breaks. Two months later the agent is switched off.

Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027. Some of those are large companies with large budgets, but the mechanism is the same: no evaluation, no data, no process owner.

A cancelled project costs more than the money spent on it. It costs the trust of employees who will greet the next agent with a smirk, and the time in which a competitor did the same thing properly.

A budgeting example

A hypothetical company: a sales team of a few people, inbound requests by email and messenger, a CRM. The task: qualify leads and reply within a minute, including evenings and weekends.

AI readiness audit: from 450 EUR, one or two weeks. Output: a process map, an estimate of the effect, a verdict per process, an estimate of monthly model and hosting costs.
Agent for lead qualification with one or two integrations (email and CRM): from 1,500 EUR, first working version in two weeks. A third integration and complex handoff logic raise the amount; I give the exact figure after the audit.
Monthly: model calls and hosting, scaled to the number of requests, plus maintenance by agreement.

The one-off budget for this scenario starts at roughly 2,000 EUR for the audit and the first version of the agent and grows with the number of systems to connect. For comparison: one month of an in-house agentic engineer in the US at the bottom of the KORE1 range is about 13,000 USD in base salary alone.

All three services with prices are listed on the home page.

If you want a price for your own process, send a short brief: which process, which systems are involved, how many requests per day. I will reply with a range and a timeline.

Originally published at ilinmaks.com.