DEV Community: Maksim Ilin

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.

AI agent or plain automation: where the real ROI is

Maksim Ilin — Thu, 10 Sep 2026 19:07:15 +0000

The market pays more for agents right now than for anything else in applied AI. The skill "agentic AI" grew 280% in US job postings in a year, to roughly 90,000 listings, according to Stanford AI Index 2026. An engineer who builds agents earns 15 to 20% more than a comparable ML engineer, per the KORE1 hiring survey for 2026. And the same market, according to Gartner, will cancel more than 40% of agentic AI projects by the end of 2027.

I don't see a contradiction there. The premium is paid for a rare skill. The cancellations hit projects where an agent was put somewhere it wasn't needed, or where nobody could prove it worked. When someone asks me for an agent, my first question is usually not "which agent" but "do you need an agent at all".

When plain automation wins

There is a whole class of tasks where a language model is simply not needed. The signs:

the input is structured: a form, a spreadsheet, an API, an email that follows a template;
the rules fit on one page and don't change every week;
the answer has to be identical every time, and a mistake is expensive;
the volume is high, but there are few decisions per unit of work.

Moving orders from the CRM into accounting. Payment reminders. Parsing a supplier price list that always comes in the same format. Assembling a weekly report from three sources. All of that is a parser, a rule, or a scenario in any automation platform. It is cheaper, it behaves the same way every time, and it has no token bill.

I would not put an agent on a task you can draw as a flowchart. The agent will be more expensive, slower and less reliable than a plain if-then.

When an agent earns its cost

An agent belongs where the input is messy and there are many small decisions.

Inbound emails to a distributor, where one message contains an order, a complaint and a question about delivery dates. Leads who write in a messenger in free text. First-line support where the questions repeat but the wording is new every time. Invoices, contracts and requests that arrive as PDFs, photos and scans.

What these have in common: the rules are too many and too fuzzy to write down. A person handles it through judgment. An agent reproduces that judgment well enough to take most of the routine off the person and leave them only the ambiguous cases.

The second sign is a chain of actions. The agent doesn't just classify an email. It finds the order in the database, checks stock, drafts a reply and creates a task for the manager. Each step on its own is trivial. The value is in linking them.

How to measure ROI

I use four numbers, and I insist they get measured before launch, not after.

Hours. How much time staff spend on the process today. Not a guess of "about half a day", but a one-week measurement. Multiply by the fully loaded hourly cost.
Response time. How long a customer or a colleague waits. In sales this is conversion, directly: a lead who got a reply in a minute and a lead who waited until morning behave differently.
Error rate. Orders typed in with a mistake, invoices sent to the wrong place, requests that got lost. Errors have a price, and usually nobody has counted it.
Revenue being lost right now. Leads nobody answered. Requests that arrived after 6 pm. Repeat sales nobody got around to.

If the sum of those four lines is smaller than implementation plus a year of maintenance, the project should not happen. That is a normal outcome of an audit, and I say so to clients.

Evaluation first, agent second

In the KORE1 survey, employers named the top skill of an agentic engineer as neither prompts nor frameworks but the ability to build an evaluation harness: a set of test cases the agent is checked against automatically after every change.

So before the agent is written, you need real examples from the process with the correct answers, ideally at least a hundred. Emails and the way your best manager replied to them. Documents and what should have been extracted from each. The agent runs against this set every time the instructions, the model or an integration changes.

Without it you don't know whether the agent got better or worse after an edit. You find out from customers. The projects Gartner counts in the cancelled 40% are very often exactly this: the demo worked, production drifted, and nobody could say why.

Data matters more than the model here. If there are no examples because nobody ever recorded the process, the first days go into collecting them. Boring work, and it decides the result.

Guardrails and handoff to a person

An agent in production has to do three things: never do what it isn't allowed to do, stop when it is unsure, and hand the case to a person in a way that lets the person understand the context in ten seconds.

In practice this is a list of allowed actions (reading an order is fine, changing a price is not), confidence thresholds below which the agent opens a task for an operator instead of answering, and a log of every action. Plus a spending cap, because an agent stuck in a loop can burn a month of tokens overnight. That one is not a scare story.

The operator doesn't disappear. They stop doing the routine and start handling exceptions. Usually it is the same person who did it by hand before, and in the first weeks they are the one who spots where the agent is wrong. That is the most useful feedback in the whole project.

Three steps to decide

Audit the process. One or two weeks: where the input comes from, who does what with it, where time and money leak, whether there is data for evaluation. The output is a list of processes with an estimated effect and a verdict for each: rule, agent, or leave it alone.
Pilot one process. Two weeks, a first working version on real data, with an evaluation set and guardrails. Not five processes at once. One.
Measure. The same four numbers as before the start. If they hold, extend to neighboring processes. If not, stop, and the loss is limited to the pilot.

This order is how my services are built: an AI readiness audit from 450 EUR, an agent for one specific process from 1,500 EUR, first working version in two weeks. Why the market pays a premium for agentic engineers, and what that means if you are the one buying, is in my review of the AI job market in 2026.

If you have a process that eats hours and you are not sure an agent belongs there, send me a short description: what comes in, who handles it, how long it takes. I will reply with what I would do in your place.

Originally published at ilinmaks.com.