A mid-market manufacturer. Three factories. Twelve suppliers. Fourteen AI agents. And one question that broke everything: what does "available" actually mean?
Let me introduce our new hero that joins me on a journey of developing The Orchestrator project.
NovaTrade
NovaTrade makes industrial components. Three factories - one in Shenzhen, one in Pune, one outside Warsaw. Twelve suppliers across four continents. Distribution centres in Singapore, Rotterdam, and Chicago. Customers ranging from automotive OEMs to construction companies that order in bulk and complain about everything.
It's a fictional company. I built it from synthetic data to stress-test a multi-agent system I've been developing called The Orchestrator. But the operational profile is real - pulled from patterns I've seen across twenty years of supply chain work in Automotive, FMCG, Industrial, Life-Science and AgriFood sectors. Mid-market complexity. Not enough scale for SAP's full stack, too much complexity for spreadsheets. The kind of company where the planning team uses one system, logistics uses another, procurement uses a third, and finance reconciles them all in Excel every Thursday.
I am giving NovaTrade fourteen AI agents - one for demand sensing, one for procurement, one for logistics, one for quality, and so on across seven operational stages. Each agent specialises in its domain. Each connected to the company's data. Each producing recommendations autonomously.
And then I run them together and start learning, blueprinting and sharing with readers.
The Contradiction
The demand sensing agent detected a 35% spike in APAC orders. It flagged the signal, loaded NovaTrade's current inventory position, and recommended increasing the Shenzhen factory's output to meet the surge.
At the same time, the procurement agent received a quality alert on Meridian Steel Works - one of NovaTrade's key suppliers. Defect rate at 3.2% against a 2.0% threshold. The agent cross-referenced the active contract, checked the supplier scorecard, and recommended pausing new purchase orders until the quality issue was resolved.
Both recommendations were individually correct. Together, they were a contradiction. You can't ramp production while pausing the supplier that feeds the production line. The demand agent didn't know about the quality hold. The procurement agent didn't know about the demand spike. They were each working from their own slice of NovaTrade's reality.
This isn't a hypothetical failure. It's the most common failure mode in multi-agent systems - and it doesn't show up in implementation post-mortems because it's too quiet. No single agent made a mistake. The system produced a plan that couldn't be executed. And the operator had to catch it manually.
I spent two weeks trying to solve this through better integration. Finer-grained sync between systems. More frequent polling. Smarter conflict resolution logic. None of it held. The problem wasn't the connections between agents. It was the architecture underneath them.
The Integration Trap
The instinct when connecting agents is to connect what already exists. NovaTrade has an ERP for financials, a TMS for logistics, a planning tool for forecasts, a WMS for inventory. The obvious approach: write adapters, build APIs, map data models, get agents talking to each source of record separately.
This works until two agents need to act on the same operational situation simultaneously. Then you need them to share not just data - but the same interpretation of that data. What counts as a "delay"? What's the current status of this purchase order? What does "available" mean when some stock is allocated, some is in transit, and some is on hold for quality inspection?
Every system answers these questions differently. And in a multi-agent environment, those differences don't average out. They compound.
The right move wasn't to connect the existing systems more tightly. It was to design a unified layer that all agents use as their single source of truth - and build everything on top of that.
I'm calling it the Supply Chain Helix™.
Why Three Strands
The insight that unlocked the design was simpler than I expected.
Every movement in a supply chain has three simultaneous dimensions. Something physical moves. Information signals accompany it. Money flows as a result. These aren't three separate streams - they're inseparable. A container that ships without an invoice is a financial liability. An invoice without a matching shipment is a dispute waiting to happen. A demand signal with no inventory response is just noise.
Most systems track these flows in isolation. The ERP owns financials. The TMS owns logistics. The planning tool owns signals and forecasts. Connecting them is the industry's oldest problem - and it's why "single source of truth" has been a supply chain aspiration for thirty years without ever quite arriving.
The Supply Chain Helix™ reframes the problem. Instead of syncing three separate systems, you model the supply chain as three intertwined strands that are fundamentally one thing:
Strand 1 - Material Flow. Physical goods moving through nodes - supplier, factory, warehouse, distribution center, customer. NovaTrade's network is 12 suppliers, 3 factories, 2 warehouses, 3 DCs, and a customer base. Every node has a type, location, capacity, capabilities, cost structure, and risk profile. Lanes connect nodes with transit times, costs, and reliability scores. The physical network is a graph, not a list.
Strand 2 - Information Flow. Forecasts, orders, decisions, status updates, alerts - bidirectional across the network. When NovaTrade's demand sensing agent detected the APAC spike, that signal arrived with type, severity, and payload. The decision it produced was recorded with full reasoning and provenance. The purchase order it referenced carries a state machine that defines valid lifecycle transitions. Nothing is freeform. Every business object has a schema.
Strand 3 - Financial Flow. Payments, costs, invoices, working capital impact at every handoff. Not a separate ledger - woven into the same record as the physical movement and information signal that triggered it.
Every record in the Helix carries all three simultaneously. Every agent reads and writes to the same shared layer - not their own local copy. Not a cached version. The same one.
This eliminates the NovaTrade contradiction. Agents can disagree on what to do - that's healthy, that's why you have multiple specialised agents. But they can't disagree on what is. The Helix is the shared definition of reality.
The Vocabulary Problem Underneath All of This
Before building the schema, I had to solve a less obvious problem: language.
In every supply chain implementation I've run - the same pattern appears. Two functions use the same word to mean different things. "Availability" means something in commercial, something different in operations, something else in finance. At NovaTrade, "available" inventory could mean on-hand in the warehouse, in-transit from Shenzhen, or allocated-but-not-yet-picked for an existing order. Three different numbers. Three different agents. Three different answers.
When you're building manual workflows, humans absorb the translation overhead. When you're building autonomous agents, that ambiguity becomes a hard bug.
So before writing a single line of schema, I defined a controlled vocabulary. Fifteen terms, each with an unambiguous definition:
Not fifteen terms as documentation overhead. Fifteen terms as load-bearing infrastructure. Every agent, every API endpoint, every piece of configuration uses these terms in exactly the same way.
This sounds obvious. Most implementations skip it anyway - because defining vocabulary before building feels like delay. What it actually is: the thing that prevents you from rebuilding the data model six weeks in.
The DNA Analogy (And Why It's More Than Decorative)
I reached for the DNA metaphor because the structural parallel is precise enough to be useful.
DNA encodes an organism's complete blueprint through intertwined strands that every cellular process reads and modifies according to strict rules. The strands aren't separate documents that get synced - they're one unified structure that the entire system treats as ground truth.
In the Helix model:
- agents are enzymes - they read the shared layer and make changes according to their specialisation
- decisions are mutations - recorded, traceable, with consequences that propagate through the system.
- policies are gene expression rules - they determine which agent behaviors activate under which conditions.
- the full network topology - every NovaTrade node, every lane, every relationship - is the genome.
The analogy extends to something important about evolution. DNA doesn't just store state - it accumulates learning. The Helix is designed with the same property: every decision an agent makes is recorded with full provenance in an immutable trace table. No updates. No deletes. Over time, the system builds a corpus of operational choices, outcomes, and patterns. That corpus is what enables higher levels of autonomy - not configuration, not rules, but learned behavior from the decision record itself.
What The Schema Actually Looks Like
The Helix is implemented as a PostgreSQL schema with a sch.* prefix. Five layers:
Layer 1 - Network Graph. sch.nodes (7 types) connected by sch.lanes (5 transport modes). sch.flows records every movement with type, quantity, and provenance. This is NovaTrade's physical topology.
Layer 2 - Value Chain. sch.stages defines the seven-stage process model. sch.artifacts are business objects with embedded state machines. sch.handoffs records every artifact transfer between stages.
Layer 3 - Agent Runtime. sch.agents with manifests, sch.fleets for group management, sch.pulses for heartbeat records. Every agent is a row.
Layer 4 - Event & Decision. sch.signals, sch.decisions, sch.traces (immutable - UPDATE and DELETE revoked at database level).
Layer 5 - Governance. sch.policies, sch.metrics, sch.postures, sch.objectives, sch.modes.
The total schema is 13 migration files. 15+ tables. Every table has explicit constraints, indexes, and triggers.
What This Changes For NovaTrade
Before the Helix, NovaTrade's agents were individually smart but collectively incoherent. The demand agent and procurement agent produced contradicting recommendations because they each had their own version of reality.
After the Helix, the same situation plays out differently. The demand sensing agent detects the APAC spike and loads the current state from the Helix - including the quality hold on Meridian Steel Works that the procurement agent already recorded. It sees the constraint. It factors it into the recommendation. Instead of "increase Shenzhen output" it recommends "increase output using alternative supplier Vanguard Materials, pending procurement review of Meridian quality resolution."
The procurement agent, running its own pulse moments later, sees the demand spike signal in the Helix alongside its own quality hold decision. It knows the context. It recommends "expedite Meridian quality audit; if unresolved within 48 hours, activate Vanguard Materials as secondary source."
Two agents. Same data. Complementary recommendations instead of contradictions. The Helix didn't make the agents smarter. It gave them the same reality to be smart about.
The Helix isn't primarily a technology concept. It's an operating model principle. The three flows - material, information, financial - are one system, and your organisation's ability to improve depends on treating them as one system.
What's Still Open
The Helix solves the "shared reality" problem. NovaTrade's agents operate on the same data, the same vocabulary, the same interpretation. That part works.
What I'm still working through is the temporal dimension. The Helix records what is - current state. It records what was decided - the trace chain. But it doesn't yet model what should have been. The counterfactual.
The other open question is cross-strand causality. When a financial flow anomaly should trigger a material flow response through an information flow mechanism - that causal chain crosses all three strands simultaneously. The schema supports it structurally. The agent logic doesn't reason about it yet.
In the next build logs, I'll walk through NovaTrade's operations stage by stage - starting with how fourteen agents actually make decisions and why you'd want to see every step of their reasoning. That's the Glass Box story.
Still building, Nerve Centre evolves and can`t wait getting to ability to measure end to end KPIs.
Build Log #3 - The Orchestrator Series. Next: the Glass Box - and why decision transparency is the product, not the feature.