AI-Patch Manager · Linux patch operations · New module

Linux patch management with typed, approval-gated agents

AI-Patch Manager plans and runs the Linux patch cycle: inventory, errata ranking, dry runs, scheduling and ring-based rollout. Execution goes through the patch tools you already run, such as Satellite, Ansible or SUSE Manager. Every agent starts advise-only, and steps that touch production need an approval.

Package lists come from the approved patch set, never from model output
Each ring opens only after the previous ring passes its gate
No execution outside an approved change window

Book a discovery session See the agents

Deploys in your VPC or on-prem
Starts in advise-only mode

Run · November cycle · payments · canary ring

Cycle opened: November errata for paymentsExample

Cycle run, step by step Gated per ring

1Reconcile inventory across CMDB, discovery and the patch toolHosts in scopeCMDB gaps flaggedRuns
2Rank errata by severity, CISA KEV, EPSS and exposureKEV-listed CVEs firstRuns
3Freeze the patch set and request approvalApprover namedAsk me first
4Dry run on each server before the windowChanged librarieslive-patch eligiblereboot readinessRuns
5Raise the change and schedule waves inside the approved windowCAB approvalHA pairs split across wavesAsk me first

Rings, in order · gate: success rate, health, soak time

Canary · a few servers per app
Non-prod
Pre-prod · after soak
Prod

Invariants

Controls that apply on every cycle.

Change windowNo execution outside an approved window or without an approved change record
Ring orderProd starts only after non-prod passes its health gate
Pinned packagesPackage lists come from the approved patch set, never from model output

Problem

Where manual patch cycles break

Common in estates with thousands of servers and a few weekend windows.

Manual cycle

Spreadsheets, tickets and scripts

Windows don’t add up: thousands of servers, a few weekend windows
Non-prod and prod drift: servers pulling from vendor repos get different patches weeks apart
Every server has rules: database weekday limits, HA pairs, freeze calendars
Impact unknown upfront: what changes, whether it can go live, whether a live-patched server comes back at its next reboot

Results arrive late

Failures surface after the window closes
Audit evidence is put together by hand

With AI-Patch Manager

Each item maps to the agent that does it

One reconciled inventory from the CMDB and discovery Inventory Reconciler
A ranked, frozen patch set, submitted for approval Patch Curator
Changed libraries, live-patch eligibility and reboot readiness known before the window Patch Impact Analyst
Waves sized to the window, HA peers split, change raised for CAB Scheduler
Every ring installs the same pinned snapshot, so prod gets what non-prod tested Repo StewardVerifier

Architecture

Seven task-scoped agents, one Persona Bee

Each agent has a fixed set of typed actions and no general-purpose shell. Each is approved once, like a runbook, then runs the same way every cycle.

Pipeline

Patch inventory
Frozen patch sets
Impact checks before patching
Window-aware scheduling
Ring-by-ring rollout, non-prod before prod

Plan

Inventory Reconciler
CMDBDiscovery
- Builds the patch inventory from the CMDB and discovery
- CMDB write-back asks first
Patch Curator
ErrataScanner findings
- Ranks errata by severity, CISA KEV, EPSS and exposure
- Drafts a frozen patch set for a person to approve
Patch Impact Analyst
Before each window
- Dry runs and changed-library checks
- Live-patch eligibility and reboot readiness
- Gives a verdict, changes nothing

Stage and schedule

Repo Steward
Approved patch set
- Publishes the approved set as a repo snapshot
- Promotes it ring by ring
Scheduler
Window calendarITSM
- Fits waves into windows by capacity, role rules and HA pairs
- Raises the change request for CAB approval

Roll out and verify

Patch Executor
Approved wave
- Runs through your existing patch tools
- Pre-checks, live patching where safe, rolling reboots
Verifier and Failure Triage
After each wave
- Compares service health before and after
- Gates the next ring
- Retries or rolls back by policy, and opens an incident

AI-Patch Manager

Persona Bee that owns the cycle

Runs the monthly cycle and chases approvals
Reports the share of servers on the current patch set; tracks exceptions with expiry dates
Builds the audit evidence pack
Starts an emergency cycle, under the same approvals and gates, when a CISA KEV-listed CVE affects servers in scope

AI-SRE

Handles patch-caused incidents

Takes over patch-related incidents
Correlates the failed run with logs, metrics and recent changes, and writes the root-cause note

Explore AI-SRE →

Gates

Starts advise-only. Autonomy is raised per agent, per environment.

Approvals go through Slack, Teams or your ITSM tool. Every action is logged against the change record.

Runs

Read-only and advisory

Reading the CMDB, errata and scanner findings
Dry runs and impact verdicts
Drafting patch sets and change requests

Ask me first

Steps that touch production

Records: CMDB write-back
Patch set: freezing and publishing it
Change: submitting it to CAB
Rollout: running each wave, ring by ring

Never

Hard limits

Commands outside the approved patch set
Both HA peers in one wave
A general-purpose shell

Waves pause on failureAnd page on-call when failures pass your threshold
Blast-radius limitsPer window and per application
Every action logged against the changeAudit evidence builds as the cycle runs

Extensibility

Uses your existing tooling. Configured per environment.

Each connector starts read-only. Write access is granted per tool when you are ready.

Policy

Window rules
CAB flow
Freeze calendars
Rings
Gate thresholds

Custom steps

Existing pre-check and restart scripts attach as steps
They run under the same approvals

Custom agents

New task-scoped agents for your own workflows
Same typed actions and gates as the built-in ones

Approval channels

Slack and Microsoft Teams
ServiceNow, BMC Remedy or Jira Service Management

Designed to work with the tools you already run

Linux patching

Red Hat Satellite
Ansible / AWX
SUSE Manager
Canonical Landscape
SSH relay

Cloud VMs

AWS Systems Manager
Azure Update Manager
GCP VM Manager

CMDB

ServiceNow
BMC Helix
Jira Service Management
Device42
CSV or Excel

ITSM and change

ServiceNow
BMC Remedy
Jira Service Management

Repos

Satellite
SUSE channels
Pulp
aptly
Artifactory

Vulnerability

Qualys
Tenable
Rapid7
Wiz
Microsoft Defender for Endpoint

Advisories

Red Hat errata
SUSE errata
Ubuntu USNs
NVD
CISA KEV
FIRST EPSS

Windows and endpoint tools (SCCM, Intune, WSUS, Tanium, BigFix, Ivanti, Automox) come in a later phase.

AI-Patch Manager FAQ

Frequently asked questions

For the platform team evaluating it and the CAB approving it.

Book a discovery session

What is AI-Patch Manager?

AI-Patch Manager is NudgeBee's Persona Bee for Linux patch operations. It runs the patch cycle through seven Task Bees: the patch inventory, frozen patch sets, impact checks before patching, window-aware scheduling and ring-by-ring rollout, non-prod before prod. Your existing tools do the work, and your teams approve each step that touches production.

Does it replace Satellite, Ansible or ServiceNow?

No. Red Hat Satellite, Ansible, SUSE Manager, ServiceNow and your other tools keep doing the work. AI-Patch Manager plans the cycle, checks impact, raises the change and runs approved waves through those tools.

Can it run commands on my servers on its own?

No. It starts advise-only, and autonomy is raised one agent and one environment at a time. Package commands come from the approved patch set, not from model output. Nothing runs outside an approved window or without an approved change, and HA peers are never patched together.

Which systems does it cover?

Linux first: Red Hat Satellite, Ansible and AWX, SUSE Manager, Canonical Landscape or an SSH relay, plus cloud VMs through AWS Systems Manager, Azure Update Manager and GCP VM Manager. Windows and endpoint tools such as SCCM, Intune and WSUS come in a later phase.

Where does it run?

In your VPC or on-premises, and it can use your own LLM. Integrations start read-only.

Is AI-Patch Manager available today?

It is a new module. It is set up for each environment and delivered in phases: window rules, CAB flow, freeze calendars, rings and gate thresholds are configured with your team, and custom Task Bees can be built for your own workflows.

How do we start?

With a 60-minute discovery session on your patching use case. Next comes a read-only plan in 2 to 3 weeks, built from an inventory export and your window calendar, with no server access. After you review it, a non-prod pilot on one application group, measured against your last patch cycle.