Skip to main content
A channel connects the Komodor Agentic Operation Platform (KAOP) to a place your team already talks — today, Slack. Once it is connected, routing rules decide what an inbound message starts, and the work shows up either in-thread or in KAOP depending on what was started. This page covers connecting a workspace, writing routing rules, and exactly what each kind of target does.

Connecting Slack

Channels live under Integrations → Channels. Add channel walks you through installing the KAOP Slack app — there are no tokens to paste and no manual app setup.
1

Approve the app in Slack

KAOP opens Slack so you can install it into your workspace.
2

Click Connect in the DM

Slack sends you a direct message with a Connect button.
3

The channel appears in KAOP

The dialog picks the connection up automatically, and the channel is ready to route messages.
One channel represents one Slack workspace connection. You can rename it, pause it, resume it, or delete it from its page. revoked is distinct from paused on purpose: one is your decision, the other is Slack’s. KAOP verifies its Slack credentials with a live check and reacts to Slack’s own revocation events, so a dead connection surfaces as revoked rather than failing quietly.

Routing rules

A channel’s Routing rules decide what an inbound message starts. Rules are evaluated in priority order, top of the list first, and the first match wins — one message starts exactly one thing. A rule can route to an agent, a workflow, or an incident pipeline. All three appear in the rule list, labelled by kind.

Rule types

Four kinds, matching the form’s own options: Channel, keyword, and mention rules are scoped by Slack channel ID in the rule form. A keyword rule with no channel scope matches workspace-wide. Two toggles are worth knowing:
  • Allow bot posts. Posts from other apps — a Datadog or PagerDuty alert, a deploy notification — are ignored unless a rule explicitly opts in. That opt-in is how you route machine-generated alerts to an investigation agent.
  • Default route. One rule can be marked the default: it catches messages that match no other rule, so the bot always has an answer path. An incident-pipeline route cannot be the default.
You can reorder rules with the arrows on each row, enable or disable one individually, edit it, or delete it.

Rules you cannot edit here

Two kinds of rule appear in the list read-only, each with a chip saying where it comes from: For these rows the reorder arrows, the enable toggle, and delete are all disabled — editing them here would be undone by whichever system owns them.
A route to an incident pipeline is not created here. It comes from that incident pipeline’s own Slack triggers, so the rule form offers Agent and Workflow as targets only. Incident-pipeline routes show up in the list because they are real routes on this channel, and they are read-only because the incident pipeline owns them.

Precedence in practice

Agent-spec rules and rules you create in the console are ordered against each other in one list, and a console-created rule usually lands near the top. Rather than reasoning about it, read the real precedence off the channel page: the Routing rules list is sorted by priority, and whatever is nearest the top wins. To change it, use the reorder arrows. Because the first match wins, two agents that both listen in the same Slack channel do not both get the message — the higher rule wins, and the overlap is ambiguous by construction. If two agents must both respond, give them distinct channels or model the fan-out inside one workflow rather than in the routing table.

Who the agent is acting for

The first time someone messages the bot, KAOP prompts them in Slack to connect their Slack identity to their KAOP user with a quick sign-in link. Once linked, runs started from their messages are attributed to them rather than to the bot, which is what keeps the audit trail honest. Until a sender links, their messages get a connect prompt instead of a run. Two exceptions, both deliberate: a bot post cannot link an identity, so bot-triggered runs act under the agent’s own principal; and a message routed to an incident pipeline creates an incident regardless, because a human mentioning an outage should not be blocked on their account linkage.

What happens when a message matches

1

KAOP reacts to the message

A reaction is added so the sender knows it was picked up. This happens for every kind of target.
2

The target is invoked with the message as input

Any preset input on the rule is merged in. An agent target becomes a run recorded with channel slack. A workflow target starts a workflow, whose agent steps are their own runs. An incident-pipeline target opens an incident and runs its orchestrator.
3

An agent target replies in-thread, live

A threaded reply is posted immediately and updated as the agent streams its progress, so the thread shows the work happening. The final reply renders the run’s human-readable output.

Only an agent target replies in-thread

This is the single most important behavioural difference between the three target kinds: Evidence is recorded for every target kind. The run, or the workflow’s step runs, or the incident’s orchestrator and specialist runs, all land in KAOP with their full evidence trail — so the operational record is complete even where Slack shows only a reaction. That is the point worth internalising: silence in the thread is not silence in the platform. If an agent run fails, the threaded reply says so and links to the run so you can read the full evidence rather than guessing from a one-line error.

Messages that match nothing

A message that explicitly addresses the bot — a mention or a DM — and matches no rule gets one in-thread reply saying so, rather than silence. It is best-effort and stays quiet in the cases where a reply would be wrong: a bot post that named the bot does not draw a public answer, and a paused, errored, or revoked channel does not post at all.

Who answered, and who really answered

Routing decides which agent receives a message. The two diverge as soon as that agent delegates, which is normal for a general-purpose assistant that hands off to a specialist. Every channel reply therefore carries a one-line attribution footer naming the agent that answered and, when it delegated, the agent that handed off — with each run linked. The footer is added by KAOP’s reply path, not written by the agent. A footer the agent authored would be exactly as trustworthy as the paraphrase it exists to make checkable. If you want one run and one bill instead of two, write a rule that routes straight to the specialist.

Next steps

Runs & evidence

Messages from a channel produce ordinary runs — here is what they record.

Orchestration

What a workflow target actually does once it starts.

Incident management & troubleshooting

Incident pipelines, and the Slack triggers that own their channel routes.

Roles & permissions

Who can connect a channel and manage its routing.