Operator: A look under the hood

We just launched Operator, an Agent for your customer operations that helps you understand, manage, and improve your entire customer experience.

Мы только что запустили Operator — Агента для ваших клиентских операций, который помогает понимать, управлять и улучшать весь клиентский опыт.

To give you an idea of how powerful this Agent is, we’re sharing more about its technical infrastructure and the engineering decisions that went into ensuring Operator works reliably at production scale across thousands of customer workspaces.

Чтобы вы могли оценить, насколько мощный это Агент, мы подробнее расскажем о его технической инфраструктуре и об инженерных решениях, которые позволили Operator надёжно работать в продакшене на тысячах клиентских воркспейсов.

If you’re a technical leader evaluating whether to build something like this yourself, or trying to understand the difference between a well-prompted LLM and a production Agent system, this is for you.

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

Escaping the “it’s just an LLM” trap

Как выбраться из ловушки «это же просто LLM»

Most engineering teams that evaluate this space start the same way: a prototype. Take a foundation model, give it API access to your support data, add a system prompt with some domain context, and you’ve got something that queries your database, summarizes tickets, and generates reports that look right. It demos convincingly.

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

The problem with that prototype is that it obscures the scope of what’s actually required. It demonstrates the 10% of the system that’s straightforward to build, and it’s easy to assume the rest is just as straightforward. It isn’t. The gap between a working demo and a production system your team depends on daily is where most of the engineering investment lives.

Проблема такого прототипа в том, что он скрывает реальный масштаб того, что на самом деле требуется. Он демонстрирует те 10% системы, которые легко построить, и возникает соблазн предположить, что и остальное столь же просто. Это не так. Разрыв между работающим демо и production-системой, на которую ваша команда полагается ежедневно, — это и есть то место, где сосредоточена основная часть инженерных вложений.

With Operator, we’ve invested deeply in every layer: tooling, reasoning, how the Agent takes action, and the infrastructure that makes it reliable at scale. Here’s a closer look.

В Operator мы глубоко вложились в каждый слой: инструментарий, рассуждение, то, как Агент совершает действия, и инфраструктуру, которая делает его надёжным в масштабе. Вот более подробный взгляд.

The tooling layer

Слой инструментария

The first thing we had to confront was that the obvious approach (giving a model access to your APIs and letting it figure things out) doesn’t hold up in production. The model makes reasonable decisions for simple queries, but operating across thousands of customer workspaces with different configurations, data models, and usage patterns, a “figure it out” approach isn’t nearly precise enough.

Первое, с чем нам пришлось столкнуться, — это то, что очевидный подход (дать модели доступ к вашим API и позволить ей самой во всём разобраться) не выдерживает в продакшене. Модель принимает разумные решения для простых запросов, но при работе с тысячами клиентских воркспейсов с разными конфигурациями, моделями данных и паттернами использования подхода «разберись сама» оказывается далеко не достаточно точным.

What you need is purpose-built tooling: tools that encode decisions about what data to fetch, how to structure it, what context to include, and what to leave out. Operator has over 50 of these tools and 10 skills.

Что вам нужно — это специально созданный инструментарий: инструменты, которые кодируют решения о том, какие данные извлекать, как их структурировать, какой контекст включать, а что оставить за рамками. У Operator более 50 таких инструментов и 10 навыков (skills).

A tool is a single action that Operator takes (search content, run a query, look up a conversation). A skill chains multiple tools together to complete a whole job, like debugging a conversation end-to-end, rolling out a content update across an entire help center, and identifying the next automation opportunity.

Инструмент (tool) — это одно действие, которое выполняет Operator (поиск контента, выполнение запроса, просмотр диалога). Навык (skill) связывает несколько инструментов вместе для выполнения целой задачи — например, отладки диалога от начала до конца, развёртывания обновления контента по всему справочному центру или выявления следующей возможности для автоматизации.

The difference between using thin wrappers around API endpoints and purpose-built tooling shows up in something as seemingly simple as a performance question. When you ask “how did Fin perform last week?”, a naive implementation runs a query and hands back a table. Operator runs a reporting tool that determines which metrics are relevant for your specific workspace, which are meaningful for your particular question, and what the numbers actually mean in context, giving you a much richer answer that you can do something tangible with.

Разница между использованием тонких обёрток вокруг API-эндпоинтов и специально созданным инструментарием проявляется в чём-то столь, казалось бы, простом, как вопрос о производительности. Когда вы спрашиваете «как Fin справился на прошлой неделе?», наивная реализация выполняет запрос и возвращает вам таблицу. Operator же запускает инструмент отчётности, который определяет, какие метрики релевантны для вашего конкретного воркспейса, какие из них значимы для вашего конкретного вопроса и что эти числа реально означают в контексте, давая гораздо более содержательный ответ, с которым можно сделать что-то осязаемое.

Developing that behavior took months of engineering. Not because any individual piece is conceptually hard, but because getting it right across the full range of customer workspaces, configurations, and edge cases is an iterative process. You build it, you test it against real conversations, you find the cases where it breaks, you fix those, and you repeat. There’s no shortcut.

Разработка такого поведения заняла месяцы инженерной работы. Не потому, что какая-то отдельная часть концептуально сложна, а потому, что добиться правильной работы по всему диапазону клиентских воркспейсов, конфигураций и пограничных случаев — это итеративный процесс. Вы это строите, тестируете на реальных диалогах, находите случаи, где оно ломается, исправляете их и повторяете. Короткого пути нет.

The intelligence layer

Слой интеллекта

The tooling layer solves what to do, but beneath it is a harder problem: understanding what’s worth doing, and why. This is the layer that makes Operator understand your business rather than just query it. Three components go into it:

Слой инструментария решает, что делать, но под ним лежит более трудная задача: понять, что вообще стоит делать и почему. Это тот слой, который заставляет Operator понимать ваш бизнес, а не просто обращаться к нему с запросами. В него входят три компонента:

1. Semantic search

1. Семантический поиск

Unlike solutions that rely on keyword matching, Operator uses a system that understands what content is about, not just what words it contains. When it searches your help center, it’s using the same semantic search engine we’ve spent years optimizing for Fin itself. This is a retrieval system that’s been tuned against millions of real support conversations, with precision and recall characteristics we’ve measured and improved continuously.

В отличие от решений, полагающихся на совпадение ключевых слов, Operator использует систему, которая понимает, о чём контент, а не только какие слова в нём содержатся. Когда он ищет по вашему справочному центру, он использует тот же движок семантического поиска, который мы годами оптимизировали для самого Fin. Это система извлечения данных, настроенная на миллионах реальных диалогов поддержки, с характеристиками точности (precision) и полноты (recall), которые мы измеряли и непрерывно улучшали.

2. Attribute awareness

2. Осведомлённость об атрибутах

Operator has access to your data and knows what is meaningful for different questions. It knows which metrics are actually in use in your workspace, which custom attributes carry signals, and which fields are populated versus effectively empty. We’ve built specific skills that give Operator this meta-knowledge, so when it’s investigating a performance question, it’s looking at the right things, not hallucinating insights from sparse data.

Operator имеет доступ к вашим данным и знает, что значимо для разных вопросов. Он знает, какие метрики реально используются в вашем воркспейсе, какие пользовательские атрибуты несут сигнал, а какие поля заполнены в отличие от фактически пустых. Мы создали специальные навыки, которые дают Operator это мета-знание, так что, исследуя вопрос о производительности, он смотрит на правильные вещи, а не галлюцинирует выводы из разрежённых данных.

3. Intelligent reasoning

3. Интеллектуальное рассуждение

A well-built Agent can answer your question and anticipate what you should ask next. If you ask Operator about escalations spiking, it doesn’t just say, “escalations increased 23% week-over-week.” It’ll continue on to tell you why this happened by examining the escalated conversations and identifying that a disproportionate number involved a specific product area, before moving on to check whether the relevant help content is up to date, and, if it isn’t, proposing an update.

Хорошо построенный Агент может ответить на ваш вопрос и предугадать, что вам следует спросить дальше. Если вы спросите Operator о всплеске эскалаций, он не просто скажет: «эскалации выросли на 23% неделя к неделе». Он продолжит и расскажет вам, почему это произошло, изучив эскалированные диалоги и выявив, что непропорционально большое их число касалось конкретной продуктовой области, после чего проверит, актуален ли соответствующий справочный контент, и, если нет, предложит обновление.

That chain of reasoning isn’t prompt engineering. It’s encoded in the skills we’ve built, refined against the patterns we see across our entire customer base.

Эта цепочка рассуждений — не промпт-инжиниринг. Она закодирована в навыках, которые мы построили и отточили на паттернах, которые видим по всей нашей клиентской базе.

The action layer

Слой действий

This is where the engineering complexity increases by an order of magnitude because instead of just analyzing problems and recommending solutions, Operator takes action to solve them itself. It can update Guidance rules, draft and publish help articles, create Procedures, configure data connectors, and modify your Fin configuration.

Именно здесь инженерная сложность возрастает на порядок, потому что вместо того чтобы просто анализировать проблемы и рекомендовать решения, Operator сам совершает действия для их решения. Он может обновлять правила Guidance, составлять и публиковать справочные статьи, создавать Procedures, настраивать коннекторы данных и изменять вашу конфигурацию Fin.

Every one of these actions has to be safe, reversible, and auditable. An analytics tool that occasionally returns a wrong number is frustrating. but an Agent that occasionally applies a wrong configuration change to a live support system is a different category of problem.

Каждое из этих действий должно быть безопасным, обратимым и поддающимся аудиту. Аналитический инструмент, который иногда возвращает неверное число, раздражает. Но Агент, который иногда применяет неверное изменение конфигурации к работающей системе поддержки, — это проблема совсем другой категории.

To prevent this, we built a robust proposal system, whereby every change Operator suggests is presented as a reviewable diff. You see exactly what will change before anything is applied, with the option to accept, reject, or refine. Nothing goes live without your explicit approval.

Чтобы это предотвратить, мы построили надёжную систему предложений, в которой каждое изменение, предлагаемое Operator, представлено как проверяемый diff. Вы видите ровно то, что изменится, прежде чем что-либо будет применено, с возможностью принять, отклонить или доработать. Ничто не вступает в силу без вашего явного одобрения.

What else sets Operator apart

Что ещё выделяет Operator

Beyond the technical complexities that power Operator behind the scenes, we’ve also worked hard to build a great user experience.

Помимо технических сложностей, которые приводят Operator в действие за кулисами, мы также упорно работали над тем, чтобы создать отличный пользовательский опыт.

A UI that’s both conversational and graphical, not one or the other

Интерфейс, который одновременно диалоговый и графический, а не что-то одно

Operator blends conversational interaction with purpose-built graphical components:

Operator сочетает диалоговое взаимодействие со специально созданными графическими компонентами:

Diff'ы предложений, показывающие ровно то, что изменится в статье. Встроенные графики, визуализирующие тренды производительности. Дашборды, отрисовываемые прямо внутри ветки диалога.

This means that when a knowledge manager reviews a proposed content update, they see a structured diff, not a wall of LLM-generated text. When a team lead asks about weekly performance, they get a chart with clear axes and context, rather than a paragraph approximating the data in prose.

Это значит, что когда менеджер по знаниям просматривает предложенное обновление контента, он видит структурированный diff, а не стену сгенерированного LLM текста. Когда руководитель команды спрашивает о недельной производительности, он получает график с понятными осями и контекстом, а не абзац, приблизительно описывающий данные прозой.

Building this kind of hybrid UI is extremely difficult outside of a native platform integration. In a chat interface or CLI, you’re limited to text output; in a standalone dashboard, you lose conversational context.

Построить такой гибридный интерфейс крайне трудно без нативной интеграции с платформой. В чат-интерфейсе или CLI вы ограничены текстовым выводом; в отдельном дашборде вы теряете диалоговый контекст.

Operator does both in the same thread, so every interaction is detailed and context-rich.

Operator делает и то, и другое в одной ветке, так что каждое взаимодействие детально и насыщено контекстом.

It lives where your team already works

Он живёт там, где ваша команда уже работает

Operator is built into the same platform your team uses every day. It’s not a separate tool with a separate login, nor is it a Slack bot your engineer set up that only three people know about. It operates exactly where you are, alongside the conversations, help center articles, workflows, and data you’re working with.

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

This helps close the distance between resolving a problem and resolving it: when your knowledge manager spots an outdated article while reviewing a Fin conversation, Operator can surface the fix in the same session. When a team lead notices an escalation spike in the morning, they can ask Operator to investigate without switching tools, waiting for a data pull, or filing a ticket with your engineering team.

Это помогает сократить расстояние между обнаружением проблемы и её решением: когда ваш менеджер по знаниям замечает устаревшую статью при просмотре диалога Fin, Operator может предложить исправление в той же сессии. Когда руководитель команды утром замечает всплеск эскалаций, он может попросить Operator разобраться, не переключая инструменты, не дожидаясь выгрузки данных и не заводя тикет для вашей инженерной команды.

A custom-built tool will always live outside the workflow. An engineer builds it, maintains it, and often, is the only one who knows how to use it. Operator is accessible to anyone who can type a question in plain language, which turns it into a system your whole team runs on.

Кастомный инструмент всегда будет жить вне рабочего процесса. Инженер его строит, поддерживает и зачастую остаётся единственным, кто умеет им пользоваться. Operator доступен любому, кто может задать вопрос обычным языком, что превращает его в систему, на которой работает вся ваша команда.

The compounding advantage

Накопительное преимущество

Every customer using Operator teaches us something. We see which debugging approaches work across different types of support operations, learn which content structures perform better, and can identify automation strategies that consistently land. Those patterns get encoded back into Operator’s skills and tools.

Каждый клиент, использующий Operator, чему-то нас учит. Мы видим, какие подходы к отладке работают в разных типах операций поддержки, узнаём, какие структуры контента показывают себя лучше, и можем выявлять стратегии автоматизации, которые стабильно срабатывают. Эти паттерны кодируются обратно в навыки и инструменты Operator.

When we discover that a particular sequence of investigation steps reliably identifies the root cause of a spike in escalations, we build that into Operator’s diagnostic skill. When we find that a specific way of structuring help articles leads to higher Fin resolution rates, we encode that into the content creation skill. Our engineering team is continuously shipping improvements based on what we observe across the entire customer base.

Когда мы обнаруживаем, что определённая последовательность шагов расследования надёжно выявляет первопричину всплеска эскалаций, мы встраиваем это в диагностический навык Operator. Когда мы находим, что конкретный способ структурирования справочных статей ведёт к более высокому уровню решения проблем Fin'ом, мы кодируем это в навык создания контента. Наша инженерная команда непрерывно выпускает улучшения на основе того, что мы наблюдаем по всей клиентской базе.

A custom-built solution gives you exactly what you built, meaning it doesn’t get smarter unless you invest engineering resources into making it smarter. And that means resources not spent on your core product.

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

We’re not locking the door

Мы не запираем дверь

Some teams want to build their own Agents. Some of our most technical customers do this. But when you do, you’re working with raw APIs and building your own tooling on top of them. When you use Operator, you’re working with a system that already knows what questions to ask, understands your data, and encodes the best practices we’ve learned from thousands of support teams.

Некоторые команды хотят строить собственных Агентов. Некоторые из наших самых технически продвинутых клиентов так и делают. Но когда вы это делаете, вы работаете с сырыми API и строите собственный инструментарий поверх них. Когда вы используете Operator, вы работаете с системой, которая уже знает, какие вопросы задавать, понимает ваши данные и кодирует лучшие практики, которые мы извлекли из работы с тысячами команд поддержки.

We recently launched the Fin CLI, which means you can use third-party agents like Claude Code or Cursor to interact with your Fin data and configuration. That door is open. What we hope this post has clarified is everything that goes into the build of Operator:

Недавно мы запустили Fin CLI, что означает, что вы можете использовать сторонних агентов, таких как Claude Code или Cursor, для взаимодействия с вашими данными и конфигурацией Fin. Эта дверь открыта. Что мы надеемся прояснить этой статьёй — это всё то, что входит в создание Operator:

Более 50 инструментов и 10 навыков, специально созданных для операций поддержки. Годы вложений в семантический поиск. Глубокая интеграция с каждым слоем стека Fin. Система предложений. Слой интеллекта. Инфраструктура надёжности.

If you’d still like to move ahead with building a custom solution, here’s an honest assessment:

Если вы всё же хотите двигаться вперёд и строить кастомное решение, вот честная оценка:

You can build a useful read-only tool in weeks. It’ll query your data, summarize tickets, and generate reports, but turning it into a production system will take quarters. Reliability, security, edge case handling, multi-tenant data isolation, and graceful degradation are all important architectural decisions that you’ll need to get right from the start.

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

The action layer is also where you might risk stalling out. Going from “here’s what’s wrong” to safely making changes in a production system is a fundamentally different engineering problem than analysis. Most DIY projects never get there.

Слой действий — это также то место, где вы рискуете застрять. Перейти от «вот что не так» к безопасному внесению изменений в production-систему — это принципиально иная инженерная задача, чем анализ. Большинство DIY-проектов до этого так и не доходят.

Finally, you’ll be maintaining it forever. Every model upgrade, API change, and new capability in your support platform means updating your custom tooling. We have a team dedicated to this. You’ll need one too.

Наконец, вам придётся поддерживать это вечно. Каждое обновление модели, изменение API и новая возможность вашей платформы поддержки означают необходимость обновлять ваш кастомный инструментарий. У нас есть команда, выделенная для этого. Вам тоже понадобится такая.

Our CTO Darragh Curran wrote an in-depth post about the pros and cons of building vs buying your own AI Agent, which is worth a read. The economics still favor buying when a vendor has invested more in the problem than you can justify internally. What I hope this post adds is a clearer picture of what that investment actually looks like from an engineering perspective.

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

The investment is ongoing. The problems we’re solving at the infrastructure level today are harder than the ones we solved a year ago, and that trajectory isn’t slowing down.

Вложения продолжаются. Проблемы, которые мы решаем на уровне инфраструктуры сегодня, труднее тех, что мы решали год назад, и эта траектория не замедляется.