WorkSkillsRecognitionAboutContactRésumé ↓
Case Study 01 · Agentic AI System

GroundTruth

Proving that the hard part of agentic AI is not generating an answer, it is knowing when the answer cannot be trusted.

Status
Live
Type
Multi-agent orchestration
Built on
Lyzr Architect

The problem worth solving

There is a gap the whole AI-agent industry now calls the productionization gap: an agent is easy to build and hard to trust. In a real support context a confident but unsupported answer is not a bad experience, it is a compliance and trust liability. The interesting problem is not can the agent answer, it is does the agent know when it should refuse.

The core design choice was a constraint, not a feature: the system is never allowed to present a claim it cannot attach to a retrieved source.

How it works

A Manager agent orchestrates four specialists, plus a separate independent finalizer. Verification is its own stage that can veto a response, not a rule folded into drafting. That separation is the single most important structural decision in the system.

Classifyintent, priority
RetrieveRAG + scores
Draftgrounded reply
Verifyclaim by claim
at the safety gate
Grounded → answer, behind a human gate
Unsupported → suppress & escalate
Nothing reaches a customer that verification cannot ground.

The architecture

Each agent has its own model and temperature, chosen for its job. The retrieval and verification agents run near-deterministic, because a checker should not be creative.

Agent Role Model Temp
Resolution Coordinator Manager, orchestrates the pipeline and enforces the safety gate claude-sonnet-4-6 0.2
Classification Agent Category, priority, intent gpt-4o-mini 0.2
KB Retrieval Agent Semantic RAG, returns articles with relevance scores gpt-4o 0.1
Response Drafting Agent Drafts a reply grounded strictly in retrieved articles claude-sonnet-4-6 0.2
Grounding Verification Agent Verifies every claim, returns Grounded / Not Grounded / No Source claude-sonnet-4-6 0.1
Response Finalizer Independent, polishes the human-approved draft gpt-4o 0.3
Orchestration and temperature tuning
Every agent runs its own model at a temperature chosen for its job. Watch where each one sits on the deterministic-to-creative axis.
MANAGER
Resolution Coordinator
claude-sonnet-4-6
0.2
SPECIALIST
Classification Agent
gpt-4o-mini
0.2
SPECIALIST
KB Retrieval Agent
gpt-4o
0.1
SPECIALIST
Response Drafting Agent
claude-sonnet-4-6
0.2
SPECIALIST
Grounding Verification Agent
claude-sonnet-4-6
0.1
INDEPENDENT
Response Finalizer
gpt-4o
0.3
0.0 · deterministiccreative · 1.0
Retrieval and verification sit at 0.1 because a checker must not be creative. Orchestration and drafting hold at 0.2. Only the independent finalizer runs warmer, at 0.3, for fluent polish after a human has approved the content. The tuning is the point: the parts that decide truth are the least creative parts of the system.

I stress-tested my own grounding claim, with numbers

A promise like the system refuses when it cannot ground an answer is only worth making if it is measured. I ran a six-ticket set, four that should ground and two that must escalate, each multiple times, because a single run cannot reveal consistency.

0
Grounding fidelity on covered topics
0
Hallucinated answers shipped
0
False retrieval match caught by verification
0
Must-escalate tickets refused

The headline result: verification caught what retrieval missed

On the SAML SSO ticket, retrieval returned a false roughly 90% match. Retrieval alone would have passed that to the drafter and produced a confident answer built on unrelated content. The verification agent recognized the retrieved content did not support a SAML answer, suppressed the draft, and escalated. This is the concrete proof that grounding needs a dedicated verification stage rather than trust in a retrieval score.

The residual non-determinism is not a bug to hide, it is a business decision to own. The system fails safe.On why this is a PM artifact, not an AI demo

The product point underneath the system

When uncertain, the system over-escalates to a human rather than hallucinating, which is the correct direction to fail for support. The real product question is not eliminate all variance, it is where the safe-fail boundary should sit: a tunable, instrumented decision a PM makes, not an engineering afterthought.

§

Full case study & deliverables

Beyond the live app, the work is documented as a five-part product dossier: build and findings, a product analysis, an illustrative business case, a hands-on test sheet, and a full PRD with competitive positioning across nine agent platforms.

Next case study
Receipts