Jasper reads every drawing, spec, and legal document once, then drafts cited RFI, submittal, and bid replies, and loops in the architect when the GC needs answers only they can give.

Project Story

About the project

Jasper is an AI agent that lives inside a Procurement Manager's inbox. It reads a project's entire document set once: drawings, specs, legal paperwork, all of it. Then it builds an index it can cite by page. From there it sits inside the real communication loop, drafting and sending RFI, submittal, and bid responses to the GC, and reaching out to the architect on the PM's behalf when a question needs input only the design team can give. Every reply is grounded in a document that was actually read, not guessed at.

What inspired us

We started from Kaya AI's own framing of the procurement track. Frontier models still can't reliably reason across a single 500-page construction document set, let alone the hundreds that make up one project. And that's exactly the reading and cross-referencing work a Procurement Manager does all day, buried under RFIs, submittals, and bid packages that all point back to the same underlying documents from different angles. The inspiration wasn't "add AI to procurement software." It was noticing how much of a PM's week goes into lookup work that a well-indexed system should never need a human for, and how invisible that work is until you actually trace one RFI back through a 300-page spec book by hand.

What we learned

The biggest lesson was how much groundwork it takes just to state the problem correctly. We spent real time researching the actual construction procurement pipeline: AIA contract structure, CSI MasterFormat, submittal registers, the RFI and addendum cycle, before we could confidently say where in that pipeline our agent should even sit. That scoping question moved more than once as we dug deeper, and each move taught us something. We first landed on the GC's post-award loop, subs and submittals. Then we realized the more coherent story was the Procurement Manager as the coordination layer between the GC and the architect, active from bid solicitation all the way through closeout. Not two separate products. One agent with two relationships to manage.

We also learned to be honest about the competitive landscape instead of assuming a gap exists just because it would be convenient. Midway through, researching bid leveling led us to discover that Procore already ships real generative AI: a document Q&A copilot that cites its sources, an RFI-drafting agent. That meant an earlier claim we'd been leaning on, that incumbents just log documents and don't understand them, was no longer true and had to be walked back. Finding that out mid-build stung a little, but it was useful. It forced our differentiation down to specifics that actually hold up: Procore's leveling only compares bids typed into its own structured form fields, while Jasper reads a sub's or GC's actual free-text proposal and checks it against real spec compliance. Procore's copilot is English-only and built around US terminology, while Jasper is meant to work across different regional document standards, starting with the US, Singapore, and Japan. Specific claims like that survive a technical judge's first question. Broad ones don't.

How we built it

We treated this as a research-first build. Before writing any architecture, we grounded every claim in something checkable: real GitHub repositories for agent orchestration patterns, real papers and open-source projects for large-document retrieval with traceable citations, and real production examples of agents handling continuous email threads with tiered autonomy. Draft freely for low-stakes replies, but never auto-send anything with legal or financial weight without a human in the loop. That last rule became the core design principle for the whole communication layer, not an afterthought. Jasper prepares, the PM decides, and every message it sends discloses that it's an AI acting on the PM's behalf.

The architecture ended up as a layered pipeline: document ingestion and structural indexing, a retrieval layer built for page-level citation instead of approximate similarity, a drafting layer for RFP, RFI, and submittal content, and a communication layer that treats every RFI, submittal, and bid response as a tracked object with its own deadline instead of just another email thread. Each layer got checked against a real, named precedent before we trusted it, and we revised more than once as our own understanding of the underlying construction process got deeper.

Challenges we faced

The hardest challenge wasn't technical. It was staying honest about scope as our own understanding of the problem sharpened. More than once we caught ourselves building on top of an assumption we hadn't actually checked: who the "Procurement Manager" really was, which bidding process we meant, whether a competitor gap was real or just something we hadn't looked into closely enough. Each time, we went back and fixed the earlier work instead of letting the inconsistency sit in the pitch.

The other honest challenge is technical, and we're not going to pretend it's solved. Our research precedents prove out traceable retrieval well on text-heavy documents like contracts and specs. Construction planning sets are drawing-heavy. Reliably reasoning over architectural and structural drawings at the fidelity this product promises is a genuinely open problem. It's something we're building toward, not something we've already cracked.

Built With

• chromadb
• claude
• express.js
• gemini
• langchain
• langgraph
• next.js
• node.js
• nodemailer
• ollama
• pinecone
• postgresql
• prisma
• react
• rest-api
• supabase
• tailwind-css
• typescript
• webrtc
• websockets
• zod