We do not build agents for the sake of agents: how an LLM fits into a task, not into a chat

When people discuss AI in a product, the conversation usually collapses into two familiar images.

The first is a chatbot: a window where a person types and the system responds.
The second is an autonomous agent: a system given a goal that then appears to “go and do everything on its own.”

Both images are useful, but there is a third option between them, and it is much more practical. That is exactly where we place our bet in real products.

The idea is simple: we do not build AI as a separate character that must be persuaded through chat. We embed an LLM into specific process points where it is genuinely stronger than traditional software.

In other words, not “ask AI to do marketing,” but:

• help collect semantic clusters;
• group keyword phrases by intent;
• prepare a personalized opening for an email;
• extract business meaning from a company website;
• propose ad copy variants under strict platform constraints.

Everywhere else, standard deterministic mechanisms continue to operate: rules, limits, APIs, queues, validation, monitoring, access control, and manual approval where needed.

That is why this approach often creates more value in business than either a regular chat or a “magical agent that does everything by itself.”

Why chat is not the best interface for work

Chat is useful when a task is vague: think through ideas, sketch options, quickly clarify something, or get help with text and analysis.

But once real operational work starts, chat limitations show up quickly.

First, people have to bring context into the dialogue again and again: what the project is, which niche it serves, what constraints exist, what data can be used, and which output format is required.
Second, quality depends heavily on how well the user can formulate prompts.
Third, the result often remains “just a conversation” that still must be turned into action manually.

So chat is usually too far from the actual process.

It can suggest.
It can produce a draft.
It can explain things.

But it is rarely an effective execution form for repeatable work tasks.

An autonomous agent sounds powerful, but it is not always what you need

The opposite extreme is the fully autonomous agent idea. You set a goal, and it picks steps, tools, and decisions on its own.

For exploratory and open-ended tasks, this can be useful. But in applied business operations, difficult questions appear quickly:

• where does the agent get permission to act;
• where are its responsibility boundaries;
• how do you cap the cost of mistakes;
• how do you guarantee output format;
• how do you explain to the team what it did and why.

If you give the agent too much freedom, you get a beautiful demo with weak controllability.
If you constrain it too hard, it starts to look like a regular script, only more expensive and less predictable.

That is why in most applied scenarios, it is more useful to build not “an agent that can do everything,” but a system where the LLM solves a strictly defined fragment of work.

The third path: an LLM as an embedded layer inside the process

This is our actual working approach.

Do not create one more digital interlocutor.
Do not build an autonomous entity just because the word agent is trendy.
Instead, decompose the process and answer honestly: where do we need a language model here, and where are classic code and rules better?

The pattern usually looks like this:

1. Data and events arrive from real sources: CRM, ad platforms, websites, company databases, analytics, and task queues.
2. The LLM is enabled only where meaning, text, intent, context, or unstructured content must be understood.
3. A deterministic layer validates format, enforces limits and access rights, applies compliance rules, calls APIs, writes to storage, and launches background tasks.
4. A human joins where approval, quality control, or managerial judgment is required.

In this contour, an LLM is not “the brain of the whole product.” It is a very strong specialized module.

And paradoxically, that is where its real strength appears.

Example 1: Sending Machine is not a sales chat, but a precise outreach engine (personalized B2B contact)

From the outside, someone might say: “So this is just AI for email.” Inside, the logic is much more interesting.

In Sending Machine, AI is not sitting in a corner of the interface waiting for a user prompt like “Write me a good email.”
It is embedded into a sequence of concrete steps.

First, the system collects companies, finds websites and contacts, and extracts page content.
Then the LLM analyzes this material: it helps classify the company, identify the niche, describe the audience, pain points, and value proposition.
After that, another AI step personalizes the message for a specific company or contact type.

But then the most important part happens: the critical operational pieces are not done by the LLM.

• email validity is checked;
• sending limits are enforced;
• domain warm-up is managed;
• a legal footer is created automatically;
• unsubscribe and compliance rules are applied;
• delivery runs through background jobs and a controlled SMTP flow.

So the LLM here is responsible not for “sending the campaign,” but for what it does better than humans and worse than rigid rules: understanding how a company operates and adapting the message to its context.

This is a very important distinction.

If we did the same through chat, the user would have to:

• copy website fragments manually;
• explain whom they are writing to;
• ask for an ice-breaker draft;
• move text into the campaign by hand;
• track limits, unsubscribes, and domain reputation separately.

Here, AI is embedded exactly where it creates uplift, while the risky and regulated contour stays under system control.

The result is not “a copywriting chat,” but a working B2B outreach tool where AI improves communication quality without breaking operational discipline.

Example 2: Ads Machine is not an agent marketer, but a system where AI works in narrow roles

Advertising has the same pattern. Many people imagine an “AI marketer” as a universal helper: give it a product and it will invent audiences, keywords, ads, budgets, and strategy by itself.

It sounds attractive, but in real advertising this is dangerous.

In Ads Machine, we split the task into layers.

There are places where the LLM is genuinely useful:

• propose an initial set of search hypotheses from the offer;
• detect meaning-level formulations that humans may miss;
• segment keywords by intent: hot, warm, informational, brand;
• generate ad copy under specific Yandex or Telegram constraints;
• explain research outputs and convert them into clear conclusions.

And there are places where algorithms and integrations work better:

• frequency checks via Wordstat;
• collecting suggestions from real search demand;
• loading keywords into ad groups;
• budget control;
• rule-based bidding;
• anomaly detection;
• applying changes through ad system APIs.

This means the LLM does not receive the instruction “run advertising.”
It receives narrower but very useful tasks:

• understand offer semantics;
• propose hypotheses;
• turn those hypotheses into a structured list;
• help with copy where character limits and platform constraints apply.

Then the system validates output against real data and real interfaces.

For example, AI can generate interesting keyword candidates, but the fate of those keywords is decided not by model inspiration, but by actual frequency and the subsequent campaign structure.
AI can propose ad texts, but the system verifies format and platform constraints, then uses a proper advertising contour.

So you get not a “marketing agent,” but an engineering advertising machine where the LLM is embedded as a semantic layer, not as a free budget operator.

How this differs from a chatbot in practice

The difference is not philosophical. It is highly practical.

A chatbot usually works like this:

• the user brings context manually;
• the user formulates the task manually;
• the user decides what to do with the answer manually;
• quality depends on prompt-writing skill.

With an embedded LLM layer, it is different:

• context comes automatically from the system;
• the task is already defined by the product;
• the response format is constrained in advance;
• the output immediately flows into the next process step.

Put simply, people interact not with a “general smart brain,” but with a product that already knows what work must be done.

This dramatically lowers the entry barrier. The user does not have to be a prompt engineer. They do not need to re-explain the business from scratch every time. They do not need to remember how to ask the model “the right way.”

They just use the tool.

Why this is often better for both business and team reality

This approach has several practical advantages.

First, predictability.
When an LLM is embedded into a narrow step, input, output, and result quality are easier to control.

Second, lower error cost.
If the model groups keywords imperfectly or proposes a weak intro variant, it is a local error. It is not the same as an autonomous agent changing budgets on its own, sending to the wrong recipient, or executing the wrong action sequence.

Third, impact is easier to measure.
You can separately track:

• whether open rate and reply rate improved;
• whether semantic collection became faster;
• whether ad hypothesis quality increased;
• how much manual routine was removed from the team.

In chat mode these effects are usually blurred.
In an embedded process they are tied to concrete operations.

Fourth, it scales inside the organization.
A good chat flow often works only for one strong specialist who knows how to “talk to AI.”
A well-embedded AI process works for the whole team, because knowledge is already built into product logic, interface, and step sequence.

When chat is still needed

It is important not to swing to the opposite extreme: chat is not useless.

It is valuable for exploration, learning, discussion, and rapid experiments.
Chat is strong when the task is not yet shaped: when you need to think, unpack an idea, compare options, and ask questions.

But once a scenario is clear and repeatable, the next step is logical: move the successful pattern from chat into the product process.

First, a person does it manually with the model.
Then the team recognizes that the step repeats.
Then that step is embedded into the system with proper context, rules, validation, and metrics.

That is the moment when AI stops being a toy and becomes part of the operational contour.

How this changes product thinking

If you view AI this way, the core question changes.

Not “where should we attach a chat.”
And not “how do we build an autonomous agent that replaces everyone.”

Instead:

• where in the process people spend too much time on semantic routine;
• where data already exists but is too textual or too noisy for ordinary rules;
• where you need reproducible output rather than free-form dialogue;
• where the model can have a narrow role while control remains with the system.

This sounds less impressive in a headline.

But this is usually where real value appears.

Not as a “magic agent,” but as a set of precisely embedded intelligent functions that remove unnecessary work, improve decision quality, and do not require re-negotiating with a machine through chat every day.

Conclusion

The most useful AI form in a product is not necessarily a chatbot and not necessarily an autonomous agent.

Very often, it is an embedded LLM layer inside a specific task:

• in outreach, to understand a company and personalize messaging;
• in advertising, to work with meaning, hypotheses, semantics, and creative assets;
• in analytics, to transform raw data into clear conclusions;
• in any operational process, to strengthen the exact segment where language and meaning matter more than rigid logic.

This approach is less noisy than what the market usually prefers to showcase.
But it fits business reality much better.

Because in real work, people usually do not need “an AI you can talk to.”
They need a tool that reliably executes a useful part of work inside an existing process.