Persistent Agents — Deployment and Schedule
You have spent the last nine lessons building the operations intelligence layer from scratch: vendor register, contract obligations, SOP library, change log, compliance map, risk register, incident post-mortems, and a metrics dashboard. Each of those artefacts has one thing in common — they were built once and will immediately start drifting.
The vendor register becomes stale the moment a new subscription renews without anyone noticing. The compliance map drifts when a regulatory update lands and nobody reviews its implications. The SOP library decays when a system change goes live without triggering a documentation update. The change log accumulates stale approvals when nobody tracks whether approved changes were ever implemented. In most organisations, this drift is invisible until it becomes an audit finding, a compliance breach, or an operational failure.
Persistent agents close this gap. Rather than waiting for a human to think to check — and hoping they remember — each agent runs on a fixed schedule, monitors a specific domain of your operational data, and alerts when something needs attention. This lesson deploys four agents: the Vendor Watchdog, the Process Health agent, the Compliance Monitor, and the Change Tracker. Together they form the automated monitoring layer of the operations intelligence system you have been building.
This is the transition from one-time analysis to continuous intelligence. The data is already built. Now you make it self-maintaining.
This exercise requires the Operations plugin (official) and the Operations Intelligence plugin (custom). If you have not installed them, follow the instructions in the Chapter 38 prerequisites before continuing.
Why Persistent Agents — and Why Only in the Custom Plugin
Every tool in the official Operations plugin was designed for on-demand use: you invoke /vendor-review when you want a vendor analysis, /change-request when you need an impact assessment. The official plugin is excellent at responding to requests. It does not, by design, watch for problems you haven't yet noticed.
The custom Operations Intelligence plugin adds the layer that the official plugin cannot: agents that run autonomously on a schedule, monitor operational data continuously, and alert without being asked. This is not a gap in the official plugin's quality — it is a deliberate architectural separation between command-response tools and persistent automation.
| Capability | Official Plugin (on-demand) | Custom Plugin (persistent) |
|---|---|---|
| Vendor evaluation | /vendor-review on request | Vendor Watchdog — weekly automation |
| Compliance tracking | compliance-tracking skill | Compliance Monitor — weekly check |
| Process documentation | /process-doc on request | Process Health — monthly check |
| Change management | /change-request on request | Change Tracker — weekly monitoring |
| Scheduled alert delivery | Not available | All four agents |
| Monthly COO reports | Not available | All four agents |
The practical difference: with only the official plugin, someone must remember to run the vendor audit every quarter. With the persistent agents, the Vendor Watchdog runs every Monday morning and delivers an alert if something needs attention — whether or not anyone remembered to check.
The Four Operations Agents
Agent 1: Vendor Watchdog
Purpose: Monitor the vendor portfolio continuously — renewals, SLA performance, spend versus budget, and unapproved vendor payments.
Schedule: Every Monday at 07:00
What it monitors:
| Check | What It Flags | Alert Recipient |
|---|---|---|
| Renewal calendar | Any contract renewing within 90 days | Contract owner + procurement |
| SLA performance | Any vendor below contracted SLA threshold this week | Vendor relationship owner |
| Spend vs. budget | Invoice above contracted rate, or cumulative spend >10% over budget | Finance + procurement |
| Approved vendor list | Payment to a vendor not on the approved list | Procurement + CFO |
Alert format — renewal example:
⚠️ RENEWAL ALERT: Salesforce CRM
Service: CRM platform (sales team + customer success)
Annual value: £124,000
Renewal date: 15 April — 47 days away
Notice required: 60 days (from contract)
Notice deadline: 16 February — ALREADY PASSED
Owner: Head of Sales
Action required: Begin emergency renewal process immediately.
Notice window has closed — auto-renewal will proceed
unless contract allows late cancellation. Verify
contract terms and engage vendor this week.
Escalating to: COO — contract value >£50,000 and notice deadline missed.
Alert format — SLA breach example:
🔴 SLA BREACH ALERT: CloudHost UK (infrastructure)
SLA metric: Uptime — contracted 99.9%
Contracted: 99.9%
Actual: 99.67% (three incidents this period)
Breach since: 3 March
Incidents: 3 (total 19.2 hours downtime)
Credit due: Check contract terms — likely £3,800-£7,200 based
on downtime duration and SLA credit formula
Owner: Head of IT
Action: Generate scorecard → initiate formal vendor conversation
→ submit credit claim before month end
Escalation: If breach continues >4 weeks: include in weekly COO report.
Monthly report to COO: Full vendor portfolio snapshot — spend, performance, renewal pipeline, rationalisation opportunities, and three prioritised recommended actions.
Agent 2: Process Health Agent
Purpose: Monitor the currency and completeness of the SOP library — overdue reviews, orphaned SOPs, change-triggered updates, and regulatory-triggered updates.
Schedule: First Monday of each month
What it monitors:
| Check | What It Flags | Alert Recipient |
|---|---|---|
| Review schedule | Any SOP overdue for review | SOP owner |
| Orphaned SOPs | SOPs where the named owner has left | Operations Manager |
| Change-triggered reviews | Changes marked complete that reference systems covered by SOPs | SOP owner |
| Regulation-triggered reviews | Regulatory changes that affect embedded controls in SOPs | SOP owner + CCO |
Alert format — overdue review:
⚠️ SOP REVIEW OVERDUE: SOP-0042: Client Onboarding Process
Owner: Sarah Okonkwo (Client Services Manager)
Tier: 1 (Critical)
Review due: 14 January — 52 days overdue
Action: Review by 28 February (Tier 1 — 14-day deadline from today)
Escalating: Tier 1 SOP overdue >30 days → Operations Manager notified.
If not reviewed by 28 February → escalate to COO.
Alert format — orphaned SOP:
🔴 ORPHANED SOP: SOP-0019: Payroll Submission Verification
Previous owner: James Mackenzie (Finance Controller — left 15 February)
Status: Owner has left the organisation
Action: Assign interim owner within 5 business days.
Schedule knowledge capture session — James left recently
and process knowledge may still be accessible.
Alert to: Finance Director + Operations Manager
Alert format — change-triggered review:
🟡 CHANGE-TRIGGERED REVIEW REQUIRED: SOP-0031: Software Access Provisioning
Change: CH-2024-047 — HR System Migration (completed 8 March)
What changed: Steps 3 and 4 of this SOP reference the old HR system's
user provisioning screens (Workday). Migration replaced
Workday with BambooHR. Steps 3, 4, and 7 now reference
screens that no longer exist.
SOP owner: IT Operations Manager
Action: Review and update SOP within 14 days (Tier 1 SOP).
Monthly process health report to COO: Full SOP library status — current, due for review, overdue, orphaned — plus change-triggered and regulation-triggered reviews pending.
Agent 3: Compliance Monitor
Purpose: Track all compliance obligations continuously — approaching review dates, aging evidence, regulatory changes, and unresolved gaps.
Schedule: Every Monday at 08:00
What it monitors:
| Check | What It Flags | Alert Recipient |
|---|---|---|
| Review schedule | Obligations due for review within 30 days | Obligation owner |
| Evidence currency | Obligations marked CURRENT but evidence >12 months old | Obligation owner |
| Regulatory changes | Relevant regulatory updates in configured jurisdictions | CCO |
| Open gaps | GAP obligations without remediation progress after 14 days | COO |
Alert format — obligation due for review:
⚠️ COMPLIANCE REVIEW DUE: OBL-007: UK GDPR — Data Retention Policy
Framework: UK GDPR (ICO)
Owner: Data Protection Officer
Review due: 5 April — 18 days away
Current status: 🟢 CURRENT
Action: Schedule review this week. Confirm data retention schedules
are still accurate for all data categories. Update evidence
record to confirm CURRENT status for another 12 months.
Alert format — regulatory change:
📋 REGULATORY CHANGE DETECTED: ICO Guidance Update — Legitimate Interest Assessments
Framework: UK GDPR (ICO)
Change: Updated guidance on when a Legitimate Interest Assessment (LIA)
is required. New guidance narrows the circumstances where
legitimate interest can be used as a lawful basis.
Effective: 1 April 2026
Source: [ICO official guidance URL]
Potentially affected obligations:
OBL-004: Marketing communications consent basis
OBL-012: Third-party data sharing lawful basis
Action: Brief sent to Data Protection Officer and CCO for impact
assessment. Do NOT update obligation status automatically —
human review required before any status changes.
Note on status changes: The Compliance Monitor never updates obligation status automatically. Regulatory changes are flagged for human review. Only the named obligation owner, after confirming control effectiveness, can change a status from PARTIAL to CURRENT. This is deliberate — automated status changes on compliance obligations create audit liability.
Quarterly report to Board/Audit Committee: Full compliance dashboard, regulatory changes assessed, open actions, upcoming obligations and review schedule.
Agent 4: Change Tracker
Purpose: Monitor all open change requests — impact assessment compliance, rollback plan presence, stale approvals, overdue changes, post-implementation reviews, and emergency change retrospectives.
Schedule: Every Friday at 16:00
What it monitors:
| Check | What It Flags | Alert Recipient |
|---|---|---|
| Impact assessment | Major/Critical changes approved without completed impact assessment | Change Manager + COO |
| Rollback plan | Major/Critical changes approaching go-live without a rollback plan | Change owner + Change Manager |
| Stale approvals | Changes approved >4 weeks ago with no implementation recorded | Change owner |
| Overdue changes | Changes >2 weeks past their planned implementation date | Change owner → COO |
| PIR tracking | Post-implementation reviews overdue for Major/Critical changes | Change owner → Change Manager |
| Emergency retrospectives | Emergency changes without retrospective review within 10 business days | Change owner |
Alert format — missing impact assessment:
🔴 CHANGE BLOCKED — MISSING IMPACT ASSESSMENT: CH-2024-089: ERP Module Upgrade
Classification: MAJOR
Approved by: Operations Director — 12 March
Missing: Impact assessment (required for MAJOR changes)
Action: Change is paused pending impact assessment completion.
This change must not proceed to implementation until
the impact assessment is complete and reviewed.
Alert to: Change Manager (enforce pause) + COO (visibility)
Owner: IT Programme Manager
Alert format — PIR overdue:
🟡 PIR OVERDUE: CH-2024-071: CRM System Upgrade
Go-live date: 8 February
PIR due: 8 March (4 weeks post go-live — MAJOR change)
Days overdue: 12 days
Owner: Head of IT
Action: Complete PIR within 5 business days.
Escalation: If not completed by 20 March → alert to Change Manager.
Note: This was a significant change (2-day outage during
go-live weekend). PIR is particularly important here
— the failure mode should be documented and prevented.
Agent Interdependencies — How the Network Works
The four agents are designed to be independent but their outputs interact. Understanding these interactions is the difference between running four uncoordinated monitors and running a coordinated operations intelligence network.
Compliance Monitor detects regulatory change
↓
Process Health Agent checks which SOPs embed controls
for the affected obligation
↓
Process Health Agent alerts SOP owners for regulation-triggered reviews
Change Tracker closes a change
↓
Process Health Agent cross-references the change log
against the SOP library
↓
Process Health Agent flags SOPs referencing the changed system
Vendor Watchdog detects SLA breach
↓
Risk register (L09) should be updated — the vendor's SLA
failure creates an operational risk entry
↓
Compliance Monitor may need to check if any compliance
obligation depends on this vendor's performance
| Interaction Chain | Trigger Agent | Responding Agent | Why |
|---|---|---|---|
| Regulatory change → SOPs | Compliance Monitor | Process Health | Controls in SOPs must reflect updated regulatory requirements |
| Change closure → SOP review | Change Tracker | Process Health | Changed systems affect documented processes |
| SLA breach → risk register | Vendor Watchdog | Manual update (L09) | Vendor failure is an operational risk |
| New vendor → approved list | Vendor Watchdog | Procurement (human) | Unapproved vendor must go through formal approval |
These interactions are not automatic — the agents alert; humans act. But by making the interactions explicit, you ensure that a regulatory change does not leave outdated SOPs unchecked, and a system change does not leave process documentation that still references the old system. The agents create the visibility; your operations team acts on it.
Configuring the Agents
Each agent requires configuration before its first run. Configuration lives in ops.local.md — the organisation-specific configuration file you built in Lesson 2. Agents draw their thresholds, data source paths, and escalation contacts from this file.
Minimum configuration for each agent:
| Agent | Required Configuration |
|---|---|
| Vendor Watchdog | Vendor list path or MCP source, approved vendor list, spend thresholds, escalation contacts |
| Process Health | SOP library path or MCP source, review cycle per tier, escalation thresholds (days), contacts |
| Compliance Monitor | Compliance map path, jurisdictions to monitor (web search targets), evidence age thresholds |
| Change Tracker | Change log path or MCP source, classification thresholds, PIR deadlines per classification |
Worked example — configuring the Vendor Watchdog:
Configure the vendor-watchdog agent for our organisation.
Data sources:
- Vendor list: [paste vendor list or describe MCP source]
- Contract repository: [Google Drive folder / SharePoint path / MCP]
- Finance system: [manual invoice data / MCP integration]
- Approved vendor list: [from ops.local.md]
Schedule: Every Monday 07:00
Alert recipients:
- Renewal alerts: Contract owner + Head of Procurement
- SLA breach alerts: IT Operations Manager + relevant vendor owner
- Spend alerts: Finance Controller + Head of Procurement
- Unapproved vendor: Head of Procurement + CFO
Escalation thresholds:
- Contracts >£50,000 with renewal <60 days and no strategy: alert COO
- SLA breach persisting >4 weeks: include in COO report
Configure and confirm the first weekly check schedule.
What to expect: The agent confirms its configuration and describes what it will check on first run. If data sources are not yet integrated via MCP, it will describe what data you need to provide manually for each check.
Exercise: Deploy All Four Agents (Exercise 12)
Type: Agent deployment and configuration Time: 35 minutes Plugin: Operations Intelligence (custom) — persistent agents Goal: Configure all four agents, run a simulated weekly/monthly check for each, and review the output quality
This exercise requires the Operations Intelligence custom plugin. The official Operations plugin is not used in this exercise.
Step 1 — Prepare the Configuration Context
Before configuring the agents, gather the following for your 200-person professional services firm:
- Your vendor list and approved vendor list (from Lesson 3, or create a representative list)
- Your SOP library structure (from Lesson 5, or describe a representative set)
- Your compliance obligation map (from Lesson 7, or describe primary obligations)
- Your change log (from Lesson 6, or describe recent changes)
If you have not completed the earlier lessons, use the running context: 200-person UK professional services firm, ~47 vendors, ~20 SOPs across four tiers, primary regulatory framework UK GDPR, two recent changes in the change log.
Step 2 — Configure and Run Each Agent
For each agent, use the following prompt pattern, adapting to your data:
Vendor Watchdog:
Configure the vendor-watchdog agent for our 200-person UK professional
services firm.
Vendor data: [paste or describe your vendor list — at minimum include
5-10 vendors with renewal dates, annual values, and SLA commitments]
Schedule: Monday 07:00
Escalation:
- Renewals >£50,000 due <60 days with no strategy: alert COO
- SLA breach >4 weeks: escalate to monthly COO report
Alert recipients:
- Renewal: [name]/Head of Procurement
- SLA breach: IT Manager + vendor owner
- Spend variances: Finance Controller + Procurement
- Unapproved vendors: Procurement + CFO
Run the first weekly check and show me what alerts would be generated
based on the data I provided.
Process Health Agent:
Configure the process-health agent for our organisation.
SOP library: [describe your SOPs — include at minimum 5 SOPs with
tier, review cycle, and named owner. Include at least one SOP with
an overdue review date and one SOP whose owner has recently left.]
Review cycles: Tier 1 — annual, Tier 2 — 18 months, Tier 3 — 2 years
Recent changes: [describe any recent system changes from your change
log that might affect documented processes]
Schedule: First Monday of each month
Run the monthly check and show me the process health report.
Compliance Monitor:
Configure the compliance-monitor agent for our UK professional
services firm.
Compliance map: [describe or paste your compliance obligations —
include at minimum: UK GDPR, Companies Act, at least one FCA obligation
if applicable, employment law. Include at least one obligation whose
review is due within 30 days and one where evidence is >12 months old.]
Jurisdictions to monitor: UK (FCA, ICO, HMRC, HSE)
Evidence age threshold: 12 months standard; 6 months for high-risk obligations
Escalation: Gaps unresolved >14 days → COO alert
Schedule: Monday 08:00
Run the weekly check and show me the alerts that would be generated.
Change Tracker:
Configure the change-tracker agent for our organisation.
Change log: [describe your open and recently completed changes —
include at minimum 3-4 changes: one Major change approved but
awaiting implementation, one recently completed Major change
without a PIR yet, one change approaching its planned go-live
date without a rollback plan.]
PIR deadlines: Major/Critical — 4 weeks; Significant — 6 weeks
Schedule: Friday 16:00
Run the weekly check and show me the alerts that would be generated.
Step 3 — Evaluate Agent Output Quality
For each agent's output, evaluate:
What to evaluate:
- Does each alert include a specific recommended action — not just a status? "Contract renewing soon" is a status. "Begin renegotiation by [date] because notice period requires action by [date]" is an action.
- Are escalation thresholds clear? Can the recipient tell exactly when something will be escalated and to whom?
- Would the COO find the monthly report actionable? Count the number of decisions the COO can make from the report versus the number of follow-up questions they would need to ask.
- Are the agents monitoring the data you built in Lessons 3-11? The Vendor Watchdog should reference your vendor register. The Process Health agent should reference your SOP library. If the agents are giving generic output, your configuration context is insufficient — add more specific data.
- Does the monthly report have a recommended actions section? A report without recommendations is a status update, not intelligence.
Step 4 — Trace the Interaction Chain
Run this additional prompt to test the agent network's coordination:
The compliance-monitor agent has just detected a new UK ICO guidance
update that affects how we document consent for marketing communications.
This affects obligation OBL-004 in our compliance map.
Which SOPs in our process library should the process-health agent now
flag for review? What alert would the process-health agent generate?
What action should the SOP owner take?
Show me the full interaction chain from the regulatory change detection
to the SOP update completion.
Deliverable: Four configured agents, each producing at least one alert and a monthly report structure. A traced interaction chain from regulatory change to SOP review. Save your configuration — Lesson 13 uses the agent outputs to build the operations intelligence brief.
The agent outputs you generate in this lesson — alerts, monthly reports, and the interaction chain — are the inputs to Lesson 13 (Operations Intelligence Brief). Keep them in your Cowork session. You will synthesise them into a single COO-level brief in the next lesson.
Try With AI
Reproduce: Apply what you just learned to a simple case.
I am configuring the vendor-watchdog agent for a 30-person technology
startup. Here is our vendor data:
- AWS: £180,000/yr, renews September, cloud infrastructure, 99.9% uptime SLA
- Salesforce: £45,000/yr, renews March (45 days away), CRM
- Stripe: £22,000/yr (transaction fees), no renewal date, payment processing
- GitHub: £18,000/yr, renews October, code hosting
- Slack: £12,000/yr, renews June, team communications
Schedule: Monday 07:00
Escalation: Contracts >£30,000 with renewal <60 days → COO alert
Run the first weekly check. What alerts would be generated?
What you are learning: Even a minimal vendor list generates meaningful alerts when a significant contract (Salesforce, £45,000) is approaching renewal with only 45 days — below the 60-day escalation threshold. Notice how the alert format determines whether the recipient knows what to do or just knows that something is happening.
Adapt: Modify the scenario to match your organisation.
I want to configure the change-tracker agent for our organisation.
Here is our current change log:
[Describe 3-5 open or recently completed changes. Include at least
one Major change that has been approved but not yet implemented,
and at least one recently completed change that needs a PIR.]
Our change classifications: Standard / Significant / Major / Critical
PIR requirements: Major and Critical — mandatory within 4 weeks.
What alerts should the change-tracker generate for this pipeline?
What is the change failure rate based on the data I provided?
What you are learning: Applying the Change Tracker to your own change log reveals whether your change process is operating within its own governance requirements — or whether the review that no one has done yet was actually required. The agent makes these gaps visible without requiring anyone to manually track every change's compliance status.
Apply: Extend to a new situation the lesson didn't cover directly.
I am the COO of a 200-person professional services firm. I have
four operations agents configured and running. It is the first
Monday of the month — all four agents have run their checks.
The Vendor Watchdog has flagged: two upcoming renewals, one SLA
breach (infrastructure provider, week 3), one unapproved vendor
payment (£2,400 from marketing department).
The Process Health agent has flagged: one Tier 1 SOP overdue
by 45 days, three change-triggered reviews pending, one orphaned
SOP (owner left last month).
The Compliance Monitor has flagged: two obligations due for review
in the next 30 days, one regulatory change requiring assessment,
one GAP obligation 18 days old.
The Change Tracker has flagged: one Major change missing a rollback
plan (go-live in 8 days), two PIRs overdue.
I have 90 minutes this Monday morning to address the most critical
items. Which three items require my personal attention this week
versus which can be delegated? What does each delegation instruction
look like?
What you are learning: Triage is the COO's most important skill when the agents deliver their Monday morning output. Not every alert is equal — the Major change missing a rollback plan with a go-live in 8 days demands immediate action; the SOP overdue by 45 days is serious but not today's emergency. This prompt builds the judgment to prioritise across the four agent outputs simultaneously.
Flashcards Study Aid
Continue to Lesson 13: Operations Intelligence Brief →