Project / R&D and proof of concept
AI agents, retrieval and document ingestion
R&D and proof-of-concept work behind the conversational layer: agents, retrieval and document ingestion built around real business data. The aim was to prove use cases far enough for client commitment. Commercial focus moved to Copilot readiness assessments, so most of this remained at proven-prototype rather than production.
- Status
- R&D and proof of concept; maturity stated per item
- Group
- Internal R&D and client PoC
- Stack
- Azure AI Foundry, Azure AI Search, App Service, Entra ID, Copilot Studio, Power Automate, Dataverse, Microsoft Teams, SharePoint Agents, Azure SQL, OCR and form recognition
- Repo
- Previous employer, private
What was actually used
Azure AI policy assistant: internal use
Retrieval-augmented generation over internal policy PDFs and Word documents, returning grounded answers with citations. It used Microsoft’s get-started-with-ai-chat reference sample on App Service with Azure AI Foundry and Azure AI Search, rather than a bespoke front end, and was secured behind Entra sign-in.
This is the one item that crossed from prototype into day-to-day use. The compliance team used it regularly on the internal tenant.
Honest limitation: an indexing-capacity and re-ingestion constraint surfaced as the content set grew. It was diagnosed but not resolved before the work was parked behind other priorities. The internal host was Entra-gated, was never publicly testable by design, and has since been retired.
What was demonstrated to a client
Insurance form ingestion using OCR: proof of concept
Built and demonstrated to a prospective insurance-brokerage client using its own submission forms as ingestion samples. Recognition was tuned to the client’s real document types and layouts, which is the part that determines whether extraction holds up outside a controlled demo.
The work proved the extraction path on genuine documents. The engagement did not convert to a paid build.
What was built and tested internally
Three agents
- Car park booking agent: a Copilot Studio agent handling booking intake and lookups.
- Products and services agent: a Copilot Studio agent tested through the chat surface for product and service queries.
- SharePoint policy variant: a SharePoint-native version of the policy assistant, built to compare a SharePoint Agent with the Azure AI Foundry route on the same governed content. It also tested how permissions, content scope, document quality and information architecture changed the answers.
The common pattern across the intake and retrieval agents was Power Automate querying business data, creating and updating Dataverse records, and returning results through Microsoft Teams.
ConnectWise natural-language ticket retrieval: prototype
A prototype over a mirrored ConnectWise dataset in Azure SQL, allowing tickets to be queried in natural language. The connector and pagination groundwork is documented in the ConnectWise to SharePoint Sync project.
Why this sits at prototype, not production
The recurring point across these builds is that the hard part of an agent is rarely the conversation. It is the governed data, permissions and actions underneath it. This is the same ground as the Copilot Readiness Assessments and the Resident Records and Permissions Automation work: an agent is only as safe as the data layer it sits on.
The R&D deliberately targeted that layer so a build could be handed to a client safely. It stopped short of production because the readiness-assessment line was commercially prioritised, not because of a technical ceiling.
Bottom line: strong R&D depth, one internally used system, one client-facing PoC on real documents, three agents built and tested, and a clear view of where the governance layer decides whether an agent is safe to ship.