Operations / logistics department playbook

This playbook illustrates how the agent blueprint applies to a department whose primary job is monitoring the state of ongoing operational processes, detecting threshold events, and coordinating the right response. You might recognise this as a logistics coordinator, a supply chain operations desk, an inventory management function, or a broader operations team that sits between front-of-house and back-office departments. Use this as a reference when mapping the blueprint to your own equivalent department. Every placeholder (“Department D”, “VM-4”, “your ERP system”) stands in for the real names you would substitute during a scoping engagement.

This playbook describes a structural pattern, not a finished implementation. Exact scope, timelines, and fit for your situation are determined during the consulting process. See Scope & Boundaries for how scoping works.

Department profile

Dimension	Example value
Department name	Department D (operations / logistics)
Primary role	Monitor operational state, detect threshold events, and coordinate response across departments
Primary input sources	Your ERP system (stock and order events), scheduled triggers, inter-department message queue
Primary outbound interfaces	Your ERP system (status and reorder records), inter-department message queue, human review queue
VM designation	VM-4

Role definition

The agent’s role statement for an operations department:

VM-4 is responsible for monitoring defined operational metrics, detecting when a threshold or exception condition is met, and routing the appropriate response — either executing a pre-approved action or notifying the responsible person with full context. It does not make procurement decisions, confirm supplier orders, or modify financial records.

Operations agents typically have a wider monitoring surface than other department types but a narrower action set. They see a lot; they act only within tightly defined rules.

Standard operating procedures

SOP 1: Monitor and detect threshold events

Trigger: Scheduled polling of your ERP system (e.g. every hour, every 15 minutes — configured per deployment), or a real-time webhook event from your ERP system when a relevant record changes.Steps:

Query the defined data points in your ERP system (e.g. current stock levels by SKU, open order statuses, delivery milestone timestamps).
Compare each data point against the configured threshold rules.
For each threshold condition met, create a threshold event record containing: the data point, the threshold value, the current value, and the event type (low stock, delayed order, missed milestone, etc.).
Log all threshold events.
Route each event to SOP 2 for response determination.

Escalation rule: If the ERP query fails or returns unexpected data, route to the human review queue as “monitoring failure” rather than proceeding with incomplete data.

SOP 2: Determine response to a threshold event

Trigger: A threshold event record from SOP 1.Steps:

Look up the event type in the response rules configured for this deployment.
Determine the defined response: pre-approved action (agent executes automatically) or human notification required (agent routes and notifies).
Route to SOP 3a (pre-approved action) or SOP 3b (human notification) based on the determination.

Escalation rule: If no response rule is found for an event type, always default to SOP 3b (human notification). The agent never invents a response for an unrecognised event type.

SOP 3a: Execute a pre-approved action

Trigger: Threshold event with a defined pre-approved action response.Steps:

Execute the pre-approved action as defined in the response rules (e.g. create a draft reorder record in your ERP system, update a status flag, send a structured message to another department’s VM via the inter-department queue).
Log the action taken, the threshold event that triggered it, and the timestamp.
Send a summary notification to the configured oversight contact confirming the action was taken (oversight notifications are always on for pre-approved actions).

Important: Pre-approved actions are limited to record creation, status flag updates, and inter-department messages. They do not include submitting orders to external parties, making purchases, or modifying financial records. Those always require human sign-off.

SOP 3b: Notify and route to a human

Trigger: Threshold event requiring human notification, or an unrecognised event type.Steps:

Compose a notification for the responsible person containing: the event type, the data point that triggered it, the current value, the threshold value, the relevant record links in your ERP system, and a plain-language summary of what the agent found.
Send the notification via the configured channel.
Log the notification with the recipient identity and timestamp.
Set a follow-up reminder if no acknowledgement is received within the configured window.

Escalation rule: If the responsible person cannot be determined from routing rules, the notification goes to the department head or a defined fallback contact. It is never silently dropped.

Inter-department messaging

A key characteristic of operations agents is that they often need to communicate with other departments’ VMs — not just with external systems. This is done through a structured inter-department message queue rather than direct integration. An example: VM-4 detects a low-stock threshold event and creates a draft reorder record. Rather than emailing a supplier directly, it sends a structured message to VM-3 (the back-office agent) containing the draft record and a request to initiate the approval workflow.

{
  "message_type": "inter_department",
  "sender_vm": "VM-4",
  "recipient_vm": "VM-3",
  "subject": "draft_reorder_for_approval",
  "payload": {
    "item_ref": "SKU-00441",
    "current_stock": 12,
    "threshold": 25,
    "suggested_reorder_qty": 100,
    "supplier_ref": "VENDOR-0007",
    "draft_record_id": "DRAFT-REORDER-0091"
  },
  "requires_action": true,
  "timestamp": "2024-08-01T11:30:00Z"
}

VM-3 receives this message as an input event and applies its own SOPs from that point. No department VM bypasses another department’s approval chain. This pattern is described in more detail in What is an agent? and Agent Structure → Overview.

Input sources

Input source	What it delivers	Format
Your ERP system	Stock level data, order status records, delivery milestones	Structured JSON via webhook or polling
Scheduled trigger	Periodic monitoring sweeps	Timer event
Inter-department message queue	Messages from other department VMs requesting action or information	Structured JSON

Outbound interfaces

Outbound interface	What the agent writes	Requires human approval?
Your ERP system	Draft reorder records, status flag updates	No (draft only — purchasing action requires human)
Inter-department message queue	Structured messages to other VMs	No
Human notification channel	Threshold event alerts with full context	N/A (notification only)
Audit log	All monitoring events, actions taken, notifications sent	No (append-only)
Human review queue	Unrecognised event types, monitoring failures, escalations	N/A (routing only)

Threshold configuration

Threshold rules are configured per deployment. They are not hard-coded into the blueprint; they are defined with you during the design phase. A typical threshold configuration looks like this:

Event type	Condition	Configured response
Low stock	Item quantity falls below defined minimum	Create draft reorder record; notify purchasing contact
Delayed order	Expected delivery date passed with no receipt confirmation	Notify operations lead; flag in ERP
Missed milestone	Process step not completed within defined time window	Notify responsible team member
Unrecognised event	Event type not in response rules	Notify department head; log for rules review

Thresholds can be updated between phases without rebuilding the agent. A threshold change is a configuration update.

Escalation rules

The following situations always route to a human:

ERP monitoring query fails or returns unexpected data
An event type has no matching response rule
A pre-approved action fails to execute (ERP write failure, message queue error)
Follow-up reminder triggers with no acknowledgement from the notified person
Any event flagged in the ERP as high-priority or exception-state

Staged evolution

Phase	What is automated	What remains manual
Phase 1	Monitoring and logging only — no actions, notifications only	All response decisions
Phase 2	Human notifications added for defined threshold events	All pre-approved actions, all purchasing
Phase 3	Pre-approved actions added (draft records, status flags, inter-VM messages)	Purchasing execution, financial approvals (permanently manual)

Phase 1 is purely observational — the agent reads your ERP and logs what it sees. This phase lets you validate that the monitoring logic is detecting the right events before any response actions are turned on.

Cross-references

What is an agent? — role definitions and the three layers of every agent
Agent Structure → Overview — inputs, intelligence, and actions
Agent Structure → Components — guardrails, tools, and handoff rules
Agent Structure → Integrations — connecting ERP systems and message queues
ERP & Legacy Systems — adapter patterns for connecting to existing operational systems
Scope & Boundaries — how threshold rules and scope are defined and controlled

Get Started

Agent Structure

Implementation Blueprint

Small Business Playbooks

Consulting Process

Operations / Logistics Department Playbook

Operations / logistics department playbook

Department profile

Role definition

Standard operating procedures

Inter-department messaging

Input sources

Outbound interfaces

Threshold configuration

Escalation rules

Staged evolution

Cross-references

​Operations / logistics department playbook

​Department profile

​Role definition

​Standard operating procedures

​Inter-department messaging

​Input sources

​Outbound interfaces

​Threshold configuration

​Escalation rules

​Staged evolution

​Cross-references

Operations / logistics department playbook

Department profile

Role definition

Standard operating procedures

Inter-department messaging

Input sources

Outbound interfaces

Threshold configuration

Escalation rules

Staged evolution

Cross-references