What makes this an agent and not just a report?

A report shows you data. An agent acts on it. This agent reads work order and job card data, applies rules to detect overdue WOs and bottlenecks, generates a prioritised briefing, and - in the LLM extension - outputs specific recommended actions per work order. The key difference is the sense-reason-act loop: the agent senses the current production state, reasons about risk using calibrated rules, and acts by producing actionable outputs rather than just raw data. The next step is giving the agent tools to write back to the ERP - creating task escalations or updating planned dates directly.

Does this require an LLM API key?

No. The core analysis - work order status, bottleneck detection, overdue flags, daily briefing - is rule-based Python and requires no API key. The notebook includes an optional LLM extension that passes the structured briefing data to Claude or GPT-4 to generate a natural language summary with customer-specific context. The LLM adds readability for a non-technical production manager but does not change the underlying analysis. Run the notebook without the LLM section first; add the API call once the rule-based logic is working to your satisfaction.

How does the agent know which operation a work order is currently at?

The agent reads job cards - one per operation per work order. A completed job card means that operation is done. The current operation is the first job card in the routing sequence that is not yet complete. In ForgeFlow, the standard routing is: Induction Heating → Die Forging → Flash Trimming → Dimensional Inspection → CNC Turning or VMC Milling. The agent builds this map from the job card data and uses it to show exactly where each WO is in the production pipeline.

How does the agent detect a bottleneck?

Bottleneck detection counts how many work orders are currently waiting at each workstation. A workstation with multiple concurrent WOs is a queue. In ForgeFlow historical data, the Heavy Forging Press consistently has the highest concurrent load - 90 of 250 job card slots go through it, and it is the single station that both overdue and on-time WOs share. The agent flags any workstation with 2 or more concurrent WOs and ranks them by total WO count to identify the primary constraint.

Can the agent detect a delivery risk before the customer misses their date?

Yes, that is the primary value. The agent combines two inputs: the current elapsed days for each WO and the calibrated lead time from playbook 2 (20 days median actual for most item families). If a WO is at Day 12 and still has 3 operations left, and 3 operations historically take 8-10 days, the agent can project the expected completion date and compare it to the customer delivery date. If the gap is negative - expected completion is after delivery date - the agent raises a delivery risk flag before the date is missed, not after.

Manufacturing Series Built on ForgeFlowFirst LLM playbook

Production Workflow Agent

Read job card state, detect overdue work orders, find the bottleneck workstation - then let an LLM write the briefing

The Problem

The production manager starts every day without knowing which jobs are at risk

ForgeFlow has 50 work orders, 250 job cards, and 6 workstations. Every morning, someone manually checks which WOs are running, where they are in the routing, and whether any deliveries are at risk. It takes 30-45 minutes and is usually wrong by the time the shop floor shift starts. The workflow agent does this in seconds - reads the current job card state, identifies what is overdue, finds the bottleneck workstation, and produces a briefing the production manager can act on before the first tool is picked up.

4/7

WOs currently overdue

All past their planned completion date

3 WOs

at Heavy Press now

Primary throughput bottleneck confirmed

1 day

planned for FG-YK Yoke

Actual median: 18 days - template never corrected

Reads work order and job card data from ERP to reconstruct current production state
Identifies current operation per WO by finding the last completed job card in the routing sequence
Flags overdue WOs, counts concurrent load per workstation, detects the bottleneck
Generates a structured daily briefing - rule-based core, optional LLM natural language summary

The Data

Work orders and job cards

Work Orders50

9 item families, Jan-Jun 2026. Planned vs actual start and end dates. Source of delivery risk calculation.

Job Cards250

5 operations per WO. Status (Completed/In Progress/Pending). Source of current-stage detection per WO.

Operations6 types

Induction Heating, Die Forging, Flash Trimming, Dimensional Inspection, CNC Turning, VMC Milling.

Workstations6

Heavy Forging Press, Light Forging Press, Induction Furnace Bay, Quality Lab, CNC Turning Bay, VMC Bay.

Agent Output

Production state - 16 Jul 2026

Filter by status. Click any work order to expand its detail. The daily briefing at the bottom shows the agent output - the same text the production manager receives each morning. Click “Show” to read it.

Open work ordersForgeFlow - snapshot 16 Jul 2026

The Approach

Sense, reason, act

1. Sense - read current production state

Load work_orders.json and job_cards.json from ForgeFlow (or ERP export)
For each WO, find the last completed job card to determine current operation
Build a workstation load map: {workstation: [list of WO IDs currently there]}
Calculate elapsed days: today - actual_start_date for each open WO

2. Reason - apply risk rules

Overdue rule: elapsed_days > planned_days for item family (from playbook 2 calibration table)
Bottleneck rule: workstation with concurrent_wo_count >= 2 ranked by load
Delivery risk rule: projected_completion_date > customer_delivery_date
Template error rule: planned_days < 10 for Heavy Press items (known legacy misconfiguration)

3. Act - produce the briefing

Rule-based briefing: structured JSON with flags per WO, bottleneck workstation, recommended actions
LLM extension (optional): pass briefing JSON to Claude as context, ask for natural language summary
Output channels: print to console, write to Slack webhook, email to production manager
Next step (not in this playbook): agent with ERP write access to create task escalations directly

First LLM in the series

Why add an LLM here, not earlier?

The first three playbooks in this series used pure Python - no API key, no model calls, no hallucination risk. The data spoke for itself. A supplier scorecard, a lead time calibration, a spend dashboard - these are tables and numbers. A production manager reading them does not need a model to interpret what 0% on-time delivery means.

This playbook is different. The agent output is not a table - it is a prioritised list of decisions: which WOs to escalate, which customer to call, which workstation to relieve. That is where language models add real value - taking structured data and producing a clear, prioritised, customer-context-aware summary that a production manager can read in 90 seconds.

The rule-based core does the reasoning. The LLM adds readability. This is the correct architecture: rules for deterministic decisions, models for communication.

Core Concepts

Key ideas in this playbook

Agentic Loop

Sense (read data) → Reason (apply rules) → Act (produce output) → repeat
This playbook implements one iteration. A production agent runs this loop every morning
The loop becomes more powerful when the "act" step can write back to the ERP, not just output text
Start with read-only agents. Only add write access once the reasoning is validated over several weeks

Current Stage Detection from Job Cards

An ERP does not usually expose "current operation" as a single field on the work order
You derive it from job cards: sort by routing sequence, find the first non-complete status
This requires knowing the standard routing per item - either from BOM or from historical job card patterns
ForgeFlow: routing is Induction → Die Forging → Trimming → Inspection → CNC/VMC (optional)

Rules vs LLM for Production Reasoning

Rules: fast, deterministic, auditable. Correct for structured decisions with clear thresholds
LLMs: flexible, contextual, readable. Correct for summarisation, prioritisation, communication
Never use an LLM to make a yes/no production decision (pause a work order, approve a PO)
Use an LLM to communicate the result of a rule-based decision to a human in natural language

Architecture

Taking it to production

Daily agent run (06:30)

Pull open WOs and job card statuses from ERP API or nightly export
Run sense-reason-act loop against calibrated lead time table from playbook 2
Generate structured JSON briefing with flags and recommended actions
Optional: call LLM to produce natural language summary paragraph
Send to Slack #production-briefing or email production manager

Next iteration: write access

After 4 weeks of validated read-only output, add ERP write tools
Agent creates task: "Reassign WO-203 from Heavy Press - alternative routing needed"
Agent updates planned dates on legacy-template WOs automatically
Agent drafts customer communication for delivery risk WOs (human approves before send)
Each new tool requires explicit validation before enabling in production

Run the notebook

Builds the production workflow agent from ForgeFlow work order and job card data. Reconstructs current production state, detects overdue WOs and workstation bottlenecks, and generates the daily briefing. No API key required for the core analysis. Optional LLM extension at the end uses the Anthropic API to add natural language summarisation.

Open in Colab