August 2026 Summaries

LLM application frameworks reduce the custom engineering needed to connect models with external data, coordinate multi-step workflows, optimize prompts, validate structured outputs, and stream responses to web interfaces, though direct provider SDKs may be sufficient for simple applications. Frameworks should be compared by their primary purpose, abstraction level, language compatibility, ecosystem maturity, and tracing and evaluation capabilities rather than treated as interchangeable tools. LlamaIndex focuses on retrieval-augmented generation and private-data workflows; LangChain supports broad orchestration across models, tools, and services; DSPy optimizes prompts and model programs using datasets and measurable quality metrics; Instructor enforces typed, schema-valid responses with validation and retries; and Vercel AI SDK supports TypeScript applications with unified provider access and streaming UI features. Firebase Genkit and Agno provide additional options for cross-language AI development and agent-oriented workflows. Applications can combine specialized frameworks, such as using LlamaIndex for retrieval, LangChain for execution flow, and Instructor for output validation, but overlapping control of state or retries should be avoided. Across these approaches, tracing and evaluation remain important for diagnosing failures, assessing retrieval and output quality, and making evidence-based release decisions.

An MCP eval is a repeatable, multi-trial assessment of how reliably an AI agent uses a specific Model Context Protocol server to complete realistic tasks, recording model decisions, tool calls, arguments, responses, errors, and resulting system state in detailed traces. Unlike server and protocol tests, which verify deterministic responses to known requests, MCP evals measure whether an agent can interpret tool descriptions, select necessary and appropriate tools, construct valid arguments, sequence multi-step actions, recover from failures, and actually achieve the requested outcome. Evaluations should mirror the production configuration, including transport, authentication, permissions, tools, and server version, because changes to models, instructions, clients, schemas, tool descriptions, permissions, or available tools can alter agent behavior even when server tests still pass. Effective scoring combines trajectory analysis and state assertions with deterministic checks, model-based judges, and human review, while repeated trials produce pass rates that reveal inconsistency rather than relying on a single successful run. The framework can assess MCP tools, resources, and prompts, distinguish application-specific readiness testing from public benchmarks, and support release decisions by turning production failures into regression cases run through CI/CD.

MCP testing verifies that Model Context Protocol servers correctly handle transports, authentication, protocol primitives, and tool interactions, while agent evaluation assesses the broader agent’s planning, tool use, trajectories, and task outcomes. The comparison ranks Braintrust as the most comprehensive option for teams needing real-agent evaluations, custom scoring, repeated trials, trace debugging, CI release gates, and production regression monitoring, though it requires MCP Inspector for protocol conformance debugging. MCPJam is positioned for protocol inspection, OAuth validation, and cross-client behavioral testing; mcp-eval provides Python and OpenTelemetry-based assertions against live servers; DeepEval supplies metrics for already recorded MCP interactions; and the open-source MCP Inspector focuses on local protocol, transport, and authentication debugging without model-based assessment. The selection criteria emphasize server connectivity, language and model support, scoring flexibility, trial repeatability, CI reporting, and production data handling, with the overall recommendation that teams combine protocol checks with model-driven evaluations to catch both server failures and ambiguous tool designs that can cause agents to act incorrectly.

MCP testing spans server unit tests, protocol conformance, security, load testing, and MCP evals, with evals specifically assessing how AI agents interpret tool descriptions, select tools, generate arguments, execute multi-step workflows, avoid unsafe actions, and complete user requests. Effective evaluations use realistic datasets drawn from production traces, support incidents, and reviewed synthetic edge cases, covering no-tool requests, ambiguous tool choices, error recovery, permissions, and side effects; they commonly run repeated trials to account for model variability. Scoring should combine deterministic checks for calls and arguments, trajectory and final-state validation for execution, and narrowly calibrated model-based scoring for semantic outcomes, while enforcing separate thresholds for high-risk failures such as unauthorized or destructive actions. Detailed traces of available tools, calls, responses, timing, and subsequent actions help attribute failures to scorers, tool definitions, schemas, server behavior, instructions, or model capability. Tool names, descriptions, and the size and composition of a tool set can materially alter agent behavior, making versioned regression evaluation important. The text also describes MCP Inspector for protocol-level debugging, open-source harnesses and public benchmarks for broader testing, and Braintrust workflows for versioned datasets, instrumented traces, custom scoring, experiment comparisons, and CI gates that evaluate changes to models, prompts, schemas, tool definitions, and server versions.

Braintrust’s Model Context Protocol (MCP) server connects MCP-compatible coding agents such as Claude Code, Codex, and Cursor to an organization’s production traces, experiments, datasets, prompts, scorers, and project settings, enabling investigation and operational changes from a terminal or agent conversation. It can support workflows such as identifying faulty chatbot responses in production logs, creating and testing evaluators, adding failures to regression datasets, comparing prompt versions through evaluations, and configuring Topics, monitoring views, alerts, and recurring investigations. The MCP also helps agents instrument applications by installing supported Braintrust SDKs, configuring tracing, and confirming that telemetry reaches Braintrust, while offering documentation search and guided workflow skills. Large SQL results can be delivered through signed URLs to avoid exhausting model context, and write actions use the authenticated account’s permissions, with confirmation recommended for potentially consequential changes such as permanent dataset deletions. Braintrust positions MCP for conversational, connected agent workflows where an authenticated shell may not be available, while its CLI is intended for repeatable scripting, CI, local-file, and shell-pipeline tasks.

Harbor, a Python framework from the terminal-bench team for evaluating sandboxed agents in isolated Docker containers, now offers a native Braintrust plugin that synchronizes evaluation results for easier comparison, sharing, and analysis. Previously, each Harbor run produced local job directories containing task environments, agent instructions, verifier results, and artifacts that had to be retained or manually shared to compare outcomes across runs. With the plugin, each job syncs managed task datasets, trial-level experiment rows, normalized verifier scores, and optional agent trajectories in Harbor’s ATIF format to a Braintrust project, while also preserving a local manifest of synced data. Users can inspect failed trials, trace agent decisions down to individual tool calls, chart separate verifier rewards, and keep setup, agent actions, and verification in a unified evaluation timeline. The integration can be enabled during a Harbor run through plugin flags or environment variables, keeps the Braintrust API key outside the sandbox container, and can backfill previously completed jobs without rerunning agents or creating duplicate records.

Braintrust and Portkey serve overlapping but distinct AI infrastructure needs: Braintrust emphasizes evaluation, observability, and release control, while Portkey, now underlying Palo Alto Networks’ generally available Prisma AIRS AI Gateway, focuses on request-time routing, governance, and security. Braintrust Gateway, which remains free in beta, supports major providers, custom endpoints, cross-SDK model switching, ordered failover, encrypted response caching, and deep links between production traces, datasets, experiments, automated scoring, and CI/CD release gates, but it does not synchronously block unsafe requests or enforce per-key budgets and quotas. Portkey offers a broader model and tool catalog, richer conditional routing, load balancing, retries, canary deployments, semantic caching, inline input and output guardrails, and policy-based controls such as model restrictions, spending limits, and rate limits. Both platforms provide prompt versioning, tracing, self-hosting options, and enterprise deployment models, although Braintrust’s customer-cloud and self-hosted data planes require Enterprise, whereas Portkey’s MIT-licensed gateway can be independently self-hosted. Braintrust is positioned as more suitable for teams making quality evaluation a formal part of development and production release decisions, while Portkey is better suited to applications requiring sophisticated gateway orchestration and real-time security enforcement; organizations can also combine them by using Portkey in the request path and Braintrust for application-level tracing and evaluation.

OpenRouter provides centralized access to more than 500 models from numerous providers through a consistent API, with configurable routing, failover, caching, and provider selection that simplify model experimentation, but its production evaluation workflow, granular cost attribution, multi-step observability, and percentage-based fees may require supplementary tools or become less attractive at scale. The comparison identifies Braintrust Gateway as a choice for teams seeking integrated production traces, evaluation datasets, scoring, experiments, and CI release gates; LiteLLM and Portkey for organizations prioritizing self-hosting and routing controls; Vercel AI Gateway for Vercel-based applications and no-markup usage; Together AI for open-weight model hosting, fine-tuning, and dedicated GPU inference; and Cloudflare AI Gateway for edge-based caching, analytics, and traffic management. Selecting an alternative should involve testing OpenAI SDK compatibility, model coverage, total pricing, caching, metadata-based cost reporting, deployment requirements, tracing, and the ability to turn poor production outputs into reusable evaluation cases. Migration generally requires changing the endpoint and credentials, mapping OpenRouter-specific model identifiers to supported target models, recreating routing and billing configurations, and comparing quality, latency, errors, token use, and costs on representative production traffic before shifting requests.

Portkey is an OpenAI-compatible AI gateway that supports more than 1,600 models and combines routing, failover, caching, credential management, prompt versioning, observability, guardrails, and enterprise governance, but teams may seek alternatives because of log-based pricing and limited retention, hosted deployment and proxy-latency concerns, data residency requirements, and its May 2026 acquisition by Palo Alto Networks. Selecting a replacement requires assessing API and SDK compatibility, provider and feature coverage, caching, cost attribution, guardrails, self-hosting, RBAC, and whether production logs can support evaluations and release workflows. Braintrust Gateway emphasizes multi-provider routing linked to tracing, datasets, experiments, and CI evaluation; OpenRouter offers broad hosted model access; LiteLLM provides an open-source self-hosted proxy; Vercel AI Gateway targets Vercel-based applications; Kong AI Gateway extends existing API-management infrastructure; and Cloudflare AI Gateway supplies edge-based routing, security controls, and logging. A migration should inventory existing configurations, recreate credentials and access policies, translate routing and caching behavior, move prompts and guardrails, export required historical data, and test representative traffic before a staged cutover.

OpenRouter and Braintrust Gateway address different parts of LLM application development and production: OpenRouter emphasizes access to a marketplace of more than 500 models from over 80 providers through a unified OpenAI-compatible API, centralized prepaid billing, optional bring-your-own-key support, automatic provider routing, and broad model exploration, while Braintrust Gateway uses team-managed provider credentials and focuses on connecting model calls with tracing, evaluation, release controls, and production-quality monitoring. Both support routing, failover, caching, request-level cost visibility, and compatibility with common SDKs, but OpenRouter generally offers a wider rapidly changing catalog and flexible routing across shared provider capacity, whereas Braintrust offers more explicit endpoint ordering, project-level credentials, application-span cost attribution, and detailed traces tied to quality scores and feedback. OpenRouter’s Ori Eval provides code-based agent regression tests and CI comparisons, while Braintrust extends evaluations from datasets and experiments to release gating, human review, and online production scoring. OpenRouter is positioned for teams prioritizing model variety and consolidated billing without direct accounts at every provider, while Braintrust is aimed at organizations that manage their own provider accounts and require measured quality standards, reproducible routing, and stronger data-plane deployment options; the two can also be used together, with OpenRouter supplying model access and Braintrust handling observability and evaluation.

LLM red teaming uses controlled adversarial methods such as prompt injection, role-play, encoding, multi-turn escalation, and extraction attempts to identify policy violations, unauthorized actions, and sensitive-data exposure in AI applications. Because red team reports become outdated after model, prompt, permission, retrieval, or application changes, confirmed findings should be converted into reproducible regression tests with preserved attack context, an approved safe outcome, severity metadata, and explicit pass-or-fail criteria. Deterministic scorers can detect concrete disclosures or prohibited patterns, while calibrated LLM judges can assess nuanced semantic harms; each scorer and test case should be updated as attack variants emerge. Findings may originate from internal teams, external vendors, open-source tools, or production incidents, but require human validation before becoming release requirements. Braintrust is presented as an evaluation platform that stores adversarial datasets, runs experiments, compares results across versions, and integrates suites into CI/CD so critical regressions can block releases, while retaining evidence and coverage over time; it does not itself generate attacks or scan applications.

Testing AI agents differs from traditional software testing because model-driven behavior is non-deterministic, often involves multiple tool calls, and may change external state, making exact output matching inadequate. Effective evaluation assesses both final outcomes and decision trajectories through scored criteria, repeated trials, trace-level inspection, and controlled or stubbed dependencies that prevent real-world side effects such as refunds or customer emails. A comprehensive strategy combines deterministic unit tests with agent evaluations across single-step decisions, full trajectories, CI regression suites, and production monitoring, examining tool selection, argument validity, output schemas, response quality, execution order, final system state, and step counts. Test cases should draw heavily from real production traffic and incidents while covering routine, edge, adversarial, and out-of-scope requests, with datasets versioned alongside agent changes. Braintrust presents its platform as a system for defining datasets, tasks, and scorers; tracing tool interactions; enforcing score thresholds in CI; and scoring sampled production traces so reviewed failures can be incorporated into future regression tests.

Effective RAG pipeline testing requires instrumenting retrieval and generation as separate trace spans, using production query logs to create a versioned golden dataset, and recording all corpus, model, prompt, and retrieval configuration details for reproducibility. The process evaluates retrieval independently through document-label metrics such as Recall@k, Precision@k, and NDCG or semantic context scorers, then tests generation against fixed reviewed context for faithfulness, relevance, and correctness while validating LLM judges against human review. Full end-to-end experiments should compare one configuration change at a time with a saved baseline, examine individual regressions alongside aggregate scores, use repeated trials for variable outputs, and apply predefined release thresholds, must-pass cases, and handling requirements for unanswerable queries. These checks can be automated in CI with smaller pull-request smoke tests and full post-merge suites, including custom logic that fails builds when quality criteria are missed. After deployment, asynchronous production scoring, dashboards, alerts, metadata filtering, and review of low-scoring traces help detect emerging failures and feed confirmed cases back into the dataset, creating a continuous evaluation cycle supported by Braintrust’s experiments, datasets, tracing, scoring, CI integrations, and production monitoring tools.

Web and browser agent evaluation assesses whether an AI system completes browser-based tasks through acceptable actions and verifiable end states, accounting for the changing page representations—such as screenshots, DOM snapshots, and accessibility trees—that agents use to select targets. Unlike standard LLM evaluations that primarily grade final responses, these evaluations examine the full interaction trajectory, including element grounding, action types and values, page-state transitions, task completion, extraction accuracy, efficiency, loops, timeouts, latency, and cost. Live websites introduce variability from layout changes, A/B tests, and altered markup, making reproducible testing environments and separate diagnosis of agent regressions versus website drift important. Effective traces capture the agent’s observations, actions, execution results, and resulting browser states at every step, typically organized into parent-child spans for multi-step tasks. Scoring can combine code-based checks for structured actions and outcomes with calibrated LLM-based judgment for trajectory interpretation, while regression datasets should be built from production failures, reset between trials, and include independently verifiable success criteria. Braintrust is presented as a platform for tracing browser runs, attaching page evidence, promoting failed production traces into datasets, comparing experiments against baselines, and applying evaluation gates to model, prompt, or agent changes.

Kimi K3 and DeepSeek V4 Flash have been added as built-in Braintrust models alongside GLM-5.2, allowing users to test them in playgrounds, prompts, scorers, and deployments without separate inference providers or API keys. In an evaluation using 327 MathTutorBench tutoring dialogs, GLM-5.2 achieved the highest teaching-quality score of 0.680, DeepSeek V4 Flash scored 0.653 while delivering the fastest first visible token at 0.57 seconds with reasoning disabled, and Kimi K3 scored 0.589 while using the fewest completion tokens at a median of 48. An example tutoring task showed GLM-5.2 correcting a student’s unsupported assumption, while DeepSeek V4 Flash reached the correct equation but initially reinforced the error and Kimi K3 retained the mistaken framing. Reasoning effort affected Kimi K3’s quality most substantially, whereas enabling reasoning also increased response latency for DeepSeek and GLM. The comparison recommends evaluating models against representative proprietary data and production needs, with GLM-5.2 positioned for quality, DeepSeek V4 Flash for speed, and Kimi K3 for lower token use; both new models can be accessed through Braintrust’s interface or gateway APIs.

LLM guardrails are policy-driven controls that inspect model inputs, outputs, or full interaction traces, score them against defined criteria, and trigger actions such as blocking, redacting, alerting, or escalating violations involving toxicity, unsafe advice, prompt injection, personal data, or compliance requirements. Provider-level model alignment and static filters offer baseline protections, but they may not address application-specific policies or reveal false negatives and changing accuracy in production. A measurable guardrail workflow combines a written policy, custom code-based or LLM-as-a-judge scorer, thresholds and severity levels, online production evaluation, alerts or automations, and a process for adding confirmed failures to regression-test datasets. Inline controls remain necessary when harmful content must be stopped before delivery, while asynchronous scoring supports monitoring and investigation without adding user-facing latency. The comparison of guardrail tools distinguishes runtime enforcement platforms, such as NVIDIA NeMo Guardrails, Guardrails AI, Check Point, OpenAI Moderation, and Amazon Bedrock Guardrails, from Braintrust’s evaluation-focused approach, which links pre-deployment experiments, production scoring, observability, and continuously expanding datasets.

LLM gateway caching can reduce model costs and latency by serving reusable responses or prompt computations before a full generation is required, with savings determined by cache hit rates, bypassed token volume, and expiration settings. Exact-match caching returns a complete stored response only when request content, model, and generation parameters match, making it suited to deterministic prompts, evaluations, CI runs, and repeated API requests; Braintrust Gateway provides this approach with configurable modes, TTLs, cache-status headers, encryption, and optional sharing controls. Semantic caching uses embeddings and similarity thresholds to reuse answers for paraphrased requests, potentially increasing hit rates but introducing a risk of incorrect matches and requiring supporting embedding and vector-store infrastructure. Provider prompt caching instead reuses computation for repeated prompt prefixes while still processing variable input and generating new output, reducing input costs without eliminating output-token charges. Selecting a method depends on whether requests, meanings, or prompt prefixes repeat, while volatile information such as prices, inventory, permissions, and account state requires short TTLs or cache bypasses. Effective production use also depends on including current context in requests, evaluating cache behavior before deployment, monitoring stale or inaccurate responses after launch, and distinguishing cached responses from fresh model generations.

AI voice agent platforms combine speech recognition, language models, voice synthesis, turn detection, session context, telephony, and error recovery to support live phone or web conversations, with production quality depending on reliable coordination rather than voice realism alone. Key comparison factors include end-to-end latency, phone-number and SIP connectivity, interruption handling, flexibility in choosing speech and language models, and testing capabilities. Vapi emphasizes developer-configurable STT, LLM, TTS, and telephony components; Retell AI offers managed phone-agent deployment with visual or prompt-based flows, monitoring, and experimentation; Bland targets high-volume inbound and outbound calling through a vendor-managed stack; LiveKit Agents provides open-source, self-hostable real-time infrastructure and broad model flexibility; and ElevenAgents centers on ElevenLabs’ speech and voice technology while allowing supported or custom language models. Pipecat is also noted as an open-source framework for multimodal agents. Selecting a platform depends on requirements for managed services versus infrastructure control, telephony scale, model choice, deployment environment, and custom media behavior, while thorough pre-release and continuous evaluation of transcripts, tools, outcomes, and call quality remains necessary to identify regressions and production failures.

LLM security requires controls across five layers: input filtering, output moderation, schema validation, tool permissions, and evaluation and monitoring, because failures can occur from untrusted prompts through downstream agent actions. Lakera Guard focuses primarily on screening inputs for prompt injections, jailbreaks, sensitive data, and other threats; Guardrails AI combines output moderation with structured-output validation; NVIDIA NeMo Guardrails governs agent behavior and tool calls; and Braintrust evaluates and monitors the effectiveness of these controls before release and in production. Each tool has limits, requiring organizations to combine runtime protections with application authentication, permissions, policies, and operational processes. Evaluation is presented as essential for measuring missed attacks and false positives, detecting regressions caused by changing models or prompts, and turning production failures into future test cases. Recommended stacks depend on application risk, with chat features needing input and output screening, structured-output systems adding schema validation, tool-using agents requiring execution controls, and regulated or high-impact applications mapping protections across all five layers.

An experiment tested whether a Recursive Language Model harness trained to decompose tasks into chunks might transfer an incorrect “sum the chunk results” strategy to a superficially similar task where global deduplication is required. Using Qwen3-30B with and without an RLM LoRA adapter, the study compared COUNT, where chunk totals can correctly be added, with SENDERS, where summing distinct senders per chunk creates double-counting. Although the task design controlled for reading difficulty, pseudonymized names, and alternative overcounting strategies, repeated evaluations encountered floor and ceiling effects: an initial version was too difficult, while a redesigned version made SENDERS too easy. A pooled analysis of 13 pairs produced an apparent negative transfer result under one random seed but not another, with the estimated accuracy effect shifting by roughly 0.4, while both models double-counted at identical rates in every run. The author concludes that the evidence neither demonstrates nor rules out harmful strategy transfer, partly because the experiment did not reliably measure whether the harness treated the two tasks as equivalent, and recommends future tests using identical sender records arranged in layouts where chunk-level addition is either valid or invalid.

Cloudflare has introduced native tracing for agents built on Cloudflare Workers, using OpenTelemetry spans that can be exported to OTLP-compatible platforms such as Braintrust for production monitoring, evaluation, and improvement. Developers can either configure Braintrust as an OTLP destination through Workers Observability without adding an SDK to their Worker, or use Braintrust’s JavaScript instrumentation for Cloudflare Agents SDK, @cloudflare/ai-chat, @cloudflare/think, and Flue, subject to specified package versions and Workers deployment requirements. Traces capture agent and model invocations, tool calls and approvals, subagent activity, token usage, decisions, and underlying infrastructure behavior, helping teams diagnose issues such as incorrect tool usage, unsuitable model choices, or slow database queries. Braintrust can also turn production traces into evaluation datasets, enabling comparisons of models and subagents and testing of prompt or tool changes before deployment, while its Flue integration supports evaluation reporting through vitest-evals.

Red team campaigns identify risks at specific points in time, but changes to various components can cause previously resolved vulnerabilities to reappear, necessitating a permanent record for each risk. Tools like Garak and PyRIT facilitate the discovery of adversarial behaviors, with Garak focusing on broad vulnerability scans and PyRIT enabling custom multi-turn attacks. These tools are part of a larger framework that includes Braintrust, which serves as a repository for confirmed risks and supports ongoing evaluations. Braintrust stores detailed records of each confirmed risk, including adversarial inputs, expected safe behaviors, and metadata, allowing for structured regression testing and continuous evaluation through CI/CD processes. Production logs can contribute new cases, and Braintrust helps maintain a versioned dataset, ensuring that confirmed risks are continuously tested and managed throughout the development and release process.

LLM provider lock-in involves dependencies that complicate switching providers, which can stem from code, behavioral, and data coupling. Code coupling, related to provider-specific SDKs and code changes, can be mitigated by gateways like the Braintrust AI Gateway, which standardizes request formats across multiple providers. Behavioral coupling arises from prompts tailored to specific models, leading to different outputs with a new model, necessitating thorough evaluation to ensure quality requirements are met. Data coupling involves reliance on provider-specific logs and evaluation history, which may hinder migration unless data is exportable and reusable with new providers. Solutions like Braintrust store data separately from model configurations, allowing cross-provider evaluation without rebuilding test cases. When switching providers, it's crucial to validate the candidate model through experiments and evaluations to ensure it meets the application's quality standards, using tools like Braintrust and OpenRouter to streamline the process and reduce engineering effort.

AI agent memory tools enhance the capability of language models by providing persistent recall across sessions, thereby allowing agents to remember preferences, project details, and decisions beyond the active context window. These tools store extracted facts in a separate memory layer and retrieve relevant information when new requests rely on previous context. Several tools, such as Mem0, Zep, Letta, Supermemory, Cognee, and Sentra, offer various approaches to managing memory, including semantic retrieval, temporal knowledge graphs, and agent-managed memory blocks. Each tool has distinct features tailored to specific use cases, such as personalization, support workflows, or organizational knowledge sharing. Integrating these tools can transform how agents handle long-term memory, but the effectiveness of memory enhancements should be evaluated through comparison tests that assess continuity, error reduction, and task completion across sessions.

Choosing the right LLM red teaming tool depends on the specific lifecycle improvements a team needs, whether it's generating attacks, evaluating immediate responses, or managing ongoing evaluation and release processes. Tools like Garak, Braintrust, Promptfoo, PyRIT, DeepTeam, and Mindgard each offer unique strengths, such as flexible open-source scanning, comprehensive known-risk evaluation, configuration-first workflows, custom multi-turn campaigns, ecosystem integration, and managed security services. Garak excels in attack discovery with its broad probe library, while Braintrust focuses on maintaining confirmed attacks as versioned evaluations. Promptfoo offers a command-line tool that covers both scanning and evaluation, and PyRIT provides adaptive attack strategies for complex scenarios. DeepTeam integrates with DeepEval for seamless adoption within existing ecosystems, and Mindgard offers a managed platform for automated AI security testing. Teams can benefit from combining tools to leverage their strengths across different stages of the security testing process, ensuring comprehensive coverage and maintaining a cohesive evaluation workflow.

Explainability in AI systems varies between model-level and application-level, especially in Large Language Model (LLM) applications, where understanding the entire AI application's behavior is crucial. Application-level explainability involves tracing the execution path, encompassing factors like context retrieval, tool selection, and memory, to identify errors, with tools like Arize Phoenix and Braintrust facilitating this through trace-based evaluations. In contrast, model-level explainability for tabular and vision models focuses on feature attribution methods like SHAP and LIME, which estimate how inputs influence predictions. Token-level attribution in LLMs falls short as it measures influence within a single model call, missing errors originating in earlier application steps. Braintrust emerges as a powerful tool for LLM explainability, linking trace steps with evaluation scores to create a feedback loop for ongoing improvement, while Arize Phoenix offers an open-source alternative. For classical machine learning models, feature attribution remains central, with tools like SHAP, LIME, Fiddler AI, and Captum offering various capabilities for different model types and deployment needs. The choice of explainability tool depends on the specific requirements of understanding either feature contributions or application traces.