Design the right team for your AI Agent projects.

Every article on building an AI customer service team starts with the same move: a list of new job titles. AI Manager, Knowledge Manager, Conversational AI Designer, AI Trainer, AI Agent Owner, Director of ACX. The implicit promise is that if you hire those five people, you’ll have an AI program.

Каждая статья о построении команды AI-поддержки клиентов начинается с одного и того же приёма: список новых должностей. AI Manager, Knowledge Manager, Conversational AI Designer, AI Trainer, AI Agent Owner, Director of ACX. Подразумевается обещание: наймёте этих пятерых — получите AI-программу.

Most of the CX leaders we talk to know that’s not how it works. They have a hiring freeze. They have an org chart they didn’t get to design from scratch. And they have a very specific question: who on my current team is going to do this, and what do they need to learn?

Большинство CX-руководителей, с которыми мы общаемся, знают, что так это не работает. У них заморозка найма. У них оргструктура, которую они не проектировали с нуля. И у них есть очень конкретный вопрос: кто из моей текущей команды этим займётся и чему ему нужно научиться?

This piece answers that. There are four functions every AI agent program needs covered. None of them require a net-new hire if your CX team is already mid-sized. What they require is that you stop thinking in titles and start thinking in functions — and that you take the maintain side as seriously as the build side.

Этот материал отвечает на него. Есть четыре функции, которые должны быть закрыты в любой программе AI-агентов. Ни одна из них не требует нового найма, если ваша CX-команда уже среднего размера. Что требуется — перестать мыслить должностями и начать мыслить функциями, а также относиться к поддержке так же серьёзно, как к построению.

Why role-listicles miss the point

Почему списки должностей бьют мимо цели

If you’ve spent any time on Google researching this, the SERP top 10 will look familiar. Ada lists three operating models and a handful of new roles. IBM names AI Owners and AI Champions. Writer says your next headcount is an AI Agent Owner. Zendesk talks about AI teammates. The HBR piece tells you to onboard them like new hires.

Если вы хоть немного гуглили эту тему, топ-10 выдачи покажется знакомым. Ada перечисляет три операционные модели и горстку новых ролей. IBM называет AI Owners и AI Champions. Writer говорит, что ваш следующий найм — AI Agent Owner. Zendesk рассуждает об AI-тиммейтах. Статья HBR советует онбордить их как новых сотрудников.

They’re not wrong about the work. They’re wrong about the unit of analysis.

Они не ошибаются насчёт работы. Они ошибаются насчёт единицы анализа.

The right unit isn’t a job title. It’s a function — a body of work that has to be owned by someone, named or not. We’ve watched dozens of teams build AI agent programs at Voiceflow, and the shape that consistently works is small. Turo runs theirs in a contained corner of their product. StubHub International launched their MVP only inside the “My Account” section. One of our customers handles tens of thousands of conversations a week with a PM and an engineer. That’s it. Two people.

Правильная единица — это не должность. Это функция — объём работы, у которого должен быть владелец, неважно, как он называется. Мы наблюдали десятки команд, строящих программы AI-агентов на Voiceflow, и форма, которая стабильно работает, — небольшая. Turo ведёт свою программу в ограниченном уголке продукта. StubHub International запустили MVP только внутри раздела «My Account». Один из наших клиентов обрабатывает десятки тысяч разговоров в неделю силами PM и инженера. И всё. Два человека.

Headcount is rarely the constraint. Clarity of ownership is. A function being unowned is what kills programs. A title being vacant rarely is.

Численность редко является ограничением. Ясность владения — да. Программы убивает именно функция без владельца. Вакантная должность — почти никогда.

There are four functions. Here’s what each one looks like, who in your existing org is most likely to own it, and what falls apart when no one does.

Есть четыре функции. Вот как выглядит каждая, кто в вашей текущей структуре скорее всего ею владеет и что разваливается, когда никто не владеет.

Function 1: conversation design (the playbook author)

Функция 1: дизайн диалогов (автор плейбука)

The work is writing the agent’s instructions. Its identity, its goals, the procedures it follows for specific tasks, the tone it strikes when a customer is frustrated.

Работа — писать инструкции агента. Его идентичность, его цели, процедуры, которым он следует для конкретных задач, тон, который он берёт, когда клиент раздражён.

What’s changed since the chatbot era: you’re not writing scripts. Modern agents reason about what to do next based on the situation. So you write playbooks — goal-oriented instructions with room for the agent to adapt — and workflows for the things that have to go right every time. A refund flow is a workflow. A billing dispute conversation is a playbook. The two compose together, and the agent moves between them based on what the customer says.

Что изменилось со времён эпохи чат-ботов: вы пишете не скрипты. Современные агенты рассуждают о том, что делать дальше, исходя из ситуации. Поэтому вы пишете плейбуки — инструкции, ориентированные на цель, с пространством для адаптации, — и workflow для вещей, которые должны срабатывать правильно каждый раз. Возврат денег — это workflow. Разбор спора по биллингу — это плейбук. Они компонуются вместе, и агент переключается между ними в зависимости от того, что говорит клиент.

Voiceflow’s playbook and workflow split is built around exactly this distinction: playbooks for goal-driven reasoning, workflows for deterministic procedures. Other platforms structure it differently, but the underlying split is universal. Whoever owns this function has to understand both modes and pick the right one for each task.

Разделение Voiceflow на плейбуки и workflow построено именно вокруг этого различия: плейбуки для рассуждения, ориентированного на цель, workflow для детерминированных процедур. Другие платформы структурируют это иначе, но базовое разделение универсально. Тот, кто владеет этой функцией, должен понимать оба режима и выбирать правильный для каждой задачи.

In your existing org, this person is almost always your senior CX strategist, your conversation designer if you have one, or your most experienced support manager. The skills overlap is high. They already know how customers ask things, what edge cases bite, where escalation paths matter. What they need to learn is how to write for an LLM: BLUF instead of preamble, specific over abstract, anticipating the messy ways real customers phrase things.

В вашей текущей структуре этот человек — почти всегда ваш senior CX-стратег, ваш conversation designer, если он есть, или ваш самый опытный support manager. Совпадение навыков высокое. Они уже знают, как клиенты задают вопросы, какие пограничные случаи кусаются, где важны пути эскалации. Чему им нужно научиться — это писать для LLM: BLUF вместо преамбулы, конкретика вместо абстракции, предвосхищение того, как реальные клиенты беспорядочно формулируют вопросы.

When this function is unowned, the agent sounds generic. It drifts off-brand. It fumbles edge cases — and no one knows how to fix it because no one owns the prompt. You’ll spot it in the transcripts: every reply reads like the AI’s default voice, not yours.

Когда у этой функции нет владельца, агент звучит обобщённо. Он уходит от голоса бренда. Он спотыкается на пограничных случаях — и никто не знает, как это починить, потому что никто не владеет промптом. Вы заметите это в транскриптах: каждый ответ читается как дефолтный голос ИИ, а не ваш.

Function 2: knowledge ownership (the source-of-truth keeper)

Функция 2: владение знаниями (хранитель источника истины)

The agent only knows what you’ve put in front of it. Pricing, policies, product details, troubleshooting steps, how the warranty works — all of it lives in your knowledge base, and it has to reflect current reality.

Агент знает только то, что вы перед ним положили. Цены, политики, детали продукта, шаги диагностики, как работает гарантия — всё это живёт в вашей базе знаний и должно отражать текущую реальность.

Knowledge isn’t static. Policies change quarterly. Products launch monthly. Pricing updates without warning when someone in finance pushes a memo through. The agent is downstream of all of that, and the only way it stays accurate is if a specific person owns the job of keeping it current.

Знания не статичны. Политики меняются раз в квартал. Продукты запускаются ежемесячно. Цены обновляются без предупреждения, когда кто-то из финансов проталкивает меморандум. Агент находится ниже по течению от всего этого, и единственный способ, чтобы он оставался точным, — это если конкретный человек владеет задачей поддерживать всё в актуальности.

In your existing org, that’s your help center owner, your technical writer, or your knowledge management lead. Sometimes it’s a CX ops person who already triages “the article on X is wrong” tickets. The skill they need to add is writing for retrieval, not for human reading. Long human-friendly walls of text retrieve poorly. Chunk size matters. Headings carry weight. The agent searches for relevant snippets, not the whole document — and that changes how you structure content.

В вашей текущей структуре это владелец help center, ваш технический писатель или ваш лид по управлению знаниями. Иногда это человек из CX ops, который уже разбирает тикеты типа «статья про X неверна». Навык, который им нужно добавить, — писать для извлечения, а не для человеческого чтения. Длинные дружелюбные для людей простыни текста плохо извлекаются. Размер чанка имеет значение. Заголовки несут вес. Агент ищет релевантные фрагменты, а не весь документ — и это меняет то, как вы структурируете контент.

Here’s the honest part: this is the function most often “owned by everyone and therefore no one.” Pin it to a person before launch. Otherwise you’ll get the most painful failure mode in customer service: the agent confidently telling customers something that used to be true. “The return policy is 30 days” — except it changed to 60 last quarter, and now you’re refunding the gap on principle. Trust collapses fast when an AI is fluently wrong.

Скажем честно: это функция, которой чаще всего «владеют все, а значит — никто». Закрепите её за человеком до запуска. Иначе вы получите самый болезненный тип сбоя в обслуживании клиентов: агент уверенно сообщает клиентам то, что когда-то было правдой. «Политика возврата — 30 дней» — за исключением того, что в прошлом квартале её изменили на 60, и теперь вы из принципа возмещаете разницу. Доверие рушится быстро, когда ИИ красноречиво ошибается.

Function 3: operations and observability (the agent manager)

Функция 3: операции и наблюдаемость (менеджер агента)

This is the function most teams skip. It’s also the single most common reason AI agent programs degrade after launch.

Это функция, которую большинство команд пропускают. Это также единственная самая частая причина деградации программ AI-агентов после запуска.

The work is reading transcripts every week. Running structured evaluations against the criteria you defined for what “good” looks like. Tracking the metrics that matter — resolution rate, escalation rate, latency, CSAT — and turning what you see into prompt updates and KB additions and the occasional “we need a new playbook for this.”

Работа — еженедельно читать транскрипты. Запускать структурированные оценки против критериев, которые вы определили как «хорошо». Отслеживать метрики, которые имеют значение — resolution rate, escalation rate, latency, CSAT — и превращать увиденное в обновления промптов, дополнения к базе знаний и периодическое «нам нужен новый плейбук для этого».

Modern agents behave probabilistically. You can’t audit them by reading the script you wrote, because you didn’t write a script. You wrote guidelines. The agent generates its own paths through them, thousands of times a day. The only way to know what’s happening is to watch.

Современные агенты ведут себя вероятностно. Вы не можете аудировать их, читая написанный вами скрипт, потому что вы не писали скрипт. Вы написали инструкции. Агент сам генерирует свои пути через них, тысячи раз в день. Единственный способ узнать, что происходит, — наблюдать.

In your existing org, this is your support ops lead, your QA manager, or a senior support manager who already cares about transcript review. They’re already wired to look at conversations and ask “why did this go sideways?” The new skill is reading agent traces, not just transcripts — understanding why the agent did what it did. Which knowledge source it referenced, which tool it called, where it exercised judgment versus where it followed a fixed procedure. This is what observability and evaluations are for: every conversation captured, every decision traceable, structured evals running automatically against the bar you set.

В вашей текущей структуре это ваш лид support ops, ваш QA manager или senior support manager, который уже неравнодушен к обзору транскриптов. Они уже настроены смотреть на разговоры и спрашивать «почему всё пошло не так?». Новый навык — читать трейсы агента, а не только транскрипты — понимать, почему агент сделал то, что сделал. На какой источник знаний он сослался, какой инструмент вызвал, где он проявил суждение, а где следовал фиксированной процедуре. Для этого и нужны observability и evaluations: каждый разговор зафиксирован, каждое решение прослеживается, структурные evals автоматически запускаются против установленной вами планки.

The Monday morning version: 30 minutes of transcript spot-checking, an eval run on the previous week’s conversations, a list of three prompts to update by Friday. Repeat every week. Forever.

Версия для утра понедельника: 30 минут выборочной проверки транскриптов, прогон eval на разговорах прошлой недели, список из трёх промптов для обновления к пятнице. Повторять каждую неделю. Бесконечно.

When this function is unowned, the agent silently degrades. Knowledge goes stale. Edge cases pile up. Escalations creep up by 2% a month and no one notices until someone in another org complains. By the time customers are loud about it, you’re months behind.

Когда у этой функции нет владельца, агент тихо деградирует. Знания устаревают. Пограничные случаи накапливаются. Эскалации ползут вверх на 2% в месяц, и никто не замечает, пока кто-то из другого подразделения не пожалуется. К моменту, когда клиенты начнут шуметь, вы отстанете на месяцы.

Function 4: engineering and integrations (the plumber)

Функция 4: инженерия и интеграции (сантехник)

The work is connecting the agent to the systems it needs — Salesforce, Zendesk, your order management, your auth provider, whatever ticketing tool you’re standardized on. Then maintaining those connections. Then deploying changes safely through dev, staging, and production without breaking production at 4pm on a Friday.

Работа — подключать агента к системам, которые ему нужны: Salesforce, Zendesk, ваша order management, ваш провайдер аутентификации, какой бы тикетинг-инструмент вы ни стандартизировали. Затем поддерживать эти подключения. Затем безопасно выкатывать изменения через dev, staging и production, не ломая production в 16:00 в пятницу.

Modern agent platforms abstract a lot of the AI-specific engineering. Your engineer doesn’t need to fine-tune a model or stand up a vector database. They need to integrate with the systems your CX team already uses, write the occasional function tool when an integration needs custom logic, and own the deployment pipeline so changes don’t go straight to production untested.

Современные платформы агентов абстрагируют значительную часть AI-специфичной инженерии. Вашему инженеру не нужно файнтюнить модель или поднимать векторную БД. Ему нужно интегрироваться с системами, которые ваша CX-команда уже использует, иногда писать function tool, когда интеграции нужна кастомная логика, и владеть пайплайном деплоя, чтобы изменения не уходили в production без тестирования.

In your existing org, this is a platform engineer, your IT integrations lead, or a backend developer who already owns CX system integrations. They probably already know Zendesk and Salesforce APIs better than anyone. The skill they need to add is the agent platform’s primitives — tools, function steps, environments — which is closer to learning a new SaaS product than to learning machine learning.

В вашей текущей структуре это platform engineer, ваш лид по IT-интеграциям или бэкенд-разработчик, который уже владеет интеграциями CX-систем. Они, вероятно, уже знают API Zendesk и Salesforce лучше всех. Навык, который им нужно добавить, — примитивы платформы агентов (tools, function steps, environments), что ближе к изучению нового SaaS-продукта, чем к изучению machine learning.

Voiceflow’s environments (separate dev, staging, production) exist precisely so this person can ship safely without becoming a release-day bottleneck. You don’t want every prompt change to require an engineer; you want engineers to own the deploy mechanism so the design and ops people can ship their work through it.

Environments в Voiceflow (отдельные dev, staging, production) существуют именно для того, чтобы этот человек мог безопасно выкатывать изменения, не превращаясь в бутылочное горлышко в день релиза. Вам не нужно, чтобы каждое изменение промпта требовало инженера; вам нужно, чтобы инженеры владели механизмом деплоя, а люди из дизайна и ops могли через него выпускать свою работу.

When this function is unowned, integrations break in silence. Deploys go straight to production with no staging check. No one can debug a tool failure when one happens. The agent looks broken to customers; the team can’t tell whether it’s the agent’s reasoning or the CRM that’s down.

Когда у этой функции нет владельца, интеграции ломаются в тишине. Деплои идут прямо в production без проверки на staging. Никто не может отладить сбой инструмента, когда он случается. Агент выглядит сломанным для клиентов; команда не может понять, дело в рассуждении агента или в том, что CRM лежит.

The build/maintain split — and why your second-year team is bigger than your first

Разделение build/maintain — и почему ваша команда во второй год больше, чем в первый

Here’s the part that surprises CXOs most: building takes weeks; maintaining takes forever.

Вот часть, которая больше всего удивляет CXO: построение занимает недели; поддержка — вечность.

A reasonable first-year split is 30% build, 70% maintain. The build share shrinks from there.

Разумное разделение в первый год — 30% построение, 70% поддержка. Доля построения дальше только уменьшается.

Most platform pitches are framed around the build phase — “look how fast you can launch your first agent!” — which is true and also misleading. The work that determines whether the program succeeds happens after launch. More knowledge to curate as the business evolves. More transcripts to review as volume grows. More integrations to maintain as upstream systems change. More evals to keep current as the agent’s scope expands.

Большинство презентаций платформ выстроены вокруг фазы построения — «смотрите, как быстро вы можете запустить своего первого агента!» — что правда и одновременно вводит в заблуждение. Работа, определяющая успех программы, идёт после запуска. Больше знаний нужно курировать по мере эволюции бизнеса. Больше транскриптов проверять по мере роста объёма. Больше интеграций поддерживать, когда меняются upstream-системы. Больше evals держать актуальными по мере расширения области действия агента.

What does not grow as fast: design effort. Once the playbook structure is right, expanding into a new use case is much cheaper than building the first one. Sanlam Studios built and threw away four or five agents before landing on something that worked. That’s not failure — that’s what learning looks like. Once they had the structure, additions came fast.

Что не растёт так же быстро: усилия на дизайн. Как только структура плейбука выстроена, расширение на новый use case куда дешевле, чем построение первого. Sanlam Studios построили и выбросили четыре или пять агентов, прежде чем выйти на что-то рабочее. Это не провал — это то, как выглядит обучение. Когда структура была найдена, дополнения пошли быстро.

By month 18, your ops and observability function is probably 60–70% of the team’s time, even though it was 30% at launch. Plan for that. The CXOs who treat the launch as the finish line end up with a degraded agent and a team that quietly stopped owning it. The ones who treat it as the starting line end up with a capability that compounds.

К 18-му месяцу ваша функция ops и observability, вероятно, занимает 60–70% времени команды, хотя на запуске это было 30%. Планируйте это. CXO, относящиеся к запуску как к финишной черте, заканчивают с деградировавшим агентом и командой, которая тихо перестала им владеть. Те, кто относятся к нему как к стартовой линии, получают возможность, которая работает на сложных процентах.

The smallest team that actually works

Самая маленькая команда, которая реально работает

The smallest viable shape is three people:

Минимально жизнеспособная форма — три человека:

Владелец PM-типа, который покрывает дизайн диалогов и решает, что приоритизировать дальше Человек ops-типа, который ведёт observability и владеет функцией знаний Человек инженерного типа, который владеет интеграциями и пайплайном деплоя

That’s a real team. You can run a meaningful program with it. The customer mentioned earlier — tens of thousands of conversations a week with a PM and an engineer — is the proof that even three is sometimes more than necessary if your scope is contained and the two people are senior.

Это настоящая команда. С ней можно вести осмысленную программу. Упомянутый ранее клиент — десятки тысяч разговоров в неделю силами PM и инженера — доказательство того, что даже трое иногда больше, чем нужно, если область действия ограничена, а два человека опытны.

Mid-size shape, when scope grows or you cross a few use cases: five people. Split conversation design from prioritization (separate CxD). Split knowledge from ops (separate KB owner).

Средний размер, когда область действия растёт или вы переходите через несколько use case: пять человек. Отделите дизайн диалогов от приоритизации (отдельный CxD). Отделите знания от ops (отдельный владелец базы знаний).

Enterprise shape, when you’re running multiple agents across product lines: 8–12 people. Multiple ops owners by domain. A dedicated KB team. Two engineers — one for integrations, one for platform and security.

Enterprise-форма, когда вы запускаете несколько агентов по продуктовым линиям: 8–12 человек. Несколько владельцев ops по доменам. Выделенная команда базы знаний. Два инженера — один по интеграциям, один по платформе и безопасности.

Notice what’s missing from all three shapes: an “AI Manager” with that title, an “AI Agent Owner” with that title, a “Conversational AI Designer” with that title. Those titles can exist if you find them useful, but they’re not what makes the team work. Coverage of the four functions is what makes the team work.

Заметьте, чего нет ни в одной из трёх форм: «AI Manager» с таким названием должности, «AI Agent Owner» с таким названием должности, «Conversational AI Designer» с таким названием должности. Эти должности могут существовать, если вы находите их полезными, но не они делают команду работающей. Работающей её делает покрытие четырёх функций.

Takeaways

Выводы

Перестаньте читать статьи, перечисляющие новые AI-должности. Начните с того, что наложите четыре функции на людей, которых уже нанимаете: дизайн, знания, ops, инженерия. Закрепите функцию 3 — ops и observability — за конкретным человеком до запуска. Это самая часто пропускаемая и самая нагруженная из четырёх. Заложите 30% времени программы на построение и 70% на поддержку в первый год. Ожидайте, что доля поддержки будет только расти. Правильный размер для старта — три человека с ясным владением всеми четырьмя функциями, а не восемь человек с пересекающимися должностями.

Where to go next

Куда двигаться дальше

The team you need is mostly the team you have. But only if you take ownership seriously, and only if you take maintenance as seriously as you take launch.

Команда, которая вам нужна, — это в основном та команда, которая у вас уже есть. Но только если вы серьёзно относитесь к владению и только если вы относитесь к поддержке так же серьёзно, как к запуску.

If your pilot is in flight and you’re trying to get it across the line, our moving an AI CX pilot into production guide covers the 90-day version of this conversation. If you want to see how playbooks, workflows, observability, and environments fit together in practice — the actual product surface the four functions work against — book a Voiceflow walkthrough.

Если ваш пилот в полёте и вы пытаетесь довести его до финиша, наш гайд moving an AI CX pilot into production покрывает 90-дневную версию этого разговора. Если хотите увидеть, как плейбуки, workflow, observability и environments складываются вместе на практике — реальную поверхность продукта, против которой работают четыре функции, — забронируйте обзор Voiceflow.