Operations

In manufacturing, the world model is the shared operating state of the plant: what is actually true right now about demand, capacity, supply, and the schedule, and how sure the business is of each. A manufacturer racing to meet demand is working blind in slow motion. A supplier slips a ship date in an email, one plant runs behind while another sits idle, the ERP shows inventory the floor cannot find, and the real schedule lives in a planner's spreadsheet no one else can see. Each system and each person is right about a slice, and no one holds the whole line. A belief state that lives outside the model reconciles those fragments into one current picture, bounded by the safety and commitment limits you set, so the ops agent schedules the right work instead of the work some stale screen implies.

The world

The environment is the manufacturing operation, often across more than one plant: customer orders and due dates, production and work orders, work centers and machines, the bill of materials, inventory and work in progress, suppliers and open POs, and the projects that tie long-lead jobs together. Entities are orders, parts, machines, suppliers, and plants. Relations cross all of them. This order depends-on that casting, this subassembly feeds final assembly, this supplier backlog blocks a job, this rush order competes-for the same work center as three others. Ground truth is scattered across the ERP and MRP, the MES on the floor, supplier emails, Teams threads, and the side spreadsheets people actually run the day on. The world model is the layer that reconciles them into one current picture instead of leaving every agent and planner to stitch it together by hand each morning.

What streams in

Observations arrive from every system and surface the operation already runs on:

• ERP and MRP data: production orders, inventory, purchase orders, and quoted lead times
• supplier emails and portal updates, where a ship date slips or a backlog first shows
• shop-floor signals: machine status, completed operations, scrap and rework, and what a supervisor reports at shift change
• project and change-order updates: milestones, customer commitments, and revised due dates
• the spreadsheets and trackers people keep on the side because the system of record never quite fit

That last channel is what makes it one picture. When the planner reschedules a job or a buyer confirms a new reship date, that becomes evidence the other agents read, so the schedule each one acts from already carries what the others just learned.

The belief state

The plant's operating picture is a set of claims drawn from every system and shift, each carrying confidence, provenance, and decay, alongside the gaps and conflicts no single screen shows.

1┌──────────────────────────────────────────────────────────────┐
2│  PRODUCTION OUTLOOK - PLANT 2                                │
3│                                                              │
4│  ● "Order #4812 ships on time"             58% │ ERP + floor │
5│  ● "Castings short by ~200 units"          82% │ supplier    │
6│  ● "Line 2 effective capacity ~70%"        74% │ MES live    │
7│  ● "Rush job can slot Thursday"            69% │ planner     │
8│    └─ ⚠ Decayed: floor count last confirmed 3 days ago       │
9│                                                              │
10│  Gap: "No firm reship date from the casting supplier"        │
11│  Contradiction: ERP shows 200 in stock; floor count says 40  │
12└──────────────────────────────────────────────────────────────┘

Every claim carries its source, so a ship date a buyer confirmed reads differently from one the ERP still assumes. The ERP-versus-floor contradiction is the kind that quietly breaks a schedule. It is invisible inside either system and obvious the moment both feed one picture. The agent that surfaces it reconciles every source at once, which is the one thing no single screen or person does.

What we're after

The intent is the operation's: meet demand on the dates the business committed to, without breaching safety, quality, or capacity. Success means the schedule reflects real capacity and real supply, the right jobs run in the right order, the commitments the business made are kept, and every scheduling call traces to evidence a manager can inspect. The limiting factor is the cross-system unknown most likely to break the plan, which here is the supplier's true reship date and the real floor count, not the machine telemetry. Moves are ranked against that intent, not against raw uncertainty, so attention lands where being wrong is most expensive.

The policy

A plant runs under rules that outrank any single shift's convenience. You encode them once, and every agent inherits them:

The actions

Group what an agent may do by what it costs to be wrong:

Today, policy and actions are a modeling lens you encode, not a contract the engine runs for you. The safety limits, the source hierarchy, and these safety classes live in how each agent observes and acts. The engine does not yet take a registered policy and refuse the calls that violate it; a declarative config surface for that is on the roadmap. Read the tables as the contract your agents uphold. What the engine guarantees is the rest of the loop: it fuses the signals into one picture, surfaces the conflicts, and keeps the trail, and a qualified human stays on the loop for anything that commits the business.

Plan & act

An operating agent does not start from the work order in front of it. It orients on the whole production picture, reads the cross-system move most at risk, and acts, with the result folding back in for every other plant and planner:

1import Beliefs from 'beliefs'
2
3const beliefs = new Beliefs({
4  apiKey: process.env.BELIEFS_KEY,
5  agent: 'production-planner',
6  namespace: 'plant:2',
7  writeScope: 'space',
8})
9
10// 1. Orient: read the production picture; the ranked next moves ride back on it
11const context = await beliefs.before('Can we hit the committed dates this week, and what is most at risk?')
12const [move] = context.moves   // top-ranked, already in hand; no extra call
13// → { action: 'gather_evidence', subType: 'confirm-reship-date', valueOfInformation: 0.8, ... }
14
15// 2. Act: your agent dispatches the tool the move points to
16const supply = await runTool(move.subType)   // 'confirm-reship-date' → your supplier portal + email reconciler
17
18// 3. Fold the result back in; it becomes the next observation for every plant and planner
19await beliefs.after(JSON.stringify(supply), { tool: 'supplier-portal', source: 'po+email' })

The verdict is the product. A stack of ERP screens and side spreadsheets hands a planner a dozen views and leaves the reconciliation to a morning standup. The production world model renders the call: order #4812 is at risk on the casting shortage, confirm the reship date and the true floor count before promising the date, and here is the confidence on each claim and the system it came from. Because every belief traces to the email, count, or work order it came off, a needs-approval expedite reaches a manager with its evidence attached. The picture every agent and planner acts from stays current, so the operation can scale work without scaling the morning standup.