{"id":32056,"date":"2026-05-15T02:30:37","date_gmt":"2026-05-15T01:30:37","guid":{"rendered":"https:\/\/www.intercom.com\/blog\/?p=32056"},"modified":"2026-05-15T02:36:02","modified_gmt":"2026-05-15T01:36:02","slug":"operator-a-look-under-the-hood","status":"publish","type":"post","link":"https:\/\/www.intercom.com\/blog\/operator-a-look-under-the-hood\/","title":{"rendered":"Operator: A look under the hood"},"content":{"rendered":"

We just launched Operator<\/a>, an Agent for your customer operations that helps you understand, manage, and improve your entire customer experience.<\/p>\n

To give you an idea of how powerful this Agent is, we\u2019re 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.<\/p>\n

If you\u2019re 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.<\/p>\n

Escaping the \u201cit\u2019s just an LLM\u201d trap<\/h2>\n

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.<\/p>\n

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

With Operator, we\u2019ve invested deeply in every layer: tooling, reasoning, how the Agent takes action, and the infrastructure that makes it reliable at scale. Here\u2019s a closer look.<\/p>\n

The tooling layer<\/h2>\n

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 \u201cfigure it out\u201d approach isn’t nearly precise enough.<\/p>\n

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.<\/p>\n

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.<\/p>\n

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 \u201chow did Fin perform last week?\u201d, 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.<\/p>\n

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\u2019s no shortcut.<\/p>\n

The intelligence layer<\/h2>\n

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:<\/p>\n

1. Semantic search<\/h3>\n

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\u2019s using the same semantic search engine we\u2019ve spent years optimizing for Fin itself. This is a retrieval system that\u2019s been tuned against millions of real support conversations, with precision and recall characteristics we\u2019ve measured and improved continuously.<\/p>\n

2. Attribute awareness<\/h3>\n

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\u2019ve built specific skills that give Operator this meta-knowledge, so when it\u2019s investigating a performance question, it\u2019s looking at the right things, not hallucinating insights from sparse data.<\/p>\n

3. Intelligent reasoning<\/h3>\n

A well-built Agent can answer your question and anticipate what you should ask next. If you ask Operator about escalations spiking, it doesn\u2019t just say, \u201cescalations increased 23% week-over-week.\u201d It\u2019ll continue on to tell you why<\/em> 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\u2019t, proposing an update.<\/p>\n

That chain of reasoning isn\u2019t prompt engineering. It\u2019s encoded in the skills we\u2019ve built, refined against the patterns we see across our entire customer base.<\/p>\n

The action layer<\/h2>\n

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.<\/p>\n

\n