From Open-Source Multi-Agent Control Tower to Governed Supply Chain Decision App

Why this tutorial matters

Vishal Vishwakarma’s open-source project, described in his Medium article Building a Multi-Agent AI Control Tower for Supply Chain Root-Cause Analysis, is a useful reference architecture for teams exploring Supply Chain Control Tower, Multi-Agent AI and Root-Cause Analysis use cases.

The original project is not presented here as a Dataleo product. It is credited to Vishal Vishwakarma and his public GitHub repository. Dataleo’s contribution is an analytical tutorial layer: what this architecture teaches, where it is promising, and what risks would need to be addressed before using a similar pattern in a real operating environment.

What the original project demonstrates

The project shows how a local multi-agent system can connect several operational domains that are usually investigated separately: shipping, inventory, purchase orders, freight and warehouse execution. According to the article and repository, the reference implementation uses 9 agents, 49 tools, Python, SQLite, FastMCP, Streamlit and Claude Desktop through MCP.

The most interesting design choice is not the chatbot interface. It is the separation of operational domains into scoped agents, combined with an investigation layer and a continuous-improvement layer. This creates a pattern that is closer to a Decision App than a generic dashboard.

The operational problem

In many supply chain teams, delayed orders are reviewed manually across ERP screens, freight portals, spreadsheets and warehouse reports. Dashboards show symptoms, but they rarely explain the cross-domain cause. A delay may appear as a freight issue while the real driver is an overdue inbound purchase order that created a stockout before freight became relevant.

The control tower pattern explored by Vishal’s project addresses this gap by asking a more operational question: which orders need action, what is the likely root cause, what evidence supports that diagnosis, and which team owns the next step?

Dataleo interpretation

Dataleo reads this project as an early example of a governed middle-layer pattern for Supply Chain Planning and exception management. It does not replace ERP, WMS, TMS, APS or BI platforms. Instead, it shows how AI agents can sit between operational data and human decision-making to structure diagnosis, prioritization and follow-up.

The value is strongest when the system remains decision-specific. The question is not “Can we build an AI control tower?” The better question is: which recurring decision is being improved, what data is required, who owns the logic, and what happens when the recommendation is wrong?

Architecture pattern

• Operational agents: domain-specific agents for shipping, inventory, purchase orders, freight and warehouse data.
• Investigation layer: a reasoning layer that assembles cross-domain evidence and produces a root-cause hypothesis.
• Recommendation layer: priority scoring, owner assignment and recommended next actions.
• Continuous-improvement layer: pattern detection, human approval, outcome tracking and rule-based learning.
• User interface: a Streamlit dashboard for operational visibility, alongside Claude Desktop as the MCP interface.

How to use this as a tutorial

A supply chain or IT team can use Vishal’s project as a learning reference, not as a production shortcut. The recommended tutorial approach is to reproduce the architecture with sample data first, then evaluate whether the pattern improves a real operational workflow.

• Start with one decision: for example, “Why is this order late and who should act?”
• Map the data needed from shipping, inventory, purchase orders, freight and warehouse operations.
• Define one agent per operational domain with read-only tools.
• Create an investigation function that assembles evidence before producing a root-cause conclusion.
• Add transparent priority scoring that planners can inspect and challenge.
• Require human approval before any recommendation becomes an action.
• Measure whether accepted recommendations actually reduce delays or improve service performance.

Risks perceived by Dataleo

The main risk is mistaking a working local prototype for an enterprise-ready control tower. The Medium article is explicit that the current implementation uses sample data, a local SQLite database and is not connected to live ERP, WMS, TMS, supplier or carrier systems. It also states that role-based access control, production monitoring, alerting and real-world validation are outside the current scope.

• Data risk: bad, incomplete or stale operational data can produce confident but wrong root-cause explanations.
• Governance risk: without clear ownership, agents may encode business rules that no process owner has validated.
• Security risk: the article describes input validation and output shielding, while the GitHub README also lists prompt injection protection, schema validation and LLM output validation as future work. This gap should be resolved before any production deployment.
• Decision risk: a recommendation may assign the wrong owner, understate urgency or over-prioritize noisy exceptions.
• Shadow IT risk: local AI-built tools can become operationally important before IT, Security and Data Governance have reviewed them.
• Auditability risk: every score, rule change, owner assignment and rejected recommendation needs traceability.
• Integration risk: connecting agents directly to ERP, APS, WMS or TMS without a controlled integration pattern can create operational and compliance exposure.

Governance box

• Data source: start with sample data or controlled extracts from ERP, WMS, TMS and freight systems.
• Process owner: Supply Chain Operations or Planning, not only IT or Data Science.
• Logic owner: named owner for delay rules, priority scoring, escalation thresholds and ownership rules.
• Validation: compare agent diagnosis against historical incidents reviewed by experienced planners and operations managers.
• Version control: store prompts, MCP tool definitions, scoring rules and data schemas in Git.
• Access: read-only by default; role-based access required before live operational data is connected.
• Human override: users must be able to reject, edit or reassign every recommendation.
• Failure mode: wrong root cause, wrong owner, missing data, prompt injection, false confidence or unvalidated scoring logic.

Dataleo recommendation

This type of project is valuable as a controlled prototype for AI Governance, Decision Architecture and Planning Governance. It should be evaluated as a learning architecture before becoming an operational system.

The right next step is not to add more agents. It is to test whether the system improves one recurring decision with measurable results: fewer late orders, faster root-cause diagnosis, better ownership, fewer repeated issues or improved service recovery. Only then should teams decide whether to keep it as a governed lightweight layer or industrialize it into APS, ERP, BI or workflow platforms.

Original source and attribution

This tutorial is based on Vishal Vishwakarma’s public article and repository. Original article: Building a Multi-Agent AI Control Tower for Supply Chain Root-Cause Analysis. GitHub repository: vishal2559/supply-chain-control-tower.