GigAI: An Event-Driven Coordination Execution Layer for Construction Project Management

Team: Martina Simoni · Sumit Sudhir Shingne · Rafik El Khoury
Faculty: Marita Georganta & Akshay Madapura

Project managers spend more than half their time chasing information that no plan ever scheduled. We built GigAI to fill that gap — the coordination execution layer that sits between planning, analysis, and the actual act of getting people aligned.

The gap we set out to fill

We interviewed 15 project managers with 6–10 years of experience. The result was consistent: 60% spend more than four hours a week on coordination tasks — chasing missing information, manually updating tasks, interpreting fragmented updates — and 80% said they would adopt automation if they retained final decision authority.

Mapping the existing toolchain made the gap explicit. Excel tracks but does not coordinate. Primavera plans but does not execute. ACC centralizes information but does not streamline decisions. Motion AI optimizes individual tasks but ignores team complexity. Each tool occupies one of three layers — planning, analysis, or information centralization. None of them own the layer where coordination is actually executed: the event-driven middle layer that turns a planned intent into a concrete action under human authority.

System concept

GigAI detects new RFIs in Autodesk Construction Cloud, processes them through a dual-model AI pipeline, and distributes a complete proposal across multiple channels — email, dashboard, calendar, and a Revit plugin — while preserving a human review checkpoint before any action executes. The decision happens inside GigAI; execution happens inside the platforms PMs already use (ACC, Gmail, Calendar) via their respective APIs. This separation matters: it lets us automate the bridge between planning and doing without forcing PMs to abandon their tooling or accept opaque autonomous decisions.

Architecture

The backend is a long-running FastAPI service backed by PostgreSQL with the pgvector extension. We chose this stack after building and discarding an earlier Cloudflare Workers prototype that hit ceilings on WebSocket support, persistent token caching, and Sonnet-class CPU budgets. The migration to a long-running Python process gave us reliable OAuth token management, async-native LLM calls without timeouts, and a vector store for semantic retrieval over a knowledge folder of project glossary, team directory, rules, and historical patterns.

The processing pipeline is nine deterministic steps, end-to-end in 30.2 seconds for a single RFI:StepOperationTime4aACC RFI fetch1.2 s4bUser email lookup0.8 s4cClaude Haiku 4.5 — extraction (material, location, quantity, change type)1.8 s4dActionability check<0.1 s4eClaude Sonnet 4 — proposal generation (specs, cost, timeline, Revit families)23.1 s4fWeighted confidence scoring0.1 s4gGmail dispatch1.5 s4hPostgreSQL persistence0.2 s4iWebSocket broadcast to dashboard0.1 s

We use Haiku 4.5 for extraction and Sonnet 4 for generation because the two tasks have different cost/latency profiles. Haiku gives us reliable structured JSON for normalization at low cost; Sonnet handles the open-ended reasoning task of producing a construction-grade proposal — and notably, without explicit prompting, it consistently grounds proposals in Italian building standards (UNI EN, DM 26/06/2015) and produces cost estimates within market range (€780/unit against a €700–900 reference band). Embeddings for the knowledge folder use Voyage-3 (1024-dim), with HNSW indexes for cosine similarity search.

Confidence scoring is a weighted formula (data clarity 30%, historical match 25%, cost acceptability 25%, no red flags 20%) that produces a 0–100% score and a recommendation: accept (>80%), review (50–80%), reject (<50%). Proposals never auto-execute — every action requires a PM click.

Output surfaces

The same proposal lands in three places: the React dashboard receives a WebSocket push and renders the full proposal with confidence breakdown and approve/reject controls; an email summary with a deep link reaches the assigned stakeholder; and a C#/.NET 4.8 Revit 2026 plugin adds a “GigAI” ribbon tab where designers query proposals by RFI UUID and view specs, cost, and recommended Revit families inside their CAD environment — closing the loop between coordination and execution surface.

Validation

Against the demo scenario — a third-floor window substitution, aluminum to wood, 12 units — the four hypotheses held:

• Event-driven automation works. Nine-step pipeline, 30.2 s, 100% API success.
• LLM output matches PM-quality proposals. 75% confidence, valid Italian standards, market-realistic costs, valid Revit family identifiers.
• Human-in-the-loop preserves trust. PM review under 30 s on a clear approve/reject interface.
• Cross-platform integration is seamless. ACC → email → dashboard → Revit, no manual handoff.

End-to-end, the manual workflow (~45 minutes) collapses to ~3 minutes — proposal generation in two, approval in one.

What we are claiming

GigAI is not another planning tool or another analytics dashboard. It is a working prototype of a coordination execution layer — the missing fourth category between planning, analysis, and information centralization. The architecture is production-ready; the validation is bounded; the human-in-the-loop is non-negotiable.

GigAI · IAAC Research Studio 2026 · Martina Simoni, Sumit Sudhir Shingne, Rafik El Khoury
Faculty: Marita Georganta & Akshay Madapura