The situation
One of Europe's largest insurance brokerages was running a high-volume customer service operation with a structural problem. Case volume was growing faster than headcount could scale. Handling times were inconsistent. And the data that would allow better decisions (claims history, customer interactions, policy details) existed across multiple systems in formats that made it effectively unusable.
The team was talented. The problem wasn't effort. It was architecture.
The challenge
Building AI for customer service operations sounds straightforward until you face the real constraints:
- Data fragmentation: Customer data lived across legacy CRM systems, policy databases, and unstructured case notes. None of it was clean or consistent.
- Decision complexity: Insurance cases involve regulatory considerations, policy nuance, and escalation logic that can't be brute-forced by a simple classifier.
- Production requirements: A demo that works 80% of the time isn't deployable. The system needed to handle edge cases reliably, escalate appropriately, and maintain an audit trail.
- Stakeholder trust: Automating customer-facing decisions in a regulated industry requires building confidence incrementally, not deploying and hoping.
The approach
I led the design and build of an end-to-end agentic AI pipeline. Not a routing bot, not a suggestion engine, but a system that handled case resolution autonomously.
Phase 1: Data architecture
Before building any models, the data layer had to work. That meant designing a unified data schema, building extraction pipelines from legacy systems, and establishing data quality standards that made retrieval actually useful. Most AI projects skip this step. This is usually why they fail.
Phase 2: Retrieval-augmented architecture
The system used retrieval-augmented generation (RAG) as its core approach: for each incoming case, it retrieved relevant policy documents, historical precedents, and customer context, then synthesised a resolution decision. This approach keeps the system grounded in the organisation's actual rules and documentation, not hallucinating plausible-sounding responses.
Phase 3: Agentic decision loop
The resolution pipeline was built as a multi-step agent: understand the case, retrieve relevant context, reason through resolution options, apply policy logic, determine whether to resolve or escalate, and generate the customer communication. Each step was observable and auditable. Essential for a regulated environment.
Phase 4: Human-in-the-loop design
Automation rate isn't the only metric that matters. The escalation logic determined which cases stayed with the AI and which were surfaced to human agents, with full context, so the human could pick up from where the AI left off without starting again. This improved both the automated resolution quality and the human agent efficiency.
Phase 5: Production deployment
Rollout was staged: 10% of case volume, monitored closely, then scaled as confidence data accumulated. This is how you build institutional trust in an automated system. Not by making promises, but by showing the numbers.
The results
- 67% of customer service cases resolved without human intervention, from first contact to resolution
- 23% improvement in sales KPIs, driven by an AI-powered opportunity identification layer built alongside the resolution system
- Significant reduction in average handling time across both automated and human-handled cases
- Audit-ready decision trail for each automated resolution
- Headcount scaling decoupled from case volume growth
What this means for your business
Most AI projects in customer service produce dashboards that show AI activity, not outcomes that change cost structures or revenue metrics. The difference is in how the system is architected from the ground up.
If you're building, or planning to build, AI for a customer-facing or operational workflow, the questions worth asking before you start are:
- Is your data actually retrieval-ready, or are you building on a fragile foundation?
- What does the escalation logic look like, and who designed it?
- How will you build trust incrementally rather than launching and hoping?
These are the conversations I have before anyone commits to a technical approach. If you're at this stage, a Technical Due Diligence or AI Transformation Sprint is the right starting point.
This engagement was delivered as co-founder and engineering lead at AdBrain. Client details are kept confidential; the organisation is referenced here with permission as "one of Europe's largest insurance brokerages," consistent with how this work has been previously described in public contexts.