> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Modules & workflows

> A module is an operational outcome you own; the workflows inside it are the automation that delivers it.

Modules are how the Komodor Agentic Operation Platform (KAOP) ships operational work you can turn
on rather than build. This page explains what a module is, what a workflow is, how the two nest,
and how to enable a module for your workspace — read it before the individual module pages, because
every one of them assumes this model.

## The one distinction that matters

**A module is an outcome you own. A workflow is a sequence of steps inside it. A module contains
workflows.**

|          | Module                                | Workflow                                            |
| -------- | ------------------------------------- | --------------------------------------------------- |
| Answers  | *What am I accountable for?*          | *How does that get done?*                           |
| Example  | Incident management & troubleshooting | "Production Alert Investigation"                    |
| Scope    | A domain — incidents, cost, drift     | One configured path through that domain             |
| You      | Enable it for a workspace             | Operate it, and read what it produces               |
| Contains | One or more workflows                 | Steps, each delivering a task to one or more agents |

So "Incident management & troubleshooting" is not a workflow, and "Production Alert Investigation" is not a module. The module
is the domain; the workflow is the automation. When you open a module you see its workflows; when
you open a workflow you see its steps.

```mermaid theme={null}
flowchart TD
  M[Module — Incident management & troubleshooting] --> W1[Workflow — Production Alert Investigation]
  W1 --> S1[1 · Source]
  W1 --> S2[2 · Dedupe & correlate]
  W1 --> S3[3 · Investigation]
  W1 --> S4[4 · Remediation]
  S3 --> A1[Datadog Investigator]
  S3 --> A2[Kubernetes Investigator]
  S3 --> A3[AWS Investigator]
```

## What a workflow is made of

A workflow is an ordered set of **steps**, and each step delivers a task to one or more **agents**.
A step names the work; the agents bound to it do the work. Because binding is explicit, you can see
exactly which agent handles which stage — and a step with nothing bound still carries its task, it
just has no agent to execute it.

That structure is what lets a module coordinate specialists: one step correlates the incoming
signal, the next fans out to domain investigators, the next proposes a remediation and asks a human
to approve it.

## The three families

Every module belongs to one family, which tells you the kind of outcome it owns.

<CardGroup cols={2}>
  <Card title="AI SRE" href="/modules-and-workflows/sre/incidents">
    Keep production healthy — incident response, alert intelligence, and proactive reliability.
  </Card>

  <Card title="Cost Optimization" href="/modules-and-workflows/cost-optimization/k8s-cost">
    Spend less across Kubernetes, cloud infrastructure, and observability.
  </Card>

  <Card title="AI Software Operations" href="/modules-and-workflows/ops-automation/change-intelligence">
    Control change risk, production readiness, and CI/CD health.
  </Card>
</CardGroup>

## Enabling a module

Modules are enabled per workspace. **Modules → Overview** lists the modules configured for yours,
across the three families above. Each entry shows its family, what it owns, and how many
workflows it contains.

<Steps>
  <Step title="Open Modules → Overview">
    Find the module under **Configured**.
  </Step>

  <Step title="Open the module">
    Configured modules appear in your sidebar with their workflows ready to operate.
  </Step>

  <Step title="Connect what it needs">
    A module reads and writes through integrations. Its page lists what to connect before its
    workflows can do useful work.
  </Step>
</Steps>

<Note>
  Disabling a configured module moves it to **Available** and removes it from the sidebar. Enable it
  again from the catalog when you want to operate its workflows.
</Note>

## What a module produces

An enabled module gives you a place to work: a list of the records it has produced — incidents,
findings, drifts, verdicts — each carrying the evidence behind it, the runs that generated it, and
any decision it needs from a human. That record list is the module's home in the sidebar.

## Next steps

<CardGroup cols={2}>
  <Card title="Orchestration" href="/manage-your-agents/run/orchestration">
    How steps, agent binding, and orchestrators work under the hood.
  </Card>

  <Card title="Concepts & glossary" href="/get-started/concepts">
    The full vocabulary, in one place.
  </Card>

  <Card title="Incident management & troubleshooting" href="/modules-and-workflows/sre/incidents">
    The module most teams start with.
  </Card>

  <Card title="Approvals" href="/security-and-governance/controls/approvals">
    How a workflow asks a human before it acts.
  </Card>
</CardGroup>


## Related topics

- [Concepts & glossary](/get-started/concepts.md)
- [Orchestration](/manage-your-agents/run/orchestration.md)
- [How Run works](/manage-your-agents/run/how-it-works.md)
- [Agent catalog](/manage-your-agents/build/catalog/overview.md)
- [Use specialized agents](/manage-your-agents/build/use-specialized-agents.md)