USE OBSERVABILITY
THE CRITICAL IMPORTANCE OF LLM
OBSERVABILITY IN ENTERPRISE AGENTS
— from a single AI agent to a production multi-agent system
From AI Agent to Production Multi-Agent System — using a real claims-adjudication system as the example
Why Traditional Observability Isn't Enough
Anatomy of a Claim's Trace
Multi-Agent: Where Failure Is Born
What Should We Observe?
①SYSTEM
the world your dashboards already own — this axis never changed for agents
②LLM
local inference makes cost a non-issue here — latency is the real budget
③AGENT
the control loop is the application now — a wrong tool choice is a bug, not a stack trace
④QUALITY
the layer everyone forgets — a claim can look "done" and still be wrong
The Tool Landscape — Five Layers
before every deploy
one session per claim
free-tier fallback chain
policy · history · fraud
everything runs on
Production Architecture — Meridian Claims
GET /claims/{id} → findings + decision + Langfuse session URLone query plane — the portal, the claim, and the trace are always one click apart
①NEXT.JS PORTAL
claims queue · new-claim form · audit trail · every finding links its trace
②MCP TOOL SERVER
check_coverage · lookup_medical_history · fraud_score — real tool calls, real spans
③LANGFUSE CLOUD
one session per claim · eval dataset re-run on every fix · continuous groundedness scoring
Meridian Claims — the actual system, named
Live Demo — Meridian Claims
file a real claim · watch the floating "thinking" widget name each agent live · watch the audit trail fill in with real MCP tool output · click "View trace ↗" into the real Langfuse session
The Production Improvement Loop
a real eval run flagged claim CLM-9004 — expected human_review, got approved.
the fraud signal for that claim had no real reason to route it — a seed-data gap, not an agent bug.
one fix to the fraud-signal table → re-run → 4/4 green.
If You Remember One Picture
IF YOU CAN'T
SEE IT, YOU
CAN'T SHIP IT

linkedin.com/in/ashishpatel2604