Government and public affairs · Citizen services
Citizens ask in their own words, eleven agents work out who answers
A leading Polish technical inspection authority receives thousands of citizen inquiries about permits, equipment safety and certification. Citizens ask in everyday language; the answers sit in dense technical documentation spread across departments. Their previous chatbot made people pick a category before asking, which most could not. We designed a multi-agent architecture that routes the question across 11 specialised knowledge areas instead.
Key results
Client: Polish technical inspection authority (under NDA)
A national authority responsible for equipment safety, operator permits and technical compliance across industrial and public infrastructure. The institution is under NDA, so it is not named here.
- Industry
- Government and technical inspection
- Use case
- Citizen-facing multi-agent chatbot
- AI approach
- Multi-agent architecture with RAG
- Knowledge
- 11 specialised domains
- Platform
- Azure, OpenAI, Qdrant, Langfuse
- Engagement
- Architecture design and working prototype
In short
Why people gave up and phoned instead
- The authority oversees safety and compliance for technical equipment across Poland, from industrial machinery and pressure vessels to elevators and amusement rides.
- Citizens describe their situation in plain Polish, “I am installing a new boiler in my building, what do I need”, while the answers live in precise, domain-specific legal documentation.
- The old chatbot required a category up front, could not calculate dates for permit deadlines, and could not combine knowledge when a question crossed domains.
- A main agent now reads the question and delegates to the specialised agents it concerns, so nobody has to know the institution’s internal structure to get an answer.
The starting point
The challenge
Citizens asked about complex technical regulations in everyday language. The previous chatbot required them to know the right category up front, could not compute dates, and could not combine knowledge across domains, so people gave up and called the office instead.
The institution oversees safety and compliance for technical equipment across Poland, from industrial machinery and pressure vessels to elevators and amusement rides. Citizens and businesses ask which permits they need, which safety requirements apply, how to apply for an inspection and what the deadlines are.
Those answers sit in dense technical and legal documentation written in precise, domain-specific language. Citizens do not ask in that language. They describe their situation conversationally and expect the system to work out which regulations apply.
The earlier chatbot hit three hard limits. It made people select a category first, and most did not know which one their question belonged to. It could not handle date calculations, which decide permit deadlines and validity periods. And it could not combine knowledge from more than one domain when a question crossed a boundary.
The build
What we built
We designed a new architecture from scratch around those specific limitations and delivered a working prototype that covers all 11 knowledge areas.
One orchestrator, eleven specialists
Instead of a single chatbot that tries to know everything, a main agent routes the question to specialised agents, each with its own knowledge base for one domain: permits, equipment categories, safety requirements, procedures. The citizen just asks. The main agent decides which domains are involved and delegates.
Plain language matched to technical language
The hard part is the gap between how a citizen describes their situation and how the documentation is written. Someone asking about “the big metal tank in my factory” has to reach documentation about pressure vessels, safety classes and inspection procedures. The retrieval and prompting pipeline is engineered to close that gap reliably.
The things the old system could not do
The new architecture handles automatic date calculation for permit deadlines and validity periods, asks a follow-up question when the request is ambiguous, and combines knowledge from several domains when a question spans them.
Domain experts maintain it, not developers
The knowledge base is managed through editable SharePoint Lists, so subject experts inside the institution update and extend the content without a developer. That was deliberate: accuracy depends on the content being current, and the people who know the content best should not need technical skills to keep it that way.
Deployed to the institution’s security requirements
The prototype runs on Microsoft Azure with Entra ID authorisation and Langfuse monitoring, which matches what the institution requires and shows exactly how the system is performing.
What changed
The results
Before
Citizens had to choose a category before asking. No date calculations, no way to combine knowledge across domains, and many people gave up and called the office.
After
Citizens ask in plain language and routing happens by itself. Date calculations are built in, cross-domain questions work, and non-technical staff maintain the knowledge through SharePoint.
The prototype showed that the multi-agent architecture solves the specific problems the previous system could not: routing, date arithmetic and questions that cross domains.
Citizens describe their situation naturally and reach the right knowledge domain without knowing the institution’s internal structure or terminology.
For any institution with a complex, multi-domain knowledge base and non-expert users, the approach scales: rather than one chatbot that tries to know everything, specialised agents plus a routing layer that puts the right expert in front of the right question.
Questions about this project
Citizen-facing multi-agent chatbot. Citizens asked about complex technical regulations in everyday language. The previous chatbot required them to know the right category up front, could not compute dates, and could not combine knowledge across domains, so people gave up and called the office instead.
Knowledge areas, each with its own domain agent: 11. Routing happens on its own, with no category to pick: Auto. Everyday language matched to technical documentation: Plain → tech.
Multi-agent architecture with RAG. Technology used: Multi-agent architecture, OpenAI, Qdrant, RAG, Microsoft Azure, Entra ID, Langfuse, SharePoint Lists, Python.
Technology used
Talk to the people who built this
theBlue.ai comes back within one business day.
