How to build an AI agent for business: 4 paths and where each one hits its limit

An AI agent is a program that takes a task in plain words and carries it through to a result on its own: it reads data in your systems, calls the tools it needs and changes state — opens a deal, places a reservation, reschedules a visit. What separates it from a chatbot is the right to act, not just to answer.

Below are four real ways to build one, from a no-code builder in an evening to custom development, the honest limits of each, six first steps, and the main thing: what breaks on the way from a pretty demo to real work inside a company. That last stretch is usually skipped in Russian-language overviews, and it is exactly what decides whether a project survives long enough to pay off.

What is an AI agent and how does it differ from a chatbot?

Short version: an agent has tools and changes the state of external systems; a bot talks along a script.

Anthropic's wording draws the line directly:

"Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks" — Anthropic's engineering blog.

In other words, in a workflow the route is set by code in advance, while an agent picks the route itself. OpenAI's definition is more practical: agents are "applications that plan, call tools, hand work off to specialized helpers and hold enough state to complete multi-step work" (the agents guide).

Both definitions contain two words you can use to test any system: tools and state. A widget that answers "what are your opening hours" has neither — that is a chatbot, and there is nothing wrong with it if that is the job. The difference starts costing money when someone sells you one thing under the name of the other. We have a separate piece on bots and their scripts — chatbots for business in Telegram and MAX, MAX being a Russian messenger.

Why build your own agent when off-the-shelf assistants exist?

Short version: an off-the-shelf assistant helps an employee; your own agent works inside your process and with your data.

Demand in Russia is no longer hypothetical. According to research by SberAnalytics and Sber Business Soft published on January 22, 2026 (a November 2025 survey of 559 respondents), automation tools break down like this:

The processes most often automated are document handling and request processing (70%), accounting and financial records (55%), HR processes and strategic planning (34% each), and customer support (30%).

"Automation has stopped being the preserve of large players and capital-city regions" — Anatoly Popov, deputy chairman of the management board at Sberbank, ComNews.

The difference between a subscription to an assistant and your own agent is simple. An assistant sits next to an employee and speeds that person up personally. An agent lives inside the process: it sees stock levels, knows the contract terms for a specific client, writes into your CRM. The first you buy with money; the second is built around your data model.

What are the four paths to building an AI agent?

Short version: a no-code builder, a cloud vendor platform, your own framework and custom development — each has its own ceiling, and the difference between them is exactly that ceiling, not quality.

Reading the table top to bottom is pointless. You start from the task, and Anthropic puts it bluntly:

"Success in the LLM space isn't about building the most sophisticated system. It's about building the right system for your needs" — Building effective agents.

The same text recommends outright not starting with an agent if a plain workflow will do: agentic systems trade latency and cost for better decisions, and it is worth understanding when that trade pays off.

Path 1: a no-code builder

Short version: the best way to find out in a week whether the idea is useful, and the worst way to build a production setup.

A builder gives you ready blocks: connect a messenger, set the model's role, upload a knowledge base, configure a couple of integrations with clicks. A first-line support prototype comes together in an evening, and that is genuinely useful: you get something concrete to talk about instead of a presentation.

The ceiling shows up on three questions, always in the same order:

1. Is your accounting system on the integrations list? 1C, the accounting and ERP platform most Russian companies run on, in its stock configuration, an in-house database, industry-specific software — these are usually missing from ready-made lists.
2. How do you limit what the agent can do? In builders, permissions are usually coarse: either access exists or it doesn't.
3. Where do conversation records physically sit? For personal data this is where the law kicks in — see our piece on AI without data leaks and Federal Law 152-FZ, Russia's personal data protection law.

While the agent answers standard questions using your own public information, none of the three gets in the way. The moment it has to book a client in or see a contract price, you hit all three at once.

At INCUBE AI we usually advise going through this stage quickly — but going through it: a week on a builder is cheap and removes half the questions from the technical spec. If the benefit doesn't add up on paper after the prototype, custom development won't create it either; it will only do the same thing more reliably and at greater cost.

Path 2: a cloud vendor platform

Short version: the middle ground between a builder and your own development — more flexible than clicks, but you inherit the vendor's rules.

The large clouds have assembled agent platforms with the bricks already in place: orchestration, memory, tools, call logging. Managed services take a noticeable share of the infrastructure work off your hands: on August 21, 2026, for instance, AWS made web search in Amazon Bedrock AgentCore generally available — the agent gets live data with citations without leaving the customer's account. Google Cloud consolidated its agent products into a single enterprise platform.

What you get: speed, logging out of the box, scaling without your own operations team.

What you accept along with it:

• Vendor lock-in. Your agent's logic sits on the vendor's primitives; moving means rewriting.
• Cost at volume. It scales linearly with requests and stops being invisible as you grow.
• Data jurisdiction. For a Russian company this is the first question, not the third: where personal data is processed and what the contract says.

Inside Russia this path usually narrows down to domestic clouds and platforms — and the decision comes down to the terms of the contract rather than the platform itself: what matters is whose data you are putting there.

Path 3: your own framework, built by in-house developers

Short version: maximum control, and it needs people who are scarce on the market.

Here the agent is built in code on open libraries: you describe the reasoning loop, the tool set, error handling and tests yourself. No platform limits — any tool, any model, any storage location.

The price of that freedom is skills. The same practitioners' breakdown names things plainly: there are few engineers in Russia who can run language models in production, and you need someone working at the intersection of development, security and model operations. On top of that, everything the platform gave you for free lands on you: observability, retries, spend limits, prompt versioning, regression tests for changes in model behavior.

This path makes sense when you already have your own product team and the agent is part of your product rather than an internal tool. If the team is busy with the core product, the agent becomes its second project — and it usually loses to the first.

Path 4: custom development around the process

Short version: it makes sense when the agent has to live inside your systems and work with your data, not alongside it.

This is the path we work in, so let me be honest about its boundaries. Custom development is not needed if the job is answering standard questions about a price list — that's a builder. It becomes the only option when three conditions come together: the agent writes into production systems; the data has to stay within your perimeter; and the process differs from the standard one enough that no ready-made blocks fit it.

Two of our cases show what that looks like in practice.

At a property developer (case study), the inbound flow consisted of people who wanted to "get a sense of things first", and managers were drowning in initial enquiries. The bot handles the first line — explains, answers, warms people up — and qualified enquiries land in the CRM automatically, where a human takes the deal forward. The metric is simple: the bot closes the first line, managers work only with warm leads.

In a network of service branches (case study), an AI administrator in Telegram and WhatsApp books and reschedules visits around the clock, and a smart schedule rules out double bookings. Here the agent already writes into production systems, and the question of access rights stops being theoretical.

Both systems are agents by the formal test from the first section: they have tools and they change the state of an external system.

Where to start: six steps to your first working agent

Short version: start with the process and the owner, not with the choice of model.

1. Pick one task. Repeatable, with a clear outcome and a measurable volume: "first line of inbound enquiries", "appointment booking", "processing incoming delivery notes". A task of the form "adopt AI" is not a task.
2. Describe how a person does it. Step by step, including exceptions: what they look at, where they write things down, when they call a colleague. This is your future technical spec and, at the same time, the answer to where the agent will need permissions.
3. Assign an owner. A real employee who is accountable for the agent's results and reviews its mistakes. Without this step the project comes back in six months as an incident.
4. Build a prototype in a week. On a builder, without integrations, on exported data. The goal is to check that the benefit adds up, not that the technology works.
5. Define acceptance criteria in advance. What share of enquiries the agent closes on its own, what counts as an error, on what signal it hands over to a human. Without described expected behavior you cannot build tests — and that is one of the standard reasons projects get stuck in the pilot stage.
6. Only now pick one of the four paths. With a prototype, a metric and a list of required integrations, the conversation with a contractor or your own team becomes concrete.

The order matters more than the content. Projects most often fall apart because step six is done first. The choice of model has nothing to do with it.

How do you connect an agent to 1C, a CRM and everything else?

Short version: through an integration layer — and half the work in an agent project goes into it.

An agent needs tools, meaning ways to read and write data where that data lives. This is where a standard comes in that has become the common language over the past two years: MCP (Model Context Protocol), an open protocol from Anthropic introduced in November 2024. It is described as a universal adapter along the lines of USB-C: instead of a bespoke integration for every model–service pair, one shared specification (Anthropic's announcement).

The protocol solves half the problem — how to talk. It does not solve the other half: at the far end you may have a system that gives nothing up on its own. Practitioners describe this plainly: older accounting systems work on a "come and get it" model, they don't push data out, and you need a separate collection and normalization layer. Freshness is a separate headache: if the analytical warehouse updates once a day, the agent will honestly answer based on yesterday's picture.

What it looks like when it's done properly can be seen in our wholesale case: two-way integration with 1C, where product catalog, stock levels, shipments and payments sync by themselves, and an order immediately sees real stock and places a reservation. The agent has something to work with precisely because that layer exists. More on the integration layer itself in our breakdown of how to connect 1C, a CRM, the bank and Telegram into one loop.

What breaks on the way from demo to production?

Short version: a demo tests the idea on clean data; production tests it on dirty data, on access rights and on the monthly bill.

This is the stretch the overviews skip. A practitioners' breakdown on Habr, “An AI agent works fine until you give it access to real data”, lists what surfaces during the move:

• The data turns out to be stale. The warehouse updates on a schedule, and the agent answers based on the previous day.
• Legacy systems don't push data out. You need an integration layer that wasn't in the demo's budget.
• The model starts deciding access questions. A client asks for someone else's information, and the agent either fulfils the request or gets it wrong. Both outcomes are bad.
• Supply chain risk appears. A compromised dependency brings someone else's code inside your perimeter.
• There are no scenarios and no metrics. Without described behavior you cannot build tests or acceptance criteria.
• There aren't enough people. Engineers who run language models in production are scarce in Russia.

And the key number, the reason to read this section before signing off on a budget: in the practice described, the cost of a full product came out roughly 20 times higher than the initial demo — because of routing, scaling and support.

The practical conclusion: treat the demo as reconnaissance, not as version one of the product. A project budget is planned from the list of integrations, the permission requirements and the volume of ongoing support — not from what the prototype cost to assemble.

What permissions should an agent get so you don't end up with an incident?

Short version: the minimum it needs, and the model itself should not be the one deciding about access.

This is a rare case where a security measure has a measured effect. On May 26, 2026, the Russian information security firm Informzashchita published data on incidents involving AI agents:

• 42% of organizations faced security incidents caused by agents in 2026 — against 31% a year earlier;
• 53% had encountered an agent exceeding the permissions it was given;
• 58% say detection and response takes more than five hours;
• among those applying least-privilege access, incidents are recorded in 17% of cases, among everyone else in 76%.

"In 2026 we expect the number of incidents to grow first of all where agents are rolled out faster than owners appear for them" — Anatoly Peskovsky, director of the offensive security department at Informzashchita, CNews.

The gap between 17% and 76% is almost fivefold, and it comes from an organizational measure rather than a software purchase. What follows from that in practice:

1. Permissions are granted for a task, not for an employee. A first-line agent does not need access to the whole customer base — it needs to create an enquiry and read the public price list.
2. The system checks permissions, not the model. The agent requests data; whether it can be released is decided by your access layer.
3. The agent has an owner. A person who reviews the action log and handles disputed cases.

That is exactly what we write into the design stage: access by role, and sensitive data doesn't leave without approval.

How do you tell a real agent from a relabeled product?

Short version: ask about tools, state and permissions — the label falls off on the third question.

The phenomenon has a name. In a press release dated June 25, 2025, Gartner introduced the term agent washing — relabeling existing products as "agents": assistants, RPA and chatbots without real agentic capabilities. Of the thousands of vendors claiming agentic capability, Gartner estimates about 130 actually deliver it.

The same release carries a forecast worth keeping in mind when planning: more than 40% of agentic projects will be canceled by the end of 2027 — because of rising costs, unclear business value and inadequate risk controls.

"Most agentic AI projects right now are early-stage experiments or proof of concepts that are mostly driven by hype and are often misapplied" — Anushree Verma, senior director analyst at Gartner, Gartner press release, June 25, 2025.

Verma adds something there that is worth reading twice before starting any project:

"Many use cases positioned as agentic today don't require agentic implementations" — that is, a large share of the tasks presented as agentic today simply don't need an agent.

A buyer's checklist of three questions worth asking any vendor:

1. Which tools does the system call and what does it change in my systems? If the answer is "it answers questions", it's a bot.
2. How are its permissions limited and who decides about access? If it's "the model will figure it out", that's a future incident.
3. What happens when it gets something wrong? There should be an answer about handover to a human, an action log and an owner.

Three questions cost less than a project canceled a year in. And they are also a good test of your own idea: if you can't answer them yourself, the task isn't described yet — which means it's too early to pick one of the four paths.

Sources

• Anthropic. Building effective agents — definitions of agent and workflow, the advice not to over-complicate
• OpenAI. Agents guide — a definition of an agent through planning, tools and state
• Anthropic. Introducing the Model Context Protocol — the standard for connecting tools, November 2024
• Gartner. Prediction on agentic projects, June 25, 2025 — 40% of projects canceled, agent washing, around 130 genuine vendors
• ComNews. SberAnalytics and Sber Business Soft research, January 22, 2026 — 39% of companies use AI agents, the structure of automation
• CNews. Informzashchita on incidents involving AI agents, May 26, 2026 — 42% incidents, 17% versus 76% under least privilege
• Habr. An AI agent works fine until you give it access to real data — what breaks on the move to production, the "20 times" estimate