Open any avionics bay and you will find the same design philosophy: separate Line-Replaceable Units, each with one job, connected by standard buses, so a faulty unit can be swapped without rewiring the aircraft. Software operations arrived at the same philosophy for running work through team chat, and the pattern has a name — ChatOps, an operating style in which routine work moves into a team channel: software assistants announce events, carry out a curated set of commands, and leave the whole exchange on the record. What most introductions skip is the internal anatomy: how a message typed at 02:00 becomes a verified, authorised, logged action on a server. This explainer follows the signal through the whole path, in the spirit of the ChatOps reference entry at the Ops Atlas, because the architecture — not the bot personality — is what makes the practice trustworthy.
Three Surfaces, One ChatOps Channel
Before the plumbing, the visible layer. A mature channel carries three distinct kinds of traffic, and teams that conflate them end up with noise:
- Notifications are machine-to-human announcements: a build finished, a certificate expired, a threshold tripped.
- Commands are human-to-machine requests, typed as short invocations from an approved list.
- Conversation is everything the humans say around those events — the questions, the decisions, the context that makes the record valuable months later.
Evidence from teams that measure their channels suggests the mix matters more than the volume: a feed where most messages demand nothing is background radiation, while one where every second message demands action turns the channel into a task queue nobody reads. Knowing which surface a message belongs to is step one of reading any ChatOps diagram. The distinction also drives design choices downstream: notifications can be grouped and throttled, commands must be allow-listed and audited, and conversation should be left alone — automated summaries are fine, but nobody wants a bot interleaving alerts into a human argument.
The Adapter: Translation, Never Decision-Making
The adapter is the part facing the chat platform. Its job is translation only — converting an incoming message or webhook payload into a normalised internal request, and formatting replies for the channel. Deliberately, it holds no authority. It cannot decide who may do what; it cannot carry business logic. This separation exists because chat platforms are the least stable layer of the entire stack: Slack’s first-generation custom bots reached end of support in March 2025; Microsoft has scheduled the classic Office 365 Connectors for removal this May; Opsgenie exits in the spring of 2027. Teams whose “brain” lived in a platform-specific integration had to rebuild from scratch each time. An adapter that can be thrown away and replaced keeps the expensive parts — rules, permissions, records — intact across migrations.
The Gateway: Where Trust Is Established or Refused
Every request next reaches the gateway, and this is where the evidence-led part begins. The gateway runs a fixed sequence, and skipping a step is how incidents start:
- Verify origin. Prove the request actually came from the platform. A Slack request must present an HMAC-SHA256 signature computed over its payload; timestamps older than five minutes get treated as replays, and the sender expects an acknowledgement inside three seconds. Teams signs its calls as JWTs. Mattermost takes a simpler route with a static token — one that names the sender but leaves the payload unsigned, so whoever obtains it can shape the body freely unless compensating checks exist.
- Map identity. Attach the request to the sender’s immutable platform ID. Display names are cosmetic and changeable; a permission system that reads them is trusting a nickname.
- Authorise. Check the mapped identity against the policy for the requested action, including which channel the request arrived in — channels are matched by ID, never by name, for the same reason.
- Route approvals. Anything high-impact pauses until a second, different human approves. Break-glass overrides exist for emergencies, and they log loudly.
- Emit an audit record. Whatever happens next, the decision itself is written to a store outside the chat platform.
Notice how much of this happens before any real work is done. That is the point: the gateway is a checkpoint, not a pass-through, and a ChatOps setup without one is just a shell with a chat skin. Every refusal the gateway issues is also data — sampled weekly, refusals reveal misconfigured clients, probing users, or commands so confusing that people keep asking for the wrong thing.
The Executor: Small, Scoped, Replaceable
Executors do the actual work — query the scheduler, restart the service, file the ticket. Good practice keeps each one narrow: a single executor with a single purpose and the least authority that job requires. The pattern shows its range in published cases. Public-sector teams run strictly read-only bots that nudge developers about stale pull requests or missing security scans — actionless by design, useful because they surface facts in the flow of work. Incident response bots pair terse commands for paging an on-call engineer with status lookups, and they are built to fail loudly: when the paging backend is unreachable, the bot says so in the channel and tries a fallback rather than going quiet. Deployment systems accept a trigger command but hold the actual state — locks, guards, canary progress — in purpose-built machinery outside the chat. The anti-pattern here is the classic “wrapper” that takes whatever text a user types and pipes it into a shell. That design turns the channel into a command line for anyone who can type, which is precisely what the allow-list exists to prevent. The confused-deputy trap also lives at this layer: when a bot runs everything under one shared identity, the system cannot distinguish which human asked for an action after the fact. StackStorm’s default execution user, chatops_bot, is a frequently cited example of how easily this default creeps into production.
Where ChatOps Records Go When They Matter
Chat history is a transcript, and transcripts are poor evidence. Messages can be edited or deleted, threads branch, retention policies prune, and none of it is designed to satisfy an auditor. The architecture therefore treats the audit store as a first-class component: append-only, queryable, outside the chat platform, receiving every command, identity, decision, approval and outcome. Teams working toward formal controls will recognise the shape — immutable identity mapping and dual authorisation align with access-control expectations such as NIST AC-3(2), while structured, tamper-evident records echo the intent of AU-3 audit schemas. The same store powers operational review: weekly refusal sampling shows whether the guardrails are tuned or merely installed, and quarterly scope checks catch the slow growth of the command catalogue.
Reading the Diagram as Evidence
Why insist on this anatomy rather than a single clever bot? Because each separation produces testable claims. You can point at the adapter and ask what platform churn would cost (one swap, nothing else). You can point at the gateway and ask how a forged request dies (at step one, with a log entry). You can point at an executor and ask what its blast radius is (one job, scoped). A setup that cannot answer those questions on a whiteboard will not answer them better during an outage. The same systems-thinking pays off across adjacent domains — readers weighing broader tooling choices will find a strategic manual for application selection useful, and the gateway’s evidence-first attitude pairs well with intelligent IT operations practice.
Scaling Without Losing the Shape
Growth stresses the architecture in predictable places. Command counts creep upward; the catalogue needs an owner per entry. Notification volume drifts; grouping and routing rules need tuning, not abandonment. Teams multiply; the identity map and channel taxonomy do the quiet work of keeping permissions legible. Through all of it, the three-part shape holds — which is exactly what you want from a design, and the quiet reason teams that adopt this anatomy early spend their later years improving policy instead of rewiring integrations. If your interests run toward the platform layer beneath all this, scalable cloud infrastructure strategy covers the ground the executors stand on. And if you take one sentence from this explainer, take the layout: translation at the edge, decisions in the middle, action at the tips, evidence everywhere.
