Definition · ChatOps · 2026

ChatOps in 2026: what it is, and what changed

ChatOps is operating software from team chat. The original idea was bots that notify. The modern shape is agents that act. Both versions are covered here.

The term is a decade old; the shape has flipped twice since. This page covers the definition, the history, what changed with LLMs, the five components of a modern ChatOps setup, six concrete recipes, the tool landscape across three eras, and how to adopt it without a platform rewrite.

Definition: what ChatOps means

ChatOps is the practice of operating software and running business processes from a team chat surface, so the work itself (the command, its output, the follow-up) is visible to the whole team and recorded in the same place the team is already talking. The chat room is both the interface to the tools and the audit log of who did what.

Three traits separate ChatOps from "we also have a Slack channel for that":

• Operations happen in chat, not in another tool. The deploy, the database query, the customer lookup, the pipeline move: triggered from the channel, output posted to the channel.
• Work is collaborative by default. A teammate can see the command and the result, can comment, can take over, can rerun. Nothing important lives in one person's terminal scrollback.
• The trail is auditable. Every action carries who triggered it, what tool ran, and what came back. The channel is the log.

A team that announces deploys in chat but runs them on a laptop is doing announcements, not ChatOps. A team that runs the deploy from the channel, with output posted inline and the next person able to redeploy from the same thread, is doing ChatOps.

A brief history: 2013-2018, the Hubot era

GitHub coined the term in 2013. Hubot, their open-source chat bot, was already running deploys and fetching logs from Campfire, then HipChat, then Slack. The shape was simple: ask the bot in the channel instead of pinging the ops team.

The pattern spread fast. By 2015 most engineering-led companies had a bot in Slack running some subset of: deploys, on-call rotation, postmortems, infrastructure queries, JIRA shortcuts, new-hire onboarding. Lita (Ruby) and Errbot (Python) gave teams alternatives to Hubot's CoffeeScript. Slack's slash commands and incoming webhooks turned every tool vendor into a Slack-integration vendor.

Then it stalled. Three reasons people give:

• Bots couldn't reason. Every command was a regex. If you asked the bot something it didn't have a regex for, you got the help text. New workflows meant new code.
• Every integration was bespoke. The Hubot Stripe plugin and the Hubot HubSpot plugin shared nothing. Maintenance was a full-time job at a serious team. Most companies retired their bot when the owner left.
• Slash commands were brittle. Argument order mattered. Typos failed silently. The bot couldn't ask a follow-up question.

By 2020, "we should set up ChatOps" had moved from "yes, let's" to "maybe later". The term stuck around in DevOps blogs without a clear answer to what the next version looked like.

2026: from notifying bots to acting agents

The next version turned out to be agents. Large language models closed the regex gap; the Model Context Protocol (MCP) standardized the integration story; Claude Code and similar agent runtimes gave teams a real participant to put in the channel, not a notifier.

The shape of modern ChatOps:

• A user asks something in plain language ("redeploy staging", "pull this customer's last three invoices", "who owns the auth flake").
• An agent in the channel reads the request, picks a tool from a shared registry, runs it, and posts the result inline.
• The team can follow up, redirect, or take over. The thread is the audit log.

The bot pattern is dead in the sense that no one is writing new Hubot plugins. The chat surface itself, channels and threads and DMs, is more important than ever; it's just that the thing in the channel is now an agent.

What the agent needs from the team

The agent picks the tool; the team curates the choices. Three things have to be in place for that to work:

• A real tool registry. MCP servers and CLIs the agent can actually reach, with credentials it's allowed to use. A registry of three good tools beats one of thirty half-wired ones.
• Permission and recovery. Some commands need a human in the loop; the agent should know when to pause and ask. When a call fails, it should try a different tool, not a generic error string.
• Visibility. The team has to see what ran and why. If the only thing posted to the channel is the conclusion, the agent has become a black box and nobody can take over.

Five components of modern ChatOps

Five pieces. Miss one and the setup falls back to bots-and-webhooks, or stops being auditable.

1. A chat surface that supports real conversation. Channels, threads, DMs, search, mentions, mobile. The team already lives here for the social side of work; the operational side has to land in the same place, or no one will look.
2. A shared tool registry. MCP servers and CLIs that any agent or human in the workspace can reach. Wire up Stripe once, and the agent in #support can run it, the agent in #finance can run it, and a teammate can run it from the shell. Per-bot registries are the old shape.
3. An agent runtime. Claude Code or a peer. The runtime decides which tool to call, with which arguments, and how to handle the response. The runtime, not a regex, is what makes ChatOps recover from a request it hasn't seen before.
4. A visible trail. Every action lands somewhere the team can see, with who triggered it and what came back. Best when the trail lives in the channel itself, so reading the thread tells you what happened.
5. A permission model. Not every command should run for everyone. The workspace needs to gate sensitive tools (production deploys, billing changes, data exports) by role, with a clear approval path when someone needs more.

Six ChatOps recipes that work

Concrete, generic shapes that any team can build. The point is the pattern, not the brand of tool.

1. Deploy from chat. A teammate asks the agent to ship the current main branch to staging. The agent runs the deploy CLI, streams logs into the thread, and posts the final URL and version. Anyone else in the channel can redeploy or roll back from the same thread.
2. On-call triage. An alert fires into an incident channel. The on-call asks the agent for the last hour of error-rate metrics, the recent deploys, and the owner of the failing service. The agent pulls from three tools, posts a summary, and links the runbook.
3. Sales pipeline summary. Every Monday, the sales lead asks the agent in #revenue for the pipeline changes from the past week, broken down by stage. The agent runs the CRM query, formats the answer, and posts it inline. No exported spreadsheet.
4. Support handoff. A customer email lands in a shared channel. The agent fetches the customer's recent orders, recent tickets, and account tier, then drafts a reply for the support lead to edit and send. The full context lives in the thread.
5. Ticket triage. A new bug report arrives. The agent reads it, searches the existing tracker for duplicates, suggests a label and a priority, and tags the likely owner. The owner approves or redirects in one reply.
6. Long migration coordination. A multi-week migration runs out of a dedicated channel. Each step is a thread; each thread shows the command, the output, the review, and the sign-off. Six months later, the channel is the entire history of how the work got done.

ChatOps tools: legacy, platform-native, agent-native

Three eras of tools, with very different trade-offs.

Legacy bot frameworks

Hubot, Lita, Errbot. Open-source frameworks for writing chat bots, popular from 2013 to roughly 2020. You write commands as code (CoffeeScript, Ruby, Python), wire them to the chat platform's API, and host the bot somewhere. Mostly retired today; the repos are quiet, the plugin ecosystems have rotted, and no one wants to be the team that runs a Hubot in 2026. Worth knowing about because the vocabulary and the patterns came from here.

Platform-native bots

Slack apps, Microsoft Teams bots, Discord bots. The chat platform itself is the bot host: webhook in, webhook out, slash commands and event subscriptions. Convenient because every vendor ships one, and the platforms have spent years polishing the developer experience. The cost is lock-in: a Slack app is a Slack app, a Teams bot is a Teams bot, and each one carries its own per-app tool registry. There's no shared "the workspace knows how to talk to Stripe" layer.

Agent-native team chat

Ano. The chat product is built around an agent runtime, not bolted onto one. A collaborative shell sits alongside every channel with that channel's context attached. The tool registry is shared across the workspace. Coworkers (named agents with their own tools) sit in the channel member list, not in a sidebar. The audit trail is the channel itself.

Bot-era vs agent-era ChatOps

How to adopt ChatOps without a rewrite

The mistake teams make is picking a platform before they pick a workflow. The result is a polished bot that no one uses because no one had a real problem the bot was solving. Reverse the order:

1. Pick one workflow that hurts. Not "deploys" in general. A specific friction: "I want to run the weekly revenue report without exporting CSVs", or "I want on-call to triage in one place".
2. Name the chat surface. Which channel? Who else needs to see it? If the answer is "no one", ChatOps is the wrong shape; what you want is a script.
3. Name the tool that does the work. Which CLI, which MCP server, which API. If the tool doesn't exist yet, build the tool first. Don't build the chat surface around a tool that isn't real.
4. Run it manually in that channel five times. A human, the tool, the channel. No automation yet. This is where you learn the actual shape, the actual handoffs, and the actual edge cases.
5. Then automate. Hand the rough edges to the agent. Promote the common cases to a saved prompt. Keep the manual path open for everything else.

Where Ano fits

Ano is team chat built for the agent-era version of ChatOps. Channels, threads, DMs, search, and mobile (the chat shape your team already knows), with a Claude Code agent available in every channel, a shared MCP and CLI registry across the workspace, and a collaborative shell that sits alongside every channel with that channel's context. The agent is a participant in the chat, the tools are shared across the workspace, and the trail is the channel itself. It isn't a Hubot replacement; the bot layer was the wrong layer. This is the next category step. Read more on the Claude Code team chat page.

Want to see what agent-era ChatOps looks like in practice? Download Ano free, read about Claude Code in team chat, or browse real setups on the examples page.