Wacky Wheels Control Tower

Inspiration

Wacky Wheels keeps no spare parts. Every part arrives just in time, so one late truck stops a production line, and a stopped line breaks promises to customers, dealers and loaner pools all at once. What struck us was how these problems actually arrive: not as clean records, but as a one-line chat message, a morning digest with two problems in it, or a vague rumor from a supplier rep.

We wanted to know if AI agents could handle that mess without being trusted to guess. If an AI moves the wrong order or forgets a dealer, real customers pay for it. So we built the whole project around one rule: the LLM reads, code decides.

What it does

The Wacky Wheels Control Tower takes in disruption messages (supplier emails, plant alerts, ops chat, quality bulletins, news) and turns each one into the exact set of enterprise actions the 10-rule policy handbook requires:

Supplier delays and plant outages: find every affected production order, move it to the earliest free slot, or transfer it to another plant that builds the same model.
Dealers: exactly one notification per dealer per event, listing only their affected orders.
Customers: loaners for Platinum, then Gold, then the earliest promise date, until the pool runs out.
Quality holds: find the lot, stop the sale of unsold cars, and contact owners who already bought one.
Noise gets zero actions. Rumors get exactly one escalation to a human, with a note saying what's missing.

On the 15 official events: 11 incidents handled, 2 escalated, 3 ignored, 766 write actions, 0 failed calls, and 15/15 events passing an independent self-check. The whole run used 15 LLM calls and 19,416 tokens on a small local model.

How we built it

Eight agents, one pipeline:

LLM reader: qwen2.5:3b-instruct, running locally through Ollama. It only copies phrases out of the message ("Huntsville", "battery packs", "Mar 29"). It never picks an action.
Resolver and gate (code): match those phrases to real records in a knowledge graph built with networkx from the company data (17,090 nodes, 28,301 edges, 13 node types), then decide: incident, noise or unconfirmed.
Coordinator: splits compound messages and routes each incident.
Three specialists: a Supply Chain Planner, a Dealer Network agent, and a Customer Care and Quality agent.
Verifier and Digital Twin: check the plan against every handbook rule, then dry-run it on a copy of the world.
Enterprise Gate: the only component allowed to write. It reads every result back to confirm it landed.

The rules are precise. For a supplier delay, an order is affected only if it is built at the receiving plant inside the delay window:

$$\text{affected} = {\, o \;:\; \text{plant}(o) = p,\ \ t_{\text{orig}} \le \text{date}(o) < t_{\text{new}},\ \ \text{part} \in \text{BOM}(\text{model}(o)) \,}$$

That last condition matters. In E-10, six other Huntsville builds in the window are left alone because their models don't use the delayed battery pack.

On top of the engine we built a Streamlit control room: an event feed with a summary and reason for every event, the graph evidence path behind each decision, a filterable audit trail, a human review inbox, a Live Incident Desk for brand new messages, What-if scenarios, a Policy Studio where managers edit rules (the scored baseline stays locked), and Agent World, a live map of the agents replaying the run.

Challenges we ran into

Ambiguous dates. "Next Friday" can mean two different days. Instead of letting the model guess, we made every interpretation an explicit, visible switch a manager can change.
A small model that over-explains. The 3B model sometimes justified its answer with words that weren't in the message. We added a grounding check that throws away any explanation not supported by the message, so decisions always come from code.
Compound events. One digest held both a plant outage and a supplier delay. Both incidents had to share one slot ledger and one loaner pool so nothing was promised twice, and each dealer still had to get just one combined message.
Exact counts. The scorer replays the action log, so one extra notification is as wrong as a missing one. Loaner pools run out, slots fill up, and transfers have to respect restart dates.
Trusting our own results. Passing our own tests proves little, so we wrote a separate, bare-bones implementation of the handbook and replayed our action log against it.

Accomplishments that we're proud of

15/15 events matching an independent recalculation, with zero failed calls.
Every action traces back to a rule and a graph path.
It handles messages it has never seen, and when information is missing it asks a person instead of guessing.
It runs entirely on a laptop: no cloud, no cost per message.

What we learned

The safest place for an LLM in operations is at the edge, reading. Narrowing the model's job made the system more accurate, cheaper and much easier to explain. We also learned that explainability has to be designed in: if every decision carries its rule and its evidence path, the audit trail and the reasoning come for free.