The Tech Trek · Ep. 712

AI Observability Metrics: Quality, Risk, and Business ROI

Jeetendra Soneja · VP of Engineering, AI Platform · iHerb

01 — The conversation
GuestJeetendra SonejaVP of Engineering, AI PlatformiHerbProfile →

An AI agent can respond quickly and still produce an unreliable answer. Jeetendra Soneja, VP of Engineering, AI Platform at iHerb, explains how observability helps teams measure the quality, cost, risk, and business value of AI systems. He discusses evaluation strategies, practical guardrails, engineering skills, and when to introduce monitoring as AI applications grow.

Key ideas
01AI observability must track quality, groundedness, and task completion, not just latency and uptime.
02Cost per task and meaningful business outcomes matter more than token usage or pull request counts.
03Evaluation criteria should reflect the specific domain and what success looks like for the business.
04The right guardrails depend on the consequences of an AI error, including when to block responses.
05AI engineering requires context management, experimentation, sound architecture, and human judgment.
06Start observability during development, prove value early, then strengthen controls before scaling.

Traditional software observability focuses on deterministic signals such as availability, errors, and latency. AI agents also introduce variable responses, hallucinations, and unexpected tool actions. Jeetendra explains how tracing, quality checks, and groundedness assessments help teams understand not just whether an agent runs, but whether it accomplishes the intended task.

AI return on investment should connect operational metrics with outcomes. Lower task completion time can matter, but more generated code or a surge in pull requests is not proof of value. For customer facing systems, useful measures may include conversions, satisfaction, and support resolution without escalation.

Risk tolerance changes with the workflow. For applications with serious consequences, online blocking evaluations and explicit guardrails may be appropriate. Other systems can use offline evaluation and feedback loops. Jeetendra discusses the balance between evaluation cost, response latency, and the risk of getting an answer wrong.

Teams do not need an expensive custom observability platform on day one. Jeetendra recommends using basic tools even during prototyping, validating an AI workflow with experiments or beta users, and identifying model, tool, and data pipeline bottlenecks as adoption grows. He also highlights the importance of software engineering fundamentals, context engineering, and long term maintainability.

02 — Transcript

Full transcript of this conversation.