ConstructIQ — AI Supply Chain Brain

Not a chatbot. A workforce of AI agents that reads your emails, tracks every shipment, predicts delays weeks early, and acts before you incur heavy contractual penalties.

Comment

Inspiration

Every week, somewhere on a construction site, a project manager gets a call they were dreading: the steel didn't arrive. The concrete pour is off. Three trades are standing idle at ₹8,000 per hour each. And the worst part? The tracking email had been sitting in the inbox for four days.

We kept asking: why does a $11 trillion industry — one of the most complex logistical operations humanity runs at scale — still manage its supply chain through email threads, phone calls, and Excel spreadsheets?

The data exists. Every Purchase Order, every invoice, every tracking notification, every delivery confirmation is already in the system somewhere. Nobody has built the intelligence layer to connect it all.

That's what inspired ConstructIQ.

What We Built

ConstructIQ is a multi-agent AI system — a workforce of specialist AI agents working 24/7 on your construction supply chain.

It connects to your real Gmail or Outlook inbox. When a tracking email arrives, it reads it, extracts the tracking ID, identifies the carrier, opens the tracking system, and retrieves live status — before you've even seen the email. If the delivery is running late, it calculates the cascade impact on your project schedule, estimates the cost in rupees, drafts a vendor escalation email, and asks you to press one button.

The system is built on four major agents:

  • 📄 Document Intelligence Agent — reads every email, PDF, invoice, and PO using Google Gemini Vision. Extracts structured data, detects discrepancies between POs and invoices, and routes attachments automatically.
  • 🚚 Shipment Tracker — detects tracking IDs in emails, identifies the carrier from 900+ global options via AfterShip API, and retrieves live shipment location and ETA. Playwright browser automation serves as fallback for carriers without APIs.
  • 📊 Forecasting Agent — an XGBoost + LSTM ensemble predicts delivery delay probability for every active order, with SHAP-powered plain-English explanations. Prophet handles seasonal trend analysis. NetworkX propagates delay impact through the project dependency graph, calculating downstream schedule and cost effects. The system improves over time through a self-correcting learning loop.
  • 🚨 Monitoring & Action Agent — watches every order, maintains a real-time health score (0–100, built from five traceable signals), fires prioritised alerts across dashboard, email, WhatsApp, and SMS, and drafts vendor communications for PM approval.

The Orchestrator agent runs the entire system via a LangGraph stateful graph — routing events, running agents in parallel, synthesising outputs, and applying a confidence-based action system that keeps the PM informed without overwhelming them.

How We Built It

Agent Framework

We chose LangGraph for its stateful multi-agent graph architecture. Unlike simpler frameworks, LangGraph lets us define explicit state transitions, run agents in parallel branches, and implement human-in-the-loop interrupts natively — essential for the PM approval flows.

LLM Strategy

We use two LLMs for different jobs:

  • Google Gemini 1.5 Flash for all multimodal tasks — reading PDFs, images, email attachments, and scanned documents.
  • Groq (Llama 3.1 70B) for all fast text-only tasks — intent classification, alert drafting, SHAP explanation writing — because it's the fastest free inference available.

ML Forecasting Stack

  • XGBoost on tabular features (vendor history, material category, season, order size, vendor load) with SHAP for explainability.
  • PyTorch LSTM on sequential vendor delivery history to detect temporal patterns.
  • Ensemble: auto-weighted combination where LSTM weight increases as vendor history grows.
  • Prophet for seasonal decomposition and material price forecasting.
  • Isolation Forest for anomaly detection on vendor behavior and PO prices.

Institutional Memory

Every vendor and material gets a living intelligence profile stored in ChromaDB (vector search) + SQLite (structured queries). The system RAG-retrieves vendor context before every prediction, enriching the model with company-specific knowledge that no public dataset contains.

Confidence Engine

The Orchestrator scores its certainty before acting:

  • >85%: acts + sends PM a dismissible FYI toast with 60-second undo.
  • 60–85%: soft approval card — PM approves with one tap.
  • <60%: direct multiple-choice question — PM's answer is logged and the same question is never asked again.

Data

Since we don't have access to a company's live data, we combined:

  • Public Kaggle construction datasets for historical delivery records.
  • 50+ Gemini-generated synthetic POs, invoices, and delivery receipts.
  • 20+ hand-crafted tracking email scenarios.
  • BLS Construction Material Price Index for price forecasting.
  • A generated 6-month Gantt schedule with 3 material tracks and 20+ milestones.

Challenges We Faced

  • Carrier identification at scale — matching a tracking number to the right carrier from 900+ options is non-trivial. We built a rule-based lookup table (number format patterns per carrier) with an LLM fallback, and AfterShip as the unified resolution layer.
  • Making the health score meaningful — early versions of the health score were just averages of averages. We scrapped it and rebuilt it as a formula-driven composite where every point change traces back to a specific order, vendor, or document. The constraint: the score cannot move without a real, identifiable cause.
  • Confidence calibration — determining when the AI should act vs ask was harder than expected. We had to build in stakes-based penalties (high ₹ impact → lower confidence, require approval) and familiarity bonuses (seen this pattern 10+ times → higher confidence).
  • Cascade propagation accuracy — a delay doesn't always propagate linearly. Parallel workstreams absorb some delay. We had to model this with weighted DAG traversal to avoid overstating impact (which would destroy PM trust in the system).

What We Learned

The hardest problem in agentic AI is not building agents that act — it's building agents that act at the right time, with the right confidence, in a way that builds rather than erodes human trust.

The confidence engine and the Internal Trust Engine (where the AI privately tracks its own mistakes) were the most important architectural decisions we made. An AI that admits uncertainty to itself while remaining confident to the user is far more useful than one that either never acts or always acts.

We also learned that institutional memory is the real product. The first month of ConstructIQ is useful. The sixth month is transformative — because by then, the system knows things about your vendors that you forgot you knew.

What's Next

  • Phase 1 (Months 1–2): Pilot with a real construction company — connect live Gmail/Outlook, ingest historical PO and delivery data, establish baseline predictions.
  • Phase 2 (Months 3–4): Forecasting model retraining on real data, cascade model calibrated to actual project schedules.
  • Phase 3 (Months 5–6): Institutional Memory is the moat — vendor trust scores become the company's proprietary dataset.
  • Phase 4 (Month 6+): Multi-project dashboard — compare supply chain health across projects, identify systemic vendor issues, benchmark against industry baselines.

Built With

Share this project:

Updates

Submission history