Foundry — About the Project

Inspiration

On almost every construction project, three teams make decisions that should be one conversation and aren't. The structural engineer designs and validates a model for safety. Procurement sources materials to hit a budget. Scheduling tracks a critical path. In practice, these three run in silos — BOQs get manually re-typed from PDFs into spreadsheets, material substitutions get made on cost alone without anyone re-checking the structural math, and vendor lead times only surface after an order is placed, when it's too late to change course.

We kept coming back to one question: what if the procurement decision never had to leave the structural model at all? Bentley's openstaad-mcp — an official MCP server exposing live OpenSTAAD API access — made that question answerable. If an AI agent could reach directly into a running STAAD.Pro session, read ground-truth quantities, and re-validate every alternative against the real analysis engine before it was ever proposed, procurement stops being a guess and becomes something closer to a second, cost-and-schedule-aware design pass — one that never gets to suggest something structurally unsafe in the first place.

That idea — a structural validity oracle sitting underneath every procurement decision — is Foundry.

What it does

Foundry connects a live, already-validated STAAD.Pro structural model to a ranked, cost- and schedule-optimized procurement plan, through four cooperating agents:

Design Optimization Agent — pulls the live bill of quantities straight from the running STAAD.Pro session (not a manual takeoff), generates alternative sections and grades from IS 808/456/1786 reference tables, and swaps each candidate into the actual model to re-run analysis. Only candidates that pass utilization, deflection, and code-compliance checks survive.
Sourcing Agent — matches every structurally-feasible candidate to vendor SKUs, compares price and lead time across suppliers, checks stock, and drafts ready-to-send RFQs.
Scheduling Agent — runs Critical Path Method analysis over the construction schedule to determine the latest safe order date per material, and flags any vendor whose lead time would miss it.
Orchestrator — combines structural margin, cost, and schedule fit into one ranked recommendation with a plain-language justification generated only from the structured data the other three agents already computed — never free-associated.

The output is a procurement roadmap: what to order, from whom, at what price, and by when — with every number traceable back to a specific STAAD analysis result, sourcing record, or schedule computation.

How we built it

The system is deliberately MCP-native end to end, not a single LLM call wrapped in a chat UI:

Structural layer: openstaad-mcp (Bentley's official server) exposes execute_code, an AST-sandboxed surface for running whitelisted OpenSTAAD COM calls — GetBeamList, GetNodeCoordinates, GetMemberProperty/SetMemberProperty, PerformAnalysis — against a live, running STAAD.Pro session. We use this to extract geometry, swap candidate properties, re-trigger analysis, and read back design results. Candidate generation is rule-based, not brute-force: only sections within a bounded range of current demand are tested, which keeps the search space small enough that re-analysis latency stays workable.
Orchestration: Claude, via the Anthropic API, drives the pipeline using MCP tool-calling — invoking the Design, Sourcing, and Scheduling agents as callable tools and generating the final grounded justification from structured decision data.
Sourcing layer: a relational schema (vendor_id, sku, spec, grade, unit_price, region, lead_time_days, stock_status) in SQLite, with rapidfuzz handling fuzzy matching between STAAD-derived spec strings (e.g. ISMB350) and inconsistently-named vendor catalog entries. Benchmark pricing is anchored to real public reference data — the Joint Plant Committee's steel price index and the Cement Manufacturers' Association's cement pricing — so the numbers in our demo dataset sit inside realistic ranges even where individual vendor listings are illustrative.
Scheduling layer: Python's networkx builds the task-dependency graph from the construction schedule and runs forward/backward passes to compute float per task, which feeds directly into the lead-time feasibility check.
Backend/frontend: FastAPI coordinates the four agents; the dashboard prototype (HTML/CSS/JS) renders live BOQ extraction, the candidate re-validation log, vendor comparison, and the recommendation and critical-path views.
Local/cloud split: because STAAD.Pro is Windows-only and must run locally with a licensed instance, openstaad-mcp's HTTP transport mode with bearer-token auth lets the Windows machine running STAAD stay local while the Sourcing, Scheduling, and Orchestrator agents run in the cloud and connect to it securely.

Challenges we ran into

Mapping the sandboxed API surface. execute_code runs AST-validated Python — imports, file access, and dangerous builtins are blocked by design. Figuring out exactly which OpenSTAAD calls were reachable inside that sandbox, and writing candidate-swap logic entirely within it, took real trial and error rather than being something we could assume up front.
Keeping re-analysis fast enough to be interactive. Every candidate swap means a real STAAD re-analysis, and that has real latency that scales with model size. We had to move from "test everything" to a bounded, rule-based candidate pool (roughly ±25% of current utilization-implied capacity) to keep the loop fast enough for a live demo, and leaned on openstaad-mcp's multi-instance support to parallelize testing across sessions.
Reconciling messy real-world spec naming. STAAD outputs clean section codes; vendor catalogs don't agree with each other or with STAAD on naming conventions. Fuzzy matching got us through the hackathon, but it's clearly a place where an embedding-based matcher will earn its keep as catalog data gets messier.
Being honest about what's live vs. simulated, without pretending otherwise. Real-time vendor pricing and stock APIs aren't something a small team can wire up in a few days, and vendor catalog access at scale needs partnership agreements we don't have yet. Rather than fake a live integration, we built a structured sourcing dataset calibrated to real JPC/CMA benchmark pricing, and kept the schema identical to what a real vendor feed would produce — so swapping in live data later is a data-source change, not an architecture change.
Grounding the AI-generated justification. It was tempting to let the recommendation-explanation step free-associate over the whole pipeline's output. We deliberately constrained it to a prompt template fed only the already-computed structured numbers, so every claim in the justification text is traceable to a real computation rather than something the model invented to sound persuasive.

Accomplishments that we're proud of

A genuine multi-agent, MCP-native architecture — four agents with distinct responsibilities, coordinated through real tool-calling, not a single prompt pretending to be a pipeline.
A structural re-validation loop that actually swaps properties into a live STAAD.Pro model and reads back real design results, rather than approximating structural feasibility with a lookup table.
End-to-end traceability: every number the Orchestrator surfaces — cost, structural margin, lead time — can be traced back to a specific analysis run, sourcing record, or schedule computation.

What we learned

MCP tool-calling is a genuinely strong fit for multi-agent engineering workflows — the "structural validity oracle" pattern (re-test every candidate against ground truth before recommending it) generalizes well beyond this specific use case.
Being explicit about what's real versus representative-at-MVP-stage isn't a weakness to hide — it's a credibility signal. Naming the exact data sources and the exact path from mock to production made the system easier to explain and reason about, not harder.
Constraining an LLM's explanatory output to only the data a deterministic pipeline already computed is a small design choice with an outsized effect on trustworthiness — especially for a tool making recommendations with real money and real safety margins attached.

What's next for Foundry

Live vendor API integrations and IndiaMART/TradeIndia partner onboarding, replacing the benchmark-calibrated sourcing dataset with real-time pricing and stock.
Direct ingestion of MS Project (.mpp) and Primavera P6 (.xer) schedule exports, so the Scheduling Agent runs against a project's actual live schedule rather than a simplified import.
Support for structural analysis engines beyond STAAD.Pro, so Foundry isn't locked to a single vendor's ecosystem.
Historical vendor performance learning (on-time delivery rate, price volatility) feeding into ranking as a first-class signal rather than a stretch feature.
ERP/procurement system integration for one-click RFQ issuance, once a human has reviewed and accepted a recommendation.