How Dunaway Built an AI Agent That Answers Regulatory Questions Live, in the Meeting
A Texas engineering firm saved 10,000 hours a year by replacing manual document searches with a Copilot Studio agent. Here's exactly what they built, how the architecture works, and why their engineers now answer client questions they used to defer.
There's a specific kind of meeting that every engineering firm dreads. A client asks about a code requirement mid-session. The engineer knows the answer is somewhere in a 2,000-page city manual — but finding it takes hours, not seconds. So they say the thing no one wants to say: "We'll look into that and get back to you." Dunaway, a Texas engineering firm operating across more than 100 cities, fixed that. They built an AI agent called Atlas that their engineers now query live in client meetings. This is how they did it.
1. The Problem: 10,000 Hours a Year in the Wrong Kind of Work

The context: Dunaway operates across more than 100 Texas cities, delivering civil and structural engineering projects. Each city, county, and state maintains its own regulatory documents — code manuals that run from 100 to over 3,000 pages, updated frequently, scattered across government websites and outdated PDFs. Before Atlas, engineers spent more than 10,000 hours every year manually searching these documents to verify compliance requirements.
The concept: Think of it like asking every engineer to become a part-time librarian. The actual skill — engineering judgement, design quality, client work — sits idle while the expert hunts through page 847 of a PDF, trying to verify whether a drainage requirement changed since the last project. The work is necessary. But it requires no expertise. It's just search.
The problem: The cost wasn't just time. Manual document hunting introduced risk. Engineers worked across several manuals simultaneously, cross-checking requirements without a central reference point. Inconsistent formatting and scattered sources meant the same question could take different amounts of time to answer on different days. Mistakes — missed requirements or outdated code references — translated directly into costly redesigns and project delays for both Dunaway and its clients.
The pattern: The 10,000-hour number is precise because Dunaway measured it. Before building anything, they knew exactly what the problem cost them. That specificity shaped what they built: not a general-purpose chatbot, but a purpose-built agent for regulatory research, with the accuracy and citation quality that professional compliance work requires.
2. What They Built: The Architecture That Makes It Work

The context: Atlas is a Microsoft Copilot Studio agent deployed in Microsoft Teams, backed by a SharePoint document store and an Azure AI Search index. The team built it using tools most Microsoft organisations already have access to — the complexity is in how they connected them, not in the components themselves.
The concept: The architecture works in three layers. First, a knowledge pipeline: subject matter experts maintain an Excel manifest of over 200 regulatory document sources. Power Automate reads that manifest, retrieves the content, converts it to PDFs, and stores everything in SharePoint. A second flow indexes those PDFs into Azure AI Search. Second, the search layer: when an engineer selects a city, that city label becomes a filter on the search index — Atlas queries only the documents relevant to that jurisdiction, preventing cross-contamination between city requirements. Third, the response layer: Copilot Studio takes the top five matching chunks from the index, passes them through a citation-matching step, and generates a structured answer with inline citations, confidence scores, and direct links to source documents.
The problem: The first version used Dataverse as the knowledge store, with one Copilot Studio topic per city. It worked — but the per-city topic approach added maintenance complexity as coverage expanded. Moving to Azure AI Search consolidated everything into a single topic, with city isolation handled through index filtering instead. Simpler to maintain, easier to extend as Dunaway adds more jurisdictions.
The pattern: The architecture is a template other organisations can reuse: a document manifest → Power Automate for ingestion → SharePoint for storage → Azure AI Search for retrieval → Copilot Studio for the conversational layer. The design principle — isolate knowledge by domain, retrieve with filters, cite back to source — applies to any domain where accuracy and traceability matter.
3. The Moment That Proved It Was Working

The context: The stated goal when Dunaway built Atlas was straightforward: speed to answer. Engineers spent too much time finding information. Atlas was supposed to make that faster. What the team didn't fully anticipate was where that speed would show up first.
The concept: In a client meeting, when someone asks a technical question and the answer isn't immediately available, there's a small but real loss of confidence. "We'll look into that and get back to you" is a professional answer. But "here's the answer" — pulled from the source, cited, in the room — is a different kind of answer. It doesn't just close the question faster. It changes the tone of the entire conversation.
The problem: Before Atlas, engineers couldn't answer code questions live because the research took hours, not seconds. The information was accurate — it just wasn't accessible at the right moment. Atlas shifted that constraint entirely. Engineers now query Atlas during meetings, receive cited answers in seconds, and close questions that previously required follow-up emails and delayed decisions.
The pattern: Brian Bowden, VP of Technology at Dunaway, described the shift plainly: "Previously, if a client had a question in a meeting, our engineers would have to say, 'We'll look into that and get back to you.' Now, they're able to query the bot in a meeting and answer the client's question immediately." That change — from deferred to real-time — is where the value of this type of agent becomes undeniable. It's not about hours on a timesheet. It's about what engineers can do in a client meeting that they couldn't do before.
4. Citation Accuracy: The Unglamorous Work That Builds Trust

The context: Regulatory compliance requires precision. An AI agent that gives confident but uncited answers is a liability, not an asset. Dunaway understood this from the start — which is why citation accuracy wasn't a nice-to-have feature. It was the engineering challenge the team spent the most time solving.
The concept: When a search index returns text chunks from a document, it knows the content but doesn't always know exactly where in the original document that content lives. For a general chatbot, this is acceptable — the answer is what matters. For a compliance tool used by professional engineers, the answer is only as useful as the citation attached to it. The engineer needs to open the source document, go to the exact page, and verify the information themselves.
The problem: Initially, Atlas attached correct citations around 70% of the time. The other 30% — chunks where location metadata was incomplete — produced answers engineers couldn't fully trust. The team built an Azure Functions app that addressed this directly. When a chunk is returned from the search index, the function processes the full PDF text and matches the chunk against all paragraphs in the document using BM25 ranking — the same algorithm behind most search engines. It identifies the correct paragraph, attaches the page number, and includes that metadata in the response. The result: consistently reliable, page-level citations across thousands of documents.
The pattern: Atlas's approach — surface the answer, attach the source, link to the exact page — is what makes it trustworthy for professional use. The 70% baseline shows why citation accuracy requires active engineering effort. Document chunk metadata is unreliable at scale. Building citation precision on top of the retrieval layer, rather than relying on metadata alone, is the difference between an agent engineers consult daily and one they distrust after the first wrong citation.
5. What Happened After Atlas: When One Agent Proves the Model

The context: Atlas was built for one specific use case: regulatory document research. It worked. And the credibility of that success opened a door. Dunaway's technology team wasn't just building a compliance tool — they were proving internally that AI agents could deliver real, measurable value. That proof funded the next bet.
The concept: Most organisations run employee support functions entirely through email or ticketing systems — HR questions, IT requests, accounting queries. Each team manages its own queue. Employees ask the same questions repeatedly. The answers exist; they're just inaccessible at the moment someone needs them. Which means those questions generate support load instead of self-resolved answers.
The problem: Dunaway built DAVE — the Dunaway AI Virtual Expert — a company-wide conversational agent that brings HR, IT, and accounting support into a single experience. Employees ask questions, complete forms, and submit requests in one place. IT ticket volume dropped 80%. But the number Dunaway is most proud of isn't the ticket reduction. It's that DAVE became genuinely adopted. In meetings, people now ask "Can DAVE do this?" — the agent has become part of the culture, not just a tool that some people use sometimes.
The pattern: The sequence matters. Dunaway didn't start with a company-wide AI strategy. They started with a specific problem (regulatory research), built something that worked (Atlas), demonstrated clear value (10,000 hours saved), and used that credibility to expand. The engineering firm that once spent over 10,000 hours a year in manual document searches now has two AI agents in active daily use — one of which their employees call a colleague by name.
The question that matters
Dunaway didn't have a large AI team, a multi-year transformation programme, or an exceptional budget. They had a specific problem, a clear measure of success, and tools they already had access to. Atlas took a compliance research process that consumed thousands of engineering hours and made it instantaneous. The question isn't whether this kind of agent is technically feasible — Dunaway answered that. The question is: what is the equivalent of 10,000 wasted hours in your organisation, and which documents do your best people spend too long searching through?
No comments yet — be the first to add to the discussion. Comments appear after they’re reviewed.
Want more insights?
Subscribe to get the latest articles delivered straight to your inbox.