Example 2: Multi-Agent Enterprise Procurement

Domain: Purchase order approval workflow across a mid-size manufacturing enterprise
Stakes: Financial exposure from incorrect approvals, audit trail gaps, vendor relationship risk
Context: Five OCTO agents being configured to automate procurement routing

The Situation

A manufacturing company is deploying five agents across their procurement workflow using REACH + OCTO. Each agent has a defined responsibility: vendor verification, budget check, approval routing, PO generation, confirmation dispatch.

The workflow looks clean on a diagram. Each agent has a lane. The instinct is to configure and deploy.

GDD says: what happens when the diagram lies?

The ICR Cycle

FORMALIZE — stated assumptions

[1] We believe an agent may modify a PO only if it holds the current lock.
[2] We believe approval limits are static — set quarterly by finance.
[3] We believe vendor verification is binary — approved or not approved.
[4] We believe the budget check agent sees real-time committed spend.
[5] We believe a PO above $50,000 requires VP approval.
[6] We believe agents operate sequentially — one completes before next starts.
[7] We believe the confirmation agent dispatches only after full approval.
[8] We believe rejected POs are returned to the requestor with a reason.

STRESS — what breaks each

[1] breaks if: two agents request the same PO simultaneously
              a lock expires mid-modification (timeout not defined)
              an agent fails after acquiring the lock but before releasing it

[3] breaks if: vendor is approved for one category but not another
              vendor approval expired — flag not updated in source system
              vendor is on a probationary status (partial approval)

[4] breaks if: committed spend is updated by a batch job that runs at midnight
              two POs are approved in the same minute — both see the same
              pre-commit balance and both pass the budget check

[6] breaks if: the confirmation agent is triggered by a webhook that fires
              before the approval agent has written its decision
              (this is a race condition — not a hypothetical)

CHECK — internal consistency

[CONFLICT A] Statement [6] assumes sequential operation.
             Statement [1] defines a locking model.
             Locking is only necessary if concurrent access is possible.
             If truly sequential, locks are unnecessary.
             If locks are necessary, [6] is false.

[CONFLICT B] Statement [4] assumes real-time committed spend.
             Stress test reveals batch update cycle.
             Real-time and batch are mutually exclusive.
             The budget check agent is operating on stale data.

[CONFLICT C] Statement [3] assumes binary vendor status.
             Procurement policy has three states: approved, probationary, suspended.
             Binary assumption will incorrectly route probationary vendors.

SURFACE — unresolvable residue

ITEM 1: Are agents sequential or concurrent?
  Cannot resolve from: OCTO configuration (not yet built)
  Decision required from: Engineering Lead + Procurement Operations
  Consequence: if concurrent, locking model must be designed before deployment
  Deadline: before OCTO arm configuration begins

ITEM 2: What is the budget check data freshness guarantee?
  Cannot resolve from: procurement system documentation (does not specify)
  Decision required from: Finance Systems + Procurement Operations
  Options: accept stale data with defined staleness window,
           add a pre-commit reservation step before approval
  Deadline: before budget check agent is configured

ITEM 3: How does the system handle probationary vendors?
  Cannot resolve from: current agent design (binary only)
  Decision required from: Procurement Policy Owner
  Options: treat as approved (current silent behaviour),
           treat as suspended (conservative),
           route to human review (correct — requires Synthesis Gate)
  Deadline: before vendor verification agent is configured

GATE

Three decisions before OCTO is configured:

1. Engineering confirms: agents are concurrent — locking model designed and specified before deployment
2. Finance and Procurement agree: budget check uses reservation pattern — a hold is placed at check time, released if PO is rejected
3. Procurement Policy Owner decides: probationary vendors route to human review — a Synthesis Gate is added to the vendor verification arm

What Changed

The race condition in the confirmation webhook was caught before deployment. The budget double-approval exposure was eliminated by the reservation pattern. Probationary vendors now surface to a procurement manager rather than being silently approved or silently blocked.

None of these were visible on the original workflow diagram.

The GDD cycle ran as a two-hour workshop with six people. It prevented three categories of production incident before a single agent was configured.

---

Next example: AI-First Feature Development →