An inspectable support-agent case study for grounded retrieval, safe tool calls, and accountable handoffs.
Reliability Lab is a frontend portfolio prototype for explaining what a reliable AI support agent should reveal before it answers a customer. Instead of presenting a generic chat window, it turns each scenario into a decision record: the response, selected sources, tool boundary, confidence signal, and the reason for a human handoff when evidence is insufficient.
The project is based on a reliable-RAG support-agent exercise and intentionally models its behavior without pretending to call a live model, order system, or vector database. This keeps the demonstration honest, portable, and easy to evaluate.
Customer-facing AI agents need more than fluent text. They need reliable source selection, narrow tool access, privacy controls, and the ability to abstain when the available evidence does not support a safe claim. Reliability Lab makes these operating principles visible in an interactive interface.
| Scenario | What the interface demonstrates | Safe outcome |
|---|---|---|
| TrailPlus return request | Policy retrieval with membership-specific terms | A supported answer or a clear support handoff |
Order AR-2048 |
Narrow order lookup and stale-ETA suppression | A status update without exposing personal data or inventing delivery dates |
| Breeze Tumbler care | Detection of conflicting authoritative documents | Explicit specialist verification rather than silent source selection |
flowchart LR
Q[Customer question] --> C[Classify intent]
C --> R[Retrieve active, authoritative evidence]
R --> G{Evidence sufficient?}
G -->|Yes| A[Compose grounded answer]
G -->|No or conflicting| H[Explain uncertainty and hand off]
C --> T[Narrow tool boundary]
T --> S[Sanitized result only]
S --> A
The interface represents four core safeguards. Source state matters, so active official policy is prioritized over stale or non-authoritative material. Tool data is scoped before composition, which prevents personal or internal fields from leaking into an answer. Confidence is treated as supporting context rather than permission to guess. Finally, a handoff is a successful safety decision when no well-supported response is available.
The scenario selector changes the active support case. The Inspect input routes a prompt to the appropriate representative case. The decision record has three reviewable views: the customer-safe response, the evidence list, and the reasoning trace. The evidence rail captures the safe tool state, grounding score, and human boundary for that response.
| Layer | Choice | Reason |
|---|---|---|
| Interface | React + Vite | Fast, portable static application shell |
| Visual system | Custom CSS + Lucide icons | Editorial “decision dossier” presentation without a UI-framework dependency |
| Interactions | Local React state | Deterministic, inspectable scenario switching |
| Deployment | Static-host compatible | Can be deployed to any conventional static host |
git clone https://github.com/greencookie-afk/learnChain-dapp.git
cd learnChain-dapp
npm install
npm run devCreate a production bundle with:
npm run buildReliability Lab does not invoke a hosted LLM, retrieve a live knowledge base, call a real order API, or store customer data. It demonstrates the interaction and observability layer that should sit around those systems. A production version would add a server-side retrieval service, authenticated tools returning schema-limited data, audit logging, evaluation regression tests, and a human-review queue.
This project is intended to demonstrate practical understanding of RAG, tool calling, source authority, privacy boundaries, prompt-safety controls, and human-in-the-loop design. The associated assignment implementation and evaluation results are available in the reliable RAG support-agent submission.
Built as a portfolio case study by Mithun Chakladar.