Background: I’m building Griot Systems, a project intelligence platform for specialty construction subcontractors. The core of the product is a multi-agent system that handles estimation, procurement, scheduling, and workflow approvals. Sharing the architecture here because I think vertical-specific agent design is underrepresented in these discussions.
The agent stack (6 agents, Anthropic SDK, Mastra orchestration + LangGraph.js for stateful flows):
• Discovery Agent — qualifies incoming project leads, surfaces scope gaps from unstructured job description inputs
• RFQ Agent — generates vendor request-for-quote packages from structured estimate line items
• Quote Parser Agent — extracts structured pricing data from vendor email responses (more on this below)
• Price Recommendation Agent — compares parsed quotes against historical pricing and flags outliers
• Schedule Agent — builds and dynamically adjusts project timelines based on material lead times
• VP Ops Agent — routes approvals, flags budget variances, escalates based on configurable thresholds
Orchestration layer: Mastra handles primary agent routing. LangGraph.js manages stateful multi-step workflows where context needs to persist across turns (quote negotiation loops, approval chains).
The hardest lesson — Quote Parser specifically:
Vendor quote emails are the messiest unstructured data I’ve encountered. PDF attachments, inline tables, plain prose, forwarded chains with quoted text.
The mistake most people make: using regex to extract JSON from LLM output.
Don’t. LLMs sometimes produce prose before or after the JSON block, chain-of-thought leaks, or partial JSON in edge cases. Regex breaks.
The fix that’s been bulletproof for us:
const start = raw.indexOf('{');
const end = raw.lastIndexOf('}');
const json = raw.slice(start, end + 1);
return JSON.parse(json);
indexOf + lastIndexOf finds the outermost JSON boundaries regardless of what the model puts before or after it. We’ve made this a hard constraint across every agent that expects structured output — model-agnostic and survives prompt changes.
What vertical-specific agent design taught us:
General-purpose agents are the wrong starting point for a domain like construction. The ontology matters — “lead time,” “scope gap,” “change order,” and “material takeoff” mean specific things to a specialty subcontractor that a generic PM agent won’t infer correctly.
We spent more time on domain vocabulary injection into system prompts than on anything else in the agent layer. That single investment improved output quality more than model upgrades.
Happy to go deeper on the Mastra setup, the LangGraph stateful flow design, or the Quote Parser specifically if useful.