/ Context
A Procurement team fielded a high volume of repetitive questions whose answers already existed in trusted enterprise documents. The assistant had to be something the team could rely on operationally, which put grounding and supportability ahead of conversational polish.
/ Role & decision scope
- Designed the assistant architecture and productionised it.
- Selected the platform and components: Azure AI Foundry, LangGraph, ChatKit, PGVector and MCP server integrations.
- Made grounding in trusted enterprise documents the defining requirement.
- Standardised the architecture into a reusable reference implementation.
/ Constraints
- Answers have to be grounded in trusted enterprise documents.
- The assistant had to be productionised, not demonstrated.
- It needed to be supportable in day-to-day operational use.
- The architecture had to be reusable beyond Procurement.
/ Architecture & key decisions
- D01
Azure AI Foundry as the delivery platform
The assistant was built and productionised on Azure AI Foundry, giving one platform for delivery rather than assembling a bespoke stack.
- D02
LangGraph for orchestration
LangGraph handles the orchestration between retrieval, reasoning and tool use, keeping the assistant's flow an explicit part of the architecture.
- D03
PGVector for retrieval
Retrieval runs on PGVector over the trusted enterprise document set that grounds the assistant's answers.
- D04
MCP server integrations and ChatKit
Integrations with MCP servers provide the assistant's access to enterprise systems, with ChatKit as the interface layer.
- D05
Generalised into a reference implementation
Rather than remaining a Procurement-specific build, the architecture was standardised as a reusable reference implementation for other assistants.
/ Trade-offs
- Answer coverage versus grounding discipline
- The assistant answers from trusted enterprise documents; grounding was a design priority, so coverage follows the trusted content rather than the model's recall.
- Bespoke fit versus reusability
- Procurement's content and configuration stay specific while the orchestration, retrieval and integration architecture was standardised into a reference implementation.
- Demonstrable versus supportable
- Design focus: supportability in day-to-day operational use, which is what productionising the assistant — rather than shipping a prototype — was intended to deliver.
/ Evidence & outcomes
- Measured
- Reduced inbound procurement support queries by 60%
- Artifact
- Production Procurement assistant on Azure AI Foundry, LangGraph, ChatKit, PGVector and MCP server integrations
- Artifact
- Reusable reference implementation standardised from the assistant architecture
- Decision
- Grounding in trusted enterprise documents as the defining design constraint