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

# Operations / Logistics Department Playbook

> See how the agent blueprint applies to an operations or logistics department — role definition, SOPs, threshold monitoring, inter-department messaging, and escalation rules.

# 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.

<Note>
  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](/consulting/scoping) for how scoping works.
</Note>

***

## 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

<Accordion title="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:**

  1. Query the defined data points in your ERP system (e.g. current stock levels by SKU, open order statuses, delivery milestone timestamps).
  2. Compare each data point against the configured threshold rules.
  3. 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.).
  4. Log all threshold events.
  5. 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.
</Accordion>

<Accordion title="SOP 2: Determine response to a threshold event">
  **Trigger:** A threshold event record from SOP 1.

  **Steps:**

  1. Look up the event type in the response rules configured for this deployment.
  2. Determine the defined response: **pre-approved action** (agent executes automatically) or **human notification required** (agent routes and notifies).
  3. 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.
</Accordion>

<Accordion title="SOP 3a: Execute a pre-approved action">
  **Trigger:** Threshold event with a defined pre-approved action response.

  **Steps:**

  1. 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).
  2. Log the action taken, the threshold event that triggered it, and the timestamp.
  3. 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.
</Accordion>

<Accordion title="SOP 3b: Notify and route to a human">
  **Trigger:** Threshold event requiring human notification, or an unrecognised event type.

  **Steps:**

  1. 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.
  2. Send the notification via the configured channel.
  3. Log the notification with the recipient identity and timestamp.
  4. 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.
</Accordion>

***

## 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.

```json theme={null}
{
  "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?](/what-is-an-agent) and [Agent Structure → Overview](/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?](/what-is-an-agent) — role definitions and the three layers of every agent
* [Agent Structure → Overview](/agent-structure/overview) — inputs, intelligence, and actions
* [Agent Structure → Components](/agent-structure/components) — guardrails, tools, and handoff rules
* [Agent Structure → Integrations](/agent-structure/integrations) — connecting ERP systems and message queues
* [ERP & Legacy Systems](/agent-structure/integrations) — adapter patterns for connecting to existing operational systems
* [Scope & Boundaries](/consulting/scoping) — how threshold rules and scope are defined and controlled