Adobe SRE Details Control Plane to Stop Silent AI Agent Failures

Reliability Before Autonomy: Building an AI Reliability Control Plane for Multi-Cloud LLM and — Ai4

Ai4

Traditional infrastructure metrics miss application-layer collapses, requiring enterprises to treat AI autonomy as earned and revocable under multi-tier SLO governance.

AI-assisted summary of Reliability Before Autonomy: Building an AI Reliability Control Plane for Multi-Cloud LLM and — original source. Check the original for full context.

Source published: 2026-08-14

Detailed notes

## Background Published on YouTube by Ai4 on August 14, 2026, this session features Arun Pandiyan Perumal, a Site Reliability Engineer at Adobe. The presentation details how to build an AI Reliability Control Plane for operating production LLMs and agentic AI systems across multi-cloud environments, addressing situations where underlying infrastructure metrics appear green despite catastrophic failures in the AI layer.

## TL;DR Perumal illustrates the AI reliability gap, showing how traditional infrastructure monitoring misses domain-specific failures like model hallucination, cascading tool timeouts, and runaway agent loops. To govern these interconnected failure domains, he details the architecture of an AI Reliability Control Plane that integrates AI gateways, policy guardrails, intelligent multi-cloud workload routing, and automated fallback tiers. Reliability is established across four levels—platform, model, agent, and workflow—utilizing SLIs and SLOs to actively govern performance and token costs. Lastly, he presents autonomy across a spectrum from L0 to L3, arguing that agentic autonomy must always be earned and revocable based on continuous SLO evaluation.

## Atmosphere & style The presentation carries a pragmatic, disciplined, and engineering-centric tone, delivered with the clear authority of a hands-on platform practitioner. Perumal communicates methodically, engaging the audience with grounded questions before diving into structured reference architectures and operational frameworks. The session feels like an architectural briefing inside an enterprise operations center, methodically replacing the false comfort of green infrastructure dashboards with rigorous, end-to-end reliability engineering.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=4s) Traditional infrastructure monitoring is inadequate for AI systems, as platform layers can appear healthy with 200 OK responses while models hallucinate, agents loop endlessly, or outputs degrade. - [01:46](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=106s) The AI reliability gap occurs when standard compute, GPU, and Kubernetes metrics remain green while the application layer experiences silent upstream outages and severe response degradation. - [03:48](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=228s) To prevent cascading failures across tightly coupled components, reliability metrics must be decoupled and measured across four tiers: Platform, Model, Agent, and Workflow. - [06:00](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=360s) The AI Reliability Control Plane sits between client applications and multi-cloud model providers to unify observability, routing, security guardrails, policy enforcement, and SLO tracking. - [08:18](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=498s) End-to-end request pipelines require both pre-inference input filtering and post-generation output guardrails to validate formatting, safety, and semantic correctness before returning results. - [09:09](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=549s) Real-time observability across every pipeline node must be complemented by continuous evaluation to detect longitudinal model drift and assess whether business objectives are being met. - [10:13](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=613s) Intelligent workload routing leverages weighted token/request capacity and latency metrics, shifting degraded endpoints into a cooldown state and cascading to fallback model groups. - [11:54](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=714s) Tool security and cost governance require enforcing least-privilege permissions on agent APIs, immutable audit trails, human approval gates for high-risk actions, and tracking token spend against business value. - [14:03](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=843s) Core operational and economic targets prioritize rapid failure containment, full decision auditability, and optimizing the cost per successful business outcome rather than just raw compute costs. - [14:56](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=896s) AI autonomy exists on a 4-tier spectrum (Observe, Assist, Supervise, Autonomous) and must be earned and revocable, automatically demoting an agent to supervised mode if it breaches SLO thresholds. - [16:05](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=965s) Reliability must be treated as a foundational operating discipline where the quality, correctness, and business value of AI outcomes take precedence over raw infrastructure uptime.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=4s) Introduction and the Illusion of Infrastructure Health

Arun introduces himself as a cloud platform engineer specializing in cloud infrastructure and site reliability engineering. Engaging the audience right away, he asks how many people in the room are familiar with reliability engineering, responding enthusiastically to the show of hands: "Uh great great." His core focus centers on architecting infrastructure systems and AI infrastructure for enterprise business applications, ensuring they are demonstrably reliable under production loads. As AI applications transition from experimental prototypes to increasingly autonomous systems embedded directly into business-critical workflows, standard operational playbooks begin to break down.

The central thesis of the session is that traditional infrastructure monitoring alone is completely inadequate for guaranteeing end-to-end reliability in modern AI workflows. An underlying platform can look entirely healthy on paper while the actual user experience is failing catastrophically. The AI system may suffer from degraded model response quality, silent availability drops, agents trapped in recursive infinite execution loops, or extreme response latency fluctuations. True reliability requires bridging the gap between infrastructure metrics and user-facing AI behavior through a dedicated operational model.

[01:46](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=106s) The AI Reliability Gap: Why Healthy Infrastructure Fails

Addressing the disconnect between operations and AI behavior, Arun outlines the fundamental architectural split. On the infrastructure side, operations teams monitor standard compute layers: Kubernetes clusters hosting AI workloads, CPU and GPU utilization for self-hosted models, and ingress API endpoints that return pristine HTTP 200 OK success responses. Everything appears completely green on infrastructure dashboards.

Yet directly above that healthy substrate, the actual AI workflow can be completely broken. Models can deliver hallucinated or invalid answers, services can suffer silent upstream outages, and autonomous agents can spin out into infinite loops because an underlying tool API failed or timed out. In addition, erratic response latencies degrade downstream tasks. When these AI-specific anomalies occur, traditional monitoring tools register zero alerts, allowing application degradation to impact end-user experience without site reliability engineers noticing.

```mermaid flowchart TD accTitle: The AI Reliability Gap subgraph InfraLayer["Infrastructure Layer (Appears Healthy)"] K8s["Kubernetes Workloads"] Compute["Healthy CPU & GPU Allocations"] APIs["APIs Returning HTTP 200 OK"] end

subgraph AIWorkflowLayer["AI Workflow Layer (Actual Failures)"] ModelIssues["Model Degradation & Output Drift"] AgentLoops["Agents Trapped in Infinite Loops"] ToolOutages["Tool Unavailability & Cascading Latency"] end

InfraLayer -. "Fails to detect".-> AIWorkflowLayer ```

[03:48](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=228s) Cascading Failure Modes and Multi-Tier Reliability Metrics

In production AI environments, components are tightly coupled: foundational models, business applications, agent orchestrators, external tools, and retrieval-augmented generation (RAG) pipelines operate in a chain. If any single component degrades, the issue cascades across the entire system. For instance, if an LLM responds too slowly or becomes intermittently unavailable, request queues back up rapidly—causing queue depth spikes that throttle the entire upstream request path. Similarly, when a dependent tool drops offline, an orchestrating agent will often retry the exact same tool call repeatedly, burning through resources while trapping the workflow in an unrecoverable loop.

To prevent and diagnose these cascading collapses, reliability cannot be evaluated as a single monolithic metric. It must be actively measured and enforced across four distinct architectural levels:

- **Platform Layer:** Tracks raw infrastructure health, endpoint availability, and hardware-level performance such as GPU cluster utilization when hosting private open-source models. - **Model Layer:** Measures generative inference metrics, specifically Time to First Token (TTFT), overall token throughput, and statistical drift in model response characteristics. - **Agent Layer:** Monitors agentic behaviors, focusing on tool execution success rates, retry frequencies, and whether autonomous agents complete tasks without looping. - **Workflow Layer:** Evaluates holistic business outcomes, verifying whether the complete end-to-end operational pipeline achieved its intended enterprise goal.

[06:00](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=360s) Architecture of the AI Reliability Control Plane

To govern these interrelated failure domains, Arun introduces the AI Reliability Control Plane. He defines it as a unified operational and governance layer that enforces reliability policies across diverse models, autonomous agents, third-party providers, and multi-cloud environments. The control plane sits between the upstream data plane—which hosts client applications, APIs, RAG pipelines, and agent frameworks—and the downstream compute/model providers.

```mermaid flowchart TD accTitle: AI Reliability Control Plane Reference Architecture subgraph DataPlane["Data Plane"] ClientApps["AI Applications & APIs"] RAG["RAG Pipelines & Agents"] end

subgraph ControlPlane["AI Reliability Control Plane"] Gateway["AI Gateway (Auth & Rate Limits)"] PolicyEngine["Policy & Guardrails Engine"] Router["Intelligent Workload Router"] SLOEngine["Telemetry & SLO Engine"] end

subgraph Providers["Multi-Cloud Model Layer"] ModelA["Primary Cloud / Model Deployments"] ModelB["Fallback Model Providers"] end

ClientApps --> Gateway RAG --> Gateway Gateway --> PolicyEngine PolicyEngine --> Router Router --> ModelA Router -. "Failover".-> ModelB ModelA -. "Metrics & Traces".-> SLOEngine Gateway -. "Telemetry".-> SLOEngine SLOEngine -. "Dynamic Health Checks".-> Router ```

When a request originates in the data plane, it enters the AI gateway for authentication and initial ingress filtering. It is then evaluated by policy and security guardrails to verify whether the caller is authorized to invoke the requested model and whether the prompt conforms to governance criteria. Once approved, the intelligent router analyzes model availability and cost constraints to select the optimal model endpoint. Simultaneously, a telemetry collection framework pulls traces, logs, and metrics across every layer into an SLO engine, continually evaluating system-wide health and reliability.

[08:18](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=498s) End-to-End Request Flow and Guardrails

The execution lifecycle of an AI request follows a disciplined sequence designed to detect and contain failures before they propagate. Once a prompt enters through the AI gateway and passes authentication, policy checks determine whether the interaction should proceed. The intelligent router matches the task with the appropriate model, passing the prompt to the executing agent or directly to the target LLM.

Crucially, reliability checks do not terminate once the model generates a response. The raw generation passes through output guardrails to validate formatting, ensure semantic accuracy, and check for safety violations or corrupted outputs. If a model endpoint is unreachable, unresponsive, or fails the output criteria, the control plane triggers automated fallback routines to transparently reroute the request to an alternative healthy model. Throughout this entire journey, telemetry continuously records performance data, allowing the platform to adapt dynamically to evolving system behavior.

[09:09](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=549s) Telemetry, Observability, and Continuous Evaluation

Arun draws a clear conceptual distinction between standard observability and continuous evaluation. Observability focuses on the real-time capture of metrics, logs, and distributed traces across every node in the pipeline—from the ingress gateway and policy engine to the routing tiers and external LLM provider endpoints. This telemetry establishes full visibility into the runtime path, answering fundamental diagnostic questions: what happened, where latency was introduced, and how individual components behaved under load.

Continuous evaluation builds on top of observability by analyzing historical telemetry records over time. Rather than merely monitoring real-time uptime, evaluation engines assess whether responses consistently hit target business metrics, whether models are drifting over time, and whether end-to-end task completion satisfies enterprise objectives. This loop converts raw operational telemetry into actionable insights for maintaining application accuracy.

[10:13](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=613s) Intelligent Workload Routing and Automated Failover

The router acts as the dynamic traffic cop of the control plane, distributing inference requests based on configurable policies. Rather than hardcoding calls to a single provider, the router implements sophisticated dispatch strategies:

- **Weighted Pick Routing:** Distributes inbound traffic across models and providers based on predefined capacity thresholds, specifically tracking Tokens Per Minute (TPM) and Requests Per Minute (RPM) rate limits to prevent provider throttling. - **Latency-Based Routing:** Continuously samples response times and automatically shifts latency-sensitive workloads toward the fastest available endpoint.

When an endpoint experiences an outage or severe degradation, the control plane initiates automated failover. The router first looks for alternative approved models within the same primary model group. If an alternative is reachable, traffic switches seamlessly. If all endpoints within the primary group are failing, the router places those models into a "cooldown state"—flagging them as unhealthy to protect upstream callers from queue starvation. The router then cascades traffic down to Fallback Model Group 1, and subsequently to Fallback Model Group 2 if issues persist. If every configured fallback tier is exhausted, the system returns a graceful failure rather than hanging indefinitely.

[11:54](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=714s) SLIs, SLOs, Tool Guardrails, and Cost Governance

Arun emphasizes that Service Level Indicators (SLIs) and Service Level Objectives (SLOs) are the foundational tools for measuring and enforcing AI reliability. SLIs capture precise quantitative behaviors across platforms, models, agents, and overall workflows, while SLOs establish acceptable operational targets. For instance, if an LLM suffers sustained performance drops or extended latency spikes, it directly burns through the model-level SLO budget, alerting operators to intervene before customer workflows are breached.

``` +------------------+-------------------------------------------------------------+ | Governance Layer | Operational Focus & Reliability Function | +------------------+-------------------------------------------------------------+ | Input Guardrails | Ingress inspection to detect and reject malformed, invalid, | | | or malicious prompts at the AI gateway. | +------------------+-------------------------------------------------------------+ | Tool Permissions | Enforcing the principle of least privilege on all external | | | APIs, databases, and capabilities accessible by agents. | +------------------+-------------------------------------------------------------+ | Output Validation| Verifying response accuracy, schema conformity, and output | | | integrity before returning data to the user. | +------------------+-------------------------------------------------------------+ | Audit & Oversight| Immutable logging of all actions, routing high-risk tasks | | | through Human-in-the-Loop approval gates. | +------------------+-------------------------------------------------------------+ | Cost Governance | Tracking token consumption against business value to cap | | | operational expenses and prevent runaway agent costs. | +------------------+-------------------------------------------------------------+ ```

Security guardrails must also be applied directly to agent tools. Requests must undergo strict input inspection at the AI gateway, discarding irrelevant or malicious prompts before they reach downstream models. External tools exposed to agents must strictly adhere to least-privilege access permissions, minimizing the blast radius of any tool-use error. Furthermore, every agent action must produce an immutable audit trail. For destructive or high-risk actions, the control plane incorporates human-in-the-loop approval gates, pausing autonomous execution until human operators approve the operation.

Finally, cost governance enforces operational limits on token usage, tracking spend against concrete business value to prevent runaway financial costs caused by looping agents or unoptimized prompts.

[14:03](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=843s) Target Outcomes Across Operations, Governance, and Economics

When managing autonomous agents, strict guardrails are necessary to inspect unexpected behavior and intervene decisively. If an AI agent attempts to execute an action that is not intended or authorized, the system must thoroughly check the action and kill the rogue process immediately. Establishing this level of supervision directly drives the core operational, governance, and economic target outcomes for an AI Reliability Control Plane.

Operationally, the primary objective is achieving faster failure detection and automated recovery before issues cascade across the infrastructure. From a governance perspective, the control plane ensures comprehensive auditability of every decision made by models and agents, enforcing consistent policies across all components and infrastructure layers. Economically, instead of focusing solely on raw compute spend, the system measures and optimizes the "cost per successful business outcome" alongside overall capacity utilization across multi-cloud components.

- **Operational Health**: Accelerated detection and automated recovery to mitigate workflow degradation. - **Governance & Compliance**: Full audit trails for agent decisions with unified policy enforcement across all AI layers. - **Cost Governance**: Tracking capacity utilization and determining efficiency based on the cost per successful business outcome.

[14:56](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=896s) The Spectrum of Autonomy: Earned and Revocable

Autonomy in AI systems is not an all-or-nothing switch; rather, "autonomy is always earned and revocable." Progressive autonomy can be understood across four distinct tiers:

```mermaid flowchart LR accTitle: Levels of AI Autonomy subgraph HumanDriven["Human Driven"] L0["L0: Observe (AI observes, human acts)"] L1["L1: Assist (AI drafts, human executes)"] end subgraph AgenticControl["Agentic Control"] L2["L2: Supervise (Agent acts, human approves high-risk)"] L3["L3: Autonomous (Agent executes all steps)"] end L0 --> L1 --> L2 --> L3 ```

- **L0 (Observe)**: The AI does not act; humans perform all actions while observing system telemetry. - **L1 (Assist)**: The AI generates drafts or suggestions, and humans use those outputs to execute actions. - **L2 (Supervise)**: The agent takes direct action, but humans remain in the loop to review and approve high-risk operations. - **L3 (Autonomous)**: Complete autonomy, where AI agents are entrusted to perform all end-to-end steps independently.

Advancing an agent to the fully autonomous stage requires continuous evaluation against predefined Service Level Indicators (SLIs) and Service Level Objectives (SLOs). If an agent fails its SLO thresholds or exhibits anomalous behavior, autonomy is immediately revoked, demoting the workflow back to a supervised state where human-in-the-loop intervention analyzes what happened and decides the corrective action.

[16:05](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=965s) Reliability as an Operating Discipline

AI reliability must be established as a foundational operating discipline. Traditional infrastructure health metrics—such as CPU utilization, container uptime, and GPU availability—are necessary prerequisites, but they are insufficient on their own; the actual quality and correctness of the AI outcome matter more than simply keeping servers green.

The AI Reliability Control Plane functions as the central nervous system for every incoming AI request, orchestrating model interactions and managing traffic routing. To ensure resilient, cost-effective, and safe operations, reliability engineering practices must be applied uniformly across all four architectural layers: the model, the platform, the agent, and the complete end-to-end workflow.

## Notable quotes > [00:04](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=4s) Uh great great. — Arun Pandiyan Perumal

> [14:56](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=896s) autonomy is always earned and revocable. — Arun Pandiyan Perumal

## Mentioned Arun Pandiyan Perumal, Adobe, Kubernetes, Ai4

## Video description Arun Pandiyan Perumal - Site Reliability Engineer, Adobe

Production AI systems can appear healthy at the infrastructure layer while model quality degrades, agents loop, tool failures cascade, latency fluctuates, and token costs surge. Across multiple clouds and model providers, probabilistic outputs, tool-use errors, cascading agent failures, variable latency, GPU scarcity, provider outages, cross-cloud dependencies, and escalating token costs can degrade an AI workflow even when every infrastructure component appears healthy. This session will focus on building an AI Reliability Control Plane for operating production LLM and Agentic AI systems in multi-cloud environments. The control plane presents a unified operational layer for service-level objectives, end-to-end observability, model and agent health monitoring, intelligent workload routing, automated failover, policy enforcement, security guardrails, cost governance, and human oversight. Attendees will learn to define reliability indicators and SLOs for models, agents, and complete workflows; detect and contain failures before they propagate; and implement policy-driven routing, fallback, and recovery across clouds and model providers.

[Source](https://www.youtube.com/watch?v=F-EDvj4lHAc)

中文简报

Adobe SRE 详述控制平面，遏制 AI Agent 静默失效传统基础设施指标难以察觉应用层崩溃，要求企业在多层级 SLO 治理下，将 AI 自主权视为需要凭表现获取且随时可撤销的特权。 Perumal 阐述了 AI 可靠性鸿沟，指出传统基础设施监控往往会忽略模型幻觉、工具级联超时以及 Agent 失控死循环等领域特有的故障。为了治理这些相互交织的故障域，他详细介绍了 AI 可靠性控制平面的架构，该架构集成了 AI 网关、策略护栏、智能多云工作负载路由以及自动化回退层。系统在平台、模型、Agent 和工作流四个层级建立可靠性机制，利用 SLI 和 SLO 主动管控性能与 Token 成本。最后，他展示了从 L0 到 L3 的自主性梯度光谱，主张 Agent 的自主权必须基于持续的 SLO 评估来动态获取，并且随时可被撤销。传统基础设施监控无法保障 AI 系统质量，即使 Kubernetes 与硬件指标全部保持 HTTP 200 正常状态，模型仍可能面临输出幻觉、静默中断与智能体（Agent）递归死循环等失效场景。 (1:46) 为防止组件紧密耦合引发级联崩溃，企业必须将可靠性指标彻底解耦，在平台（Platform）、模型（Model）、智能体（Agent）与工作流（Workflow）四个层级分别度量与监控。 (3:48) AI 可靠性控制平面作为多云架构下的统一治理层，集成了推理前后的安全护栏（Guardrails），并能基于 TPM/RPM 权重与延迟实施智能路由、端点冷却及多级自动降级故障转移。 (6:00) 针对 Agent 工具与成本治理，需对外部 API 实施最小特权原则，建立不可篡改的审计追踪，对高危操作强制引入人工审批闸门（HITL），并根据实际业务价值管控 Token 支出。 (11:54) AI 自治权分为 L0 至 L3 四个等级，且遵循“凭表现获取并可随时撤回”的机制；一旦 Agent 跌破预设的 SLO 阈值或发生异常行为，自治权将被立即收回并降级回人工监督状态。 (14:56)

Reading summary

Cloud platform engineer Arun argues that standard infrastructure health checks are inadequate for production artificial intelligence, as systems can appear fully operational while silently failing. To bridge this divide, organizations must deploy a dedicated AI Reliability Control Plane that enforces multi-tiered service-level objectives before granting systems autonomy. The Infrastructure Disconnect and Multi-Tiered Failures (1:46) Standard site reliability practices monitor compute resources such as Kubernetes cluster health, CPU and GPU utilization, and ingress endpoints returning HTTP 200 OK responses. However, Arun observes that an application can appear healthy on operational dashboards while completely breaking at the task level. In AI workflows, underlying services may suffer from model hallucinations, output drift, erratic latency spikes, or autonomous agents trapped in unrecoverable retry loops after an external tool times out. Because these components are tightly coupled, an unresponsive LLM or failed tool rapidly backs up request queues, creating cascading bottlenecks that traditional monitoring fails to flag. To address these interrelated failure modes, Arun asserts that reliability must be measured across four operational layers: the platform layer (compute and GPU hardware health), the model layer (Time to First Token, token throughput, and response drift), the agent layer (tool success rates and execution loops), and the workflow layer (overall enterprise business outcomes). Control Plane Architecture and Dynamic Traffic Routing (6:00) To govern multi-cloud environments and third-party models, Arun outlines an AI Reliability Control Plane positioned between upstream client applications and downstream compute providers. When a request arrives, an AI gateway handles authentication and rate limiting before a policy engine applies security guardrails. An intelligent router evaluates model availability and cost constraints to select the optimal endpoint. System health is continuously evaluated by an SLO engine, which combines real-time observability—capturing traces, logs, and latency bottlenecks—with continuous evaluation of historical data to detect model drift and track task completion rates. The router prevents bottlenecks and outages using adaptive dispatch strategies. Weighted pick routing balances traffic using Tokens Per Minute (TPM) and Requests Per Minute (RPM) thresholds to avoid provider throttling, while latency-based routing directs time-sensitive requests to the fastest endpoint. When degradation occurs, failing models enter a cooldown state, and traffic cascades across primary and secondary fallback model groups. If all fallback tiers are exhausted, the system returns a graceful failure rather than stalling. Guardrails, Least Privilege, and Outcome Economics (11:54) Reliability policies govern both data boundaries and external agent tools. Input guardrails at the AI gateway inspect and reject malformed or unauthorized prompts, while output guardrails validate response formatting, semantic correctness, and safety before returning answers. For autonomous agents interacting with external APIs and databases, Arun stresses the principle of least privilege to restrict the blast radius of operational errors. High-risk or destructive actions trigger human-in-the-loop approval gates, pausing execution until operators approve, while all actions generate immutable audit logs. Cost governance is integrated directly into this operational supervision. Rather than tracking raw compute or GPU spend in isolation, the control plane monitors token consumption against concrete business results. Arun defines the key economic metric as the 'cost per successful business outcome,' ensuring that looping agents or unoptimized prompts do not trigger runaway expenses. Earned Autonomy and Automated Revocation (14:56) Arun defines autonomy as an operational spectrum spanning four tiers: L0 (Observe), where AI observes while humans act; L1 (Assist), where AI suggests drafts for human execution; L2 (Supervise), where agents act autonomously but require human approval for high-risk operations; and L3 (Autonomous), where agents execute complete workflows independently. Under this model, autonomy is 'always earned and revocable.' Systems advance to higher autonomy tiers only by consistently meeting Service Level Indicators (SLIs) and Service Level Objectives (SLOs). If an agent violates latency thresholds, exhibits task loops, or breaches behavioral targets, the control plane automatically revokes autonomy, demoting the agent to a supervised tier for human intervention and corrective analysis. Arun concludes that reliability engineering must function as a prerequisite operating discipline across platform, model, agent, and workflow layers before organizations deploy autonomous systems. The framework relies on continuous evaluation and strict SLO thresholds to prevent cascading failures, demanding that teams actively supervise agent actions rather than relying solely on infrastructure-level availability.

精炼阅读摘要

云平台工程师 Arun 指出，传统的底层基础设施监控已无法保证企业级 AI 工作流的端到端可靠性，必须在数据平面与多云模型层之间构建专用的“AI 可靠性控制平面”。该框架主张在四个架构层级全面量化可靠性，并通过可撤回的分级机制确保自主权以业务结果为约束条件。传统基建健康与 AI 失效之间的脱节 (0:04) 在生产环境中，基础计算设施往往呈现出完全健康的假象。Kubernetes 集群、CPU 与 GPU 分配正常，API 网关持续返回 HTTP 200 OK，然而上层的 AI 交互可能已经出现灾难性故障。这些隐性失效包括模型输出幻觉与结果退化、静默的上游断连、模型端点延迟剧烈波动，以及自主智能体在底层工具调用失败或超时后陷入无限重试循环。由于现有的站点可靠性工程监控工具仅采集底层算力指标，通常不会触发报警，导致终端用户体验恶化而运维人员无法察觉。级联失效风险与四层可靠性指标体系 (3:48) 现代 AI 系统由基础模型、业务应用、智能体编排器、外部工具和检索增强生成（RAG）管道紧密耦合而成。当单一部件退化时，极易引发跨架构的连锁崩溃。例如，若大语言模型响应延迟增加或发生间歇性停机，上游请求队列会迅速积压引发限流；若依赖工具离线，智能体反复重试会浪费计算资源并彻底锁死流程。为此，Arun 主张不能依赖单一的聚合指标，必须建立四个层级的度量体系：涵盖硬件使用率与端点可用性的平台层、衡量首字生成时间（TTFT）与吞吐量及漂移的模型层、追踪工具执行成功率与重试频率的智能体层，以及最终评估企业业务目标达成度的端到端工作流层。 AI 可靠性控制平面的架构与动态路由机制 (6:00) AI 可靠性控制平面作为统一的运行与治理中枢，介入数据平面（客户端应用、API、RAG 管道和智能体框架）与多云模型层之间。请求进入系统后，首先由 AI 网关执行身份认证与流量准入，随后安全策略引擎对输入提示词进行合规检查并应用最小特权权限。通过合规审查的请求进入智能路由器，后者依据基于容量阈值（每分钟 Token 数与每分钟请求数）的加权选择路由策略，或根据实时响应时延将流量分发至最优端点。响应生成后，输出防护栏会验证格式规范、语义准确度及安全性。若主模型组端点全部故障，系统会将其置入冷却状态，自动向下级联切换至备用模型组（Fallback Model Group），直至所有备选耗尽才返回优雅失败，避免请求永久挂起。遥测、持续评估与成本管控的结合 (9:09) Arun 严格区分了实时可观测性与持续评估两个维度。可观测性专注于实时抓取网关、策略引擎、路由节点和外部模型调用链路中的指标、日志与分布式追踪，用于定位延迟和解析运行瓶颈；持续评估则通过分析历史遥测数据，量化模型是否发生行为漂移以及是否长期契合业务目标。这些数据直接输入服务水平指标（SLIs）与服务水平目标（SLOs）引擎，当模型延迟或失败消耗 SLO 预算时自动触发干预。此外，控制平面通过实施输入过滤拦截恶意调用，对高危及破坏性智能体行为设置人工审批闸口（Human-in-the-Loop），并建立不可篡改的审计日志。在经济维度上，系统不再仅仅关注原始算力开销，而是通过跟踪 Token 消耗与交付价值，将核心衡量指标转变为单次成功业务结果的成本及多云算力利用率。分级自主权体系：自主性是可赚取且可撤回的 (14:56) 在 AI 智能体治理中，自主权并非二元开关，而必须遵循“可赚取且可撤回”的原则。系统将自主性划分为四个阶段：L0 观察（AI 仅提供遥测与观测，人类完全掌控执行）、L1 辅助（AI 生成草稿或建议，人类确认执行）、L2 监督（智能体自主执行任务，但高危操作需要人类批准）以及 L3 自主（智能体端到端独立执行完整工作流）。智能体只有在历史运行中持续满足预设的 SLI 和 SLO 阈值后，才能逐步晋升至更高自主阶段。一旦系统检测到行为异常、输出越界或违反 SLO 指标，控制平面会立即终止该异常进程并撤销其自主权，将其降级回监督状态以等待人工干预与故障归因。 Arun 总结认为，AI 可靠性必须作为一项覆盖模型、平台、智能体和工作流四层的核心工程规范来构建。虽然服务器和计算硬件正常是基础，但交付成果的质量与准确性才是衡量可靠性的最终标准；而系统在多云环境下平衡故障恢复、合规审计与以产出为导向的成本控制能力，将直接决定企业智能体应用能否真正实现规模化落地。

Detailed notes — zh

## Background 该视频由 YouTube 频道 Ai4 于 2026 年 8 月 14 日发布，主讲人为 Adobe 的站点可靠性工程师（SRE）Arun Pandiyan Perumal。内容重点探讨了如何在多云环境下为生产级大语言模型（LLM）与智能体系统构建统一的“AI 可靠性控制平面”，以解决基础设施指标正常但上层 AI 工作流与模型质量严重劣化的静默故障挑战。 ## TL;DR 主讲人提出生产级 AI 必须从单一的基础设施监控升级为覆盖平台、模型、智能体与工作流四层维度的端到端可靠性控制平面。该控制平面通过 AI 网关实现安全护栏鉴权，利用基于 TPM/RPM 配额和延迟的智能路由器分发流量，并在故障时触发多级冷却与备用模型故障转移。此外，系统以每次成功业务产出的成本为基准进行经济学治理，并建立了从 L0 观察到 L3 完全自治的分级演进机制，确保在指标劣化时随时撤销智能体自治权并引入人工干预。 ## Atmosphere & style 整场演讲呈现出严谨、务实且深植于工程实战的专业技术峰会氛围，主讲人以冷静敏锐的 SRE 视角直击生成式 AI 运维中的痛点。叙事节奏条理清晰、层层递进，从揭露“底层正常但业务崩溃”的静默故障现象，自然延展至完备的参考架构与分级治理模型。听众能够深刻感受到主讲人对系统稳定性的执着，在追求 AI 自主化的浪潮中，传递出一种“先确保可靠性、再谈自主化”的理性与厚重感。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=4s) 底层基础设施健康不代表上层 AI 系统可靠；即使 CPU、GPU 和 HTTP 状态码显示正常，仍可能发生模型质量劣化、延迟激增或 Agent 死循环等静默故障。 - [00:04](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=4s) 解决 AI 运维痛点的范式是从单纯的基础设施监控升级为具备端到端治理能力的 AI 可靠性控制平面（AI Reliability Control Plane）。 - [02:30](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=150s) AI 系统中模型、外部工具与 RAG 检索管道高度耦合，极易引发级联故障；例如模型延迟会导致队列打满，外部工具离线会导致 Agent 陷入无限重试。 - [05:03](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=303s) 可靠性度量必须跨越四个层级：平台层（资源水位与可用性）、模型层（TTFT 与漂移）、智能体层（工具调用成功率）以及工作流层（最终业务成果）。 - [06:50](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=410s) 控制平面与数据平面明确解耦，请求需依序经过 AI 网关鉴权、策略与护栏审查、智能路由分发，以及输出校验与异常降级。 - [09:09](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=549s) 区分可观测性与持续评估：可观测性解答的是系统内部正在发生什么与链路流转，而持续评估则是对历史数据深度审计以验证长期业务价值达成情况。 - [09:09](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=549s) 智能路由超越了简单轮询，而是根据各模型端点的 TPM/RPM 配额进行加权选择，并结合实时延迟在多云和多提供商之间动态调度负载。 - [10:54](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=654s) 系统具备自动化故障转移机制，当主模型不可用时将其置入“冷却状态”以防流量冲击，并按优先级阶梯平滑下沉至多级降级模型组。 - [11:54](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=714s) 安全护栏与成本控制贯穿请求全周期，包含输入过滤、工具调用的最小权限原则、高风险操作的人机协作（HITL）审批及 Token 消耗监控。 - [14:03](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=843s) 控制平面聚焦三大核心目标：运营层面的故障快速自愈、治理层面的全决策链路审计，以及经济学层面以“单次成功业务产出成本”为核心的算力优化。 - [14:56](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=896s) 智能体自治权遵循“自治权是赚来的，且随时可被撤销”的原则，系统支持从 L0 观察、L1 辅助、L2 监督到 L3 完全自治的四级演进路径。 - [14:56](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=896s) 当线上 SLI/SLO 出现劣化或异常行为时，控制平面会立刻撤销 Agent 的自治权，自动降级并触发人工介入（Human-in-the-Loop）排查故障根因。 - [16:05](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=965s) AI 可靠性必须上升为长期运营准则：基础设施健康只是必要条件，AI 系统最终交付的业务成果远比单纯维持底层资源运转更为关键。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=4s) 引言与核心挑战：为什么单纯的基础设施健康不等于 AI 系统的可靠？主讲人 Arun Pandiyan Perumal 是一名专注于云基础设施和站点可靠性工程（SRE）的平台工程师，在演讲开场时与现场互动，询问有多少人了解可靠性工程。他指出，随着 AI 应用变得越来越自主化，并深度融入企业的关键业务工作流，传统仅监控底层基础设施的运维方式已经完全无法保障端到端的系统可靠性。在生产环境中，经常会出现一种极具欺骗性的现象：底层的 CPU、GPU 和服务器一切看似运行平稳，但上层的 AI 工作流却已经在默默崩溃。这种静默故障的诱因五花八门，可能源于模型输出质量的骤降、模型不可用、响应延迟激增，或者是智能体（Agent）陷入无休止的死循环。Arun 强调，AI 系统的核心目标是支撑最终的用户体验与业务成果，因此只关注基础设施是远远不够的。本次演讲的核心论点，正是要构建一套支持多云 LLM 与 Agentic AI 系统的“AI 可靠性控制平面”（AI Reliability Control Plane），将端到端可观测性、策略执行、模型智能路由以及成本治理统一收敛到一个集中的运营模型中。 - **核心矛盾**：底层基础设施指标（如服务器存活、HTTP 200 返回码）正常，但上层 AI 工作流与模型质量严重劣化。 - **解决范式**：从单纯的基础设施监控，升级为具备端到端治理能力的 AI 可靠性控制平面。 --- ### [02:30](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=150s) AI 系统的复杂依赖与级联故障模式在典型的生产级 AI 架构中，Kubernetes 算力集群托管着自建或私有化部署的模型，底层 GPU 资源与 API 接口可能持续返回 200 OK 的成功状态，但这掩盖了应用层面的深层问题。在 AI 工作流内部，模型可能返回无意义的错误响应甚至完全不可用；智能体可能因为依赖的外部工具失效而停滞不前；请求响应延迟的急剧攀升也会直接摧毁用户体验。 ```mermaid flowchart TD accTitle: AI System Cascading Failure Propagation subgraph S1["组件交互与故障源"] M["AI 模型 (Model)"] T["外部工具 (Tools)"] R["RAG 检索管道"] end subgraph S2["连锁反应机制"] Q["队列积压与限流 (Queue Depth)"] L["Agent 陷入死循环 (Agent Loop)"] end subgraph S3["最终业务影响"] F["业务工作流失败 / 体验崩溃"] end M -- "延迟过高 / 宕机" --> Q T -- "接口失效 / 离线" --> L R -- "上下文异常" --> L Q --> F L --> F ``` AI 生态系统由多个高度紧密耦合的组件组成，包括基础模型、业务应用、Agent 编排器、外部工具以及 RAG 检索管道。这种高度集成的依赖关系极易引发“多米诺骨牌式”的级联故障： - **模型响应过慢或宕机**：会直接导致请求队列深度（Queue Depth）暴增，迅速打满限流阈值并阻塞整条请求链路。 - **外部工具不可用**：Agent 会因为无法获取预期结果而一遍又一遍地重复执行相同步骤，彻底陷入死循环。 - **级联破坏效应**：单个组件的细微异常都会被上游或下游放大，最终破坏整个 Agentic AI 的既定工作逻辑。 --- ### [05:03](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=303s) 多层级可靠性度量体系与控制平面设计针对上述复杂的故障模式，可靠性不能只停留在某一个孤立节点，而必须在平台层、模型层、智能体层和工作流层这四个不同维度上分别进行度量与强制执行： | 架构层级 | 核心关注指标与度量重点 | |:--- |:--- | | **平台层 (Platform)** | API 端点可用性、自建模型托管的底层 GPU 算力健康度、基础设施资源水位。 | | **模型层 (Model)** | 首字元生成时间（TTFT, Time to First Token）、吞吐量（Throughput）、模型响应质量漂移（Drift）。 | | **智能体层 (Agent)** | 工具调用成功率（Tool Success Rate）、既定子任务按期完成率。 | | **工作流层 (Workflow)** | 端到端业务成果达成率、最终交付质量与成功度量指标。 | 为了在多模型、多供应商和多云环境中统一实施上述标准，Arun 提出了“AI 可靠性控制平面”。该控制平面作为一个统一的运营与治理层，集成了 AI 网关（AI Gateway）、端到端可观测性、SLI/SLO 引擎、安全护栏策略以及成本治理功能，负责统筹定义“应该使用哪些模型”和“应当遵守哪些运行策略”，而底层的数据平面则专注于承载具体的 Agent 应用与 RAG 检索工作。 --- ### [06:50](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=410s) 参考架构与端到端请求生命周期在控制平面的参考架构中，系统清晰地拆分为数据平面（Data Plane）与控制平面（Control Plane）。数据平面承载着 Agent 应用、API 接口和 RAG 数据管道，所有发起的推理请求首先进入控制平面： ```mermaid flowchart LR accTitle: AI Reliability Control Plane Request Flow subgraph DP["数据平面 (Data Plane)"] Req["Agent / API / RAG 请求"] end subgraph CP["控制平面 (Control Plane)"] GW["AI 网关 (鉴权)"] Pol["策略与护栏检查"] Rtr["智能路由器 (Router)"] end subgraph Models["模型提供商与多云端点"] M1["主模型 (Primary Model)"] M2["降级模型 (Fallback Model)"] end Req --> GW GW --> Pol Pol -- "审批通过" --> Rtr Rtr --> M1 M1 -. "异常回退".-> M2 ``` 当请求进入控制平面后，其生命周期遵循严格的闭环治理： 1. **认证与策略鉴权**：请求到达 AI 网关完成身份鉴权，由策略与护栏模块判定其调用的模型是否合规、请求内容是否允许被批准执行。 2. **智能路由分发**：获批的请求被交由路由器（Router），根据当前策略选择最佳的可用模型实例。 3. **输出校验与异常降级**：Agent 调用模型执行任务后，输出护栏会对模型返回的内容进行合规与准确性校验；若目标模型无响应或返回异常，系统立即触发回退机制切换到备用模型。 4. **遥测数据闭环**：控制平面底层的可观测性模块持续采集网关、模型及 Agent 的全链路指标、日志与链路追踪（Traces），喂给 SLO 引擎以动态评估全局系统的健康状况。 --- ### [09:09](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=549s) 全链路可观测性、持续评估与智能负载路由系统中的可观测性不仅涵盖静态指标，还深度追踪请求从数据平面经由 AI 网关、路由器、最终抵达模型并返回的全路径。Arun 将可观测性与持续评估的区别进行了精确拆解：可观测性解答的是“系统内部刚刚发生了什么、请求是如何流转的”，而持续评估（Continuous Evaluation）则是对历史可观测记录进行深度审计，以验证系统是否持续达成了预期的业务目标与商业成效。在工作负载路由层面，AI 路由器并非采用简单的轮询，而是根据严苛的策略矩阵进行动态分流： - **加权选择（Weighted Pick）**：严格依据各模型端点的每分钟 Token 数配额（TPM, Tokens Per Minute）与每分钟请求数配额（RPM, Requests Per Minute）进行权重分配。 - **延迟优先路由（Latency-Based）**：动态监控各模型提供商及私有部署端点的实时延迟，将请求分发至响应最快的实例。 - **多云多提供商适配**：在不同的模型部署环境与供应商之间实现动态负载均衡。 --- ### [10:54](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=654s) 自动化故障转移与多级冷却降级机制当路由器将请求发送至选定模型却遭遇不可用时，控制平面会启动自动化的故障转移（Automated Failover）流程。系统首先在当前“主模型组”（Primary Model Group）中寻找其他已通过审批的备用实例，若找到健康实例则请求立即恢复成功。 ```mermaid flowchart TD accTitle: Automated Failover and Cooldown Workflow Start["发起模型请求"] --> TryPrim["尝试主模型组 (Primary Group)"] TryPrim -- "成功" --> Done["请求成功完成"] TryPrim -- "不可用" --> MarkCool["标记为不健康并进入冷却 (Cooldown)"] MarkCool --> TryFB1["路由至降级模型组 1 (Fallback Group 1)"] TryFB1 -- "成功" --> Done TryFB1 -- "不可用" --> TryFB2["路由至降级模型组 2 (Fallback Group 2)"] TryFB2 -- "成功" --> Done TryFB2 -- "全部耗尽" --> Fail["返回最终请求失败"] ``` 如果主模型组内的所有实例均不可用，系统会将这些故障模型标记为不健康，并将其置入“冷却状态”（Cooldown State），防止后续流量继续冲击已崩溃的节点。随后，路由器按照预先设定的优先级阶梯，依次将流量路由至“降级模型组 1”；若降级组 1 同样故障，则继续下沉至“降级模型组 2”。只有当所有预设的降级候选模型全部耗尽时，系统才会向调用方返回最终失败。 --- ### [11:54](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=714s) AI 系统的 SLI/SLO 体系、安全护栏、人机协作与成本治理在可靠性度量层面，SLI（服务质量指标）负责实时量化模型、Agent 和平台各环节的行为表现，而 SLO（服务质量目标）则设定了可接受的目标阈值。若某个模型长时间宕机或性能劣化，将直接消耗该指标的错误预算并触发告警。与此同时，Arun 强调生产环境中的安全防护与成本控制必须贯穿请求全流程： - **输入检查与过滤**：在 AI 网关层严格审查入站请求，果断拦截与业务无关或存在潜在风险的恶意输入。 - **工具授权与最小权限原则**：对 Agent 所调用的外部工具实施严格的身份授权，坚决贯彻最小权限（Least Privilege）原则。 - **输出合规验证与审计**：在模型吐出结果后必须经由输出护栏校验格式与内容合规性，并对系统内的每一步操作留存审计日志。 - **人机协同审批（Human in the Loop）**：针对涉及资金、敏感数据修改等高风险操作，引入强制性的人工审批门禁（Approval Gates）。 - **Token 成本精细化治理**：监控每次业务交付所消耗的 Token 总量，严格控制 AI 系统在多云环境下的总体运营支出。 ### [14:03](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=843s) 控制平面的核心目标：运营效率、全链路治理与业务经济学在构建多云与 Agentic AI 系统的可靠性控制平面（Reliability Control Plane）时，首要的前提是具备进程终止与隔离能力。当 AI Agent 试图执行非预期或异常行为时，系统必须进行详尽的拦截检查，并在必要时果断终止该进程，防止故障扩散。围绕这一防线，控制平面需要实现三大维度的核心目标：运营响应、治理合规与经济效益。在运营（Operations）层面，控制平面的目标是实现更快的故障感知与自动恢复，大幅缩短平均恢复时间；在治理（Governance）层面，系统需要对 AI 做出的每项决策进行完整的审计追踪，并将统一的策略与治理标准贯彻到 AI 基础设施的每一个组件与分层中；而在经济学（Economics）层面，控制平面改变了单纯以基础设施资源计费的传统视角，转向精确核算“每次成功业务产出的成本”（cost per successful business outcome），并据此动态调优整套 AI 基础设施中的容量分配与组件利用率。 - **快速检测与自愈（Operations）**：实现异常行为的毫秒级拦截、进程熔断与跨云故障自动转移。 - **全栈决策审计（Governance）**：针对 Agent 的推理链、工具调用及模型响应进行全链路溯源，实施跨层策略管控。 - **业务价值导向的成本控制（Economics）**：以业务目标的实际达成率为基准，监控与优化 Token 消耗及 GPU 计算容量。 ```mermaid flowchart LR accTitle: AI可靠性控制平面的三大目标 subgraph Operations["运营 Operations"] O1["故障快速检测"] --> O2["进程熔断与恢复"] end subgraph Governance["治理 Governance"] G1["决策审计追踪"] --> G2["跨层策略实施"] end subgraph Economics["经济学 Economics"] E1["单次成功业务成本"] --> E2["算力与容量调优"] end ``` --- ### [14:56](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=896s) 自治权的分级授予与可撤销机制：从 L0 观察到 L3 完全自治在 Agent 架构中，系统必须贯彻一条核心原则：“自治权始终是赚来的，且随时可被撤销”（Autonomy is always earned and revocable）。AI 系统的自主权不是一蹴而就的，而是依据 SLO 与 SLI 指标的持续量化评估，按级别逐步开放： ```mermaid flowchart TD accTitle: AI 系统的四级自治演进模型 L0["L0 观察 (Observe) AI 仅监控，人类执行全部操作"] --> L1["L1 辅助 (Assist) AI 生成草案，人类审核并触发动作"] L1 --> L2["L2 监督 (Supervise) Agent 自主执行日常操作，高危动作需人类审批"] L2 --> L3["L3 完全自治 (Autonomous) AI Agent 自主完成端到端全流程"] L3 -. "SLO/SLI 劣化或异常触发".-> HITL["人工介入 (Human-in-the-Loop) 撤销自治权并介入分析"] ``` 在 L0（Observe）阶段，AI 完全不直接操作，仅进行观察，所有动作均由人类执行；进入 L1（Assist）阶段，AI 负责起草方案或内容，人类利用这些草案手动执行操作；演进至 L2（Supervise）阶段，Agent 已经可以自主执行常规任务，但针对关键的高风险操作，系统会设立审核卡点，必须由人类审批后方可放行；最终到达 L3（Autonomous）完全自治阶段，AI Agent 被赋予端到端自主完成全流程任务的权限。推动系统向高阶自治演进的关键，在于基于 SLI/SLO 体系对 AI Agent 的实际表现进行持续评估。一旦线上监控发现指标异常或行为偏离预期，控制平面必须立刻“撤销 AI Agent 的自治权”，自动降级并将流程回退给人类，启动“人机协同介入”（Human-in-the-Loop）机制，由人工排查故障根因并决定后续恢复动作。 --- ### [16:05](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=965s) AI 可靠性作为运营准则：以业务结果为核心的全局控制平面 AI 基础设施的可靠性必须上升为一种长期的工程运营准则。在生成式与代理式 AI 时代，“基础设施层面的健康只是必要条件，但 AI 的最终业务产出远比单纯维持基础设施运转更重要”（Infrastructure health is necessary, but the AI outcome is more important）。即使底层虚拟机、GPU 容器和网络端口全部显示正常，一旦模型输出幻觉、Agent 陷入无限调用死循环或上下文漂移，整个 AI 流程在业务意义上依然是彻底失败的。 AI 可靠性控制平面正是解决这一矛盾的核心枢纽。它拦截并接管每一次 AI 请求，统一调度底层各类大语言模型与多云资源，并将可靠性工程实践贯穿至模型（Model）、平台（Platform）、智能体（Agent）和工作流（Workflow）的每一个层面，确保 AI 系统在多云与异构环境下既能安全受控，又能稳定交付真实的商业价值。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=4s) 底层的 CPU、GPU 和服务器一切看似运行平稳，但上层的 AI 工作流却已经在默默崩溃。 — Arun Pandiyan Perumal > [00:04](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=4s) 底层基础设施指标（如服务器存活、HTTP 200 返回码）正常，但上层 AI 工作流与模型质量严重劣化。 — Arun Pandiyan Perumal > [09:09](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=549s) 可观测性解答的是“系统内部刚刚发生了什么、请求是如何流转的”，而持续评估则是对历史可观测记录进行深度审计，以验证系统是否持续达成了预期的业务目标与商业成效。 — Arun Pandiyan Perumal > [11:54](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=714s) 针对涉及资金、敏感数据修改等高风险操作，引入强制性的人工审批门禁。 — Arun Pandiyan Perumal > [14:03](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=843s) 当 AI Agent 试图执行非预期或异常行为时，系统必须进行详尽的拦截检查，并在必要时果断终止该进程，防止故障扩散。 — Arun Pandiyan Perumal > [14:03](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=843s) 控制平面改变了单纯以基础设施资源计费的传统视角，转向精确核算“每次成功业务产出的成本”（cost per successful business outcome）。 — Arun Pandiyan Perumal > [14:56](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=896s) 自治权始终是赚来的，且随时可被撤销（Autonomy is always earned and revocable）。 — Arun Pandiyan Perumal > [16:05](https://www.youtube.com/watch?v=F-EDvj4lHAc&t=965s) 基础设施层面的健康只是必要条件，但 AI 的最终业务产出远比单纯维持基础设施运转更重要（Infrastructure health is necessary, but the AI outcome is more important）。 — Arun Pandiyan Perumal ## Mentioned Arun Pandiyan Perumal, Adobe, Ai4, Kubernetes, AI Gateway, RAG, LLM, Agentic AI, SRE ## Video description Arun Pandiyan Perumal - Site Reliability Engineer, Adobe Production AI systems can appear healthy at the infrastructure layer while model quality degrades, agents loop, tool failures cascade, latency fluctuates, and token costs surge. Across multiple clouds and model providers, probabilistic outputs, tool-use errors, cascading agent failures, variable latency, GPU scarcity, provider outages, cross-cloud dependencies, and escalating token costs can degrade an AI workflow even when every infrastructure component appears healthy. This session will focus on building an AI Reliability Control Plane for operating production LLM and Agentic AI systems in multi-cloud environments. The control plane presents a unified operational layer for service-level objectives, end-to-end observability, model and agent health monitoring, intelligent workload routing, automated failover, policy enforcement, security guardrails, cost governance, and human oversight. Attendees will learn to define reliability indicators and SLOs for models, agents, and complete workflows; detect and contain failures before they propagate; and implement policy-driven routing, fallback, and recovery across clouds and model providers. [Source](https://www.youtube.com/watch?v=F-EDvj4lHAc)

Source quotes

[0:04] Arun Pandiyan Perumal: 底层的 CPU、GPU 和服务器一切看似运行平稳，但上层的 AI 工作流却已经在默默崩溃。 [0:04] Arun Pandiyan Perumal: 底层基础设施指标（如服务器存活、HTTP 200 返回码）正常，但上层 AI 工作流与模型质量严重劣化。 [9:09] Arun Pandiyan Perumal: 可观测性解答的是“系统内部刚刚发生了什么、请求是如何流转的”，而持续评估则是对历史可观测记录进行深度审计，以验证系统是否持续达成了预期的业务目标与商业成效。 [11:54] Arun Pandiyan Perumal: 针对涉及资金、敏感数据修改等高风险操作，引入强制性的人工审批门禁。 [14:03] Arun Pandiyan Perumal: 当 AI Agent 试图执行非预期或异常行为时，系统必须进行详尽的拦截检查，并在必要时果断终止该进程，防止故障扩散。 [14:03] Arun Pandiyan Perumal: 控制平面改变了单纯以基础设施资源计费的传统视角，转向精确核算“每次成功业务产出的成本”（cost per successful business outcome）。 [14:56] Arun Pandiyan Perumal: 自治权始终是赚来的，且随时可被撤销（Autonomy is always earned and revocable）。 [16:05] Arun Pandiyan Perumal: 基础设施层面的健康只是必要条件，但 AI 的最终业务产出远比单纯维持基础设施运转更重要（Infrastructure health is necessary, but the AI outcome is more important）。

Source quotes

[0:04] Arun Pandiyan Perumal: Uh great great. [14:56] Arun Pandiyan Perumal: autonomy is always earned and revocable.

Original transcript

[0:04] I am Arun um a cloud platform engineer. I specialize in um cloud infrastructure and [0:10] reliability engineering. So how many people know about reliability engineering? Uh great great. Um [0:17] so I uh focus on building infrastructure systems AI infrastructure and uh for many [0:24] business applications and show whether they are reliable enough or not. Um so [0:29] today uh I'll be talking about how we can build an operating model uh that support and enhance [0:37] um AI reliable infrastructure uh for multicloud LLMs and agent AI systems. [0:47] So um so now like AI applications have been uh becoming more autonomous and they have been being [0:54] integrated into uh business critical workflows, right? So like monitoring the infrastructure [1:00] alone is not in uh sufficient enough to ensure uh an end to-end reliability. Um so if when an [1:08] infrastructure looks good or appear healthy but the model uh the AI workflows can be failing uh [1:15] maybe it's due to the model quality issues or any response issues or availability problems [1:22] agents can go into loops um and then maybe um we may face some uh latency response issues um [1:33] so it's important that how we build uh an infrastructure that is more reliable [1:39] and then how it's um supporting the user experience. Uh [1:46] so um I'll be uh so the central argument is that um so focusing on I mean uh the infrastructure is [1:53] not alone sufficient enough but building uh the uh a model that supports uh AI infrastructure. So [2:02] I'll be focusing on that building a AI reliability control plane uh that supports observability uh [2:09] policy enforcement model routing um and then uh like cost governance that uh supports the um [2:18] the uh the AI infrastructure uh as well as the uh the aenting systems. [2:26] So uh I'll be covering these things. [2:30] So um as as I told you like the infrastructure health uh is alone not important. So if the AI [2:37] workflows is failing uh that can impact the uh the user experience. So on the on the left side [2:43] like if uh I know the it shows the um the models I mean sorry the AI infrastructure components like [2:51] the Kubernetes workloads where we host that AI component AI workflows. uh even if the CPUs GPUs [2:58] will look healthy because if you are hosting any self-hosted models um and you may get like the [3:03] APIs uh retaining like uh 200 success response so these are like uh on the uh infrastructure side [3:10] but on the um AI workflow the the models may be uh not providing a proper response maybe uh becoming [3:19] unavailable uh the agents can go into loops because of some tools may not be uh available [3:25] at the uh we may encounter like response latency issues. Um so these things like uh when uh I mean [3:35] when we if we start facing these issues that impact the overall uh AI quality. [3:48] Yeah. So this shows like what are the failures that we can encounter with the AI systems. So [3:53] uh in if you if you think about like in an AI uh environment uh many components are [4:00] tightly integrated each other like uh the models applications agent orchestrators uh tools rack [4:07] pipelines and if has if any component has issues that can impact the other components performance. [4:15] Um for example uh if if a model uh um is becoming unavailable or it's like it's uh I mean response [4:23] is too slow that can you know trigger a Q death uh like the um the Q the request Q can uh go [4:35] what I say like it it can uh throttle that um the request path and uh if if a agent also [4:43] uh enter into loop that impacts the the workflows [4:48] and uh if a tool becomes unavailable that makes the agent to repeat the steps again and again. [4:54] So these failures can impact the uh the way how the agent should work. [5:03] So the the main important thing like the reliability must be measured and enforced at [5:08] the model agent and the platform levels. So like platform the sense like we we need to cover the [5:15] endpoint uh the infrastructure GPUs I mean GPUs in sense like we are hosting any self-hosted models [5:22] right and for the model like we need to focus on the TTFT the time to uh uh the first token [5:29] um and then like the throughput matters uh and you also need to check for any drift [5:35] with the responses from the model uh and then the agent perspective like we need to focus on [5:41] uh the tool success and then the task whether it's able to complete it regularly or not [5:47] and at last the workflow it it show workflow is nothing but the business outcome [5:52] like how the workflow is completed at the end and how we are measuring measuring the success [5:59] so this is the AI reliability control plane uh it's it's actually a model it it is a uh it is [6:05] an operational and governance layer where we can apply the governance across the models agents, [6:11] providers, clouds, uh and uh it it it actually combines this AI gateway, observability, [6:20] um and SLIS, SLOs's, uh policy, guad rails, uh and then like cost governance. Um so the AI [6:29] reliability control plane defines what models should be used, what policies should be defined. [6:34] Um and then um and then the the data plane that hosts the AI applications, rack pipelines and the [6:43] uh and then the uh other components that requires the AI models to be leveraged. [6:50] So this is a reference architecture. So the the first one is the data plane [6:54] where we have the agents APIs uh the rack pipelines and the request from the data [7:00] plane goes through the AI reliability control plane. So the request gets authenticated uh [7:06] by the AI gateway and then the policy determines like I mean it checks whether the the request is [7:13] does have the uh um like model I mean what model it it requested and what u [7:23] I mean the policy and guarance determines like whether the request should be approved or not in [7:27] the first place and whether the request is approved it goes through the router [7:31] and the router determines like which model is uh uh know can be uh used for that request [7:40] and uh that that's a request flow and uh so the the below part is the the control plane [7:47] I mean the the it has this observability like we collect the telemetry across all the components [7:54] um starting from the AI gateway uh and then the models the reagents and then uh [8:01] with that telemetry like we uh evaluate the health of the infrastructure and also the SLO engine [8:08] that determines and helps us to measure the AI reliability of the entire infrastructure. [8:18] So this is the uh request flow like how it I mean it starts with like uh it enters the AI gateway [8:25] and then the policy determines whether the request needs to be approved or not and then it [8:30] uh routes the request to the appropriate model uh and then the model um I mean and then the AI [8:37] agent picks up the right model and then executes task. So uh and also we also determining whether [8:43] that model response is accurate or not whether we received a proper response [8:48] um and with the help of the output guardrail and then if the model or anything is unavailable [8:55] then we take some uh actions how we can fall back to the available model [9:00] and then we observe and then adapt to like uh how how the workflows is completing. [9:09] So u talk about the end to end observability and evaluations like as I said uh we capture [9:14] telemetry like um the metrics logs traces across all the components within this [9:21] uh control plane and then we trace that request how the request flows starting from uh the data [9:27] plane that enters into the AI gateway flows through the router and then goes through the uh [9:33] the model uh and then how we get the response back from the model and analyze it and how we [9:40] uh know determine the reliability of the uh entire infrastructure. [9:46] Um here the observability part helps us to determine like what happened, how it has [9:51] happened and how the request behaved well and the continuous evaluation part like it it actually [9:57] evaluates the history of the observability record. it it helps us to determine like whether [10:04] we are achieving the desired outcome and whether we are meeting the business uh outcomes for that. [10:13] So it is the AI workload routing how the work uh router works. So when the request comes to the AI [10:20] gateway uh the policy checks for the request and sends to the router and the router um routes a [10:26] request based upon these routing strategies like waiter pick it is based waiter pick is based upon [10:32] the TPM and RPM like TPM is like token per minute or the RPM is a request per minute uh rate limit [10:39] where some the other one is latency based. So these are the strategies that router follows to [10:45] route the request to the appropriate models uh provider and uh and then the model deployments. [10:54] Yeah, this one is uh important thing like automated failure. So a router sends a [10:59] request to a model but that model seems to be unavailable, right? So what happens next? Like [11:05] the I mean it checks for the other approved models within that primary model group. If that second [11:11] the uh the other model is available then the request gets success. If it is if the models [11:16] are not available in the primary model group then it uh since I mean what it does like it [11:21] puts the models in cooldown state like it it um I mean it marks us like the those models [11:27] are unhealthy and then what it does it goes it routes a request to the fallback model um [11:34] and if that models in that fallback model group one is not available and it and then routes a [11:39] request to the group two. So the it goes up like the the number of models that we define and if [11:45] any of the models are not available it will uh the options will exhaust and then the request failure. [11:54] Uh at last this I mean the SLI SLOs's for AI system. So we define the SLI SLOs's for [12:01] platform model agent and the workflow. Um so the SLIS and SLOs's are the primary uh components used [12:09] to measure the AI reliability. So the SLI helps us to measure the behavior of a model agent platform [12:18] and the SLOs's will set up the t acceptable target like if the if a model goes uh down for a [12:27] a longer period of time then that impacts the model um SLI met SLO metric. [snorts] [12:37] Yeah. security guardrails um like for for the tools that use AI. So it's important that [12:44] whatever the request that comes through the AI gateway, we inspect that input. [12:48] Um if something that is not relevant, it should be rejecting that input request [12:53] and then we also need to authorize the tools that the A8 needs to use like it the tools [12:59] needs to follow the lease privilege permissions. Um and also important that we need to validate [13:04] the model output like we route the request to the appropriate model but we al we need to [13:08] ensure that the we are receiving the proper output from the model and at last like it [13:14] is important to uh audit every action. Uh if it is something like uh high-risk uh request [13:21] uh and then we can use uh we can involve in a human in the loop process to approve that request. [13:30] Um at last the uh sorry the cost governance um here the cost governance helps us to control the [13:37] AI operating cost. Um and I mean we generally focus on the tokens um how how how we measure [13:45] the to number of tokens used for um an AI outcome. Um and also um on the uh human hover side we also [13:55] need to uh you know integrate or incorporate the approval gates for the high-risk actions [14:03] and if something uh an AI agent requires to do something that is not intended where that that [14:09] needs to be checked thoroughly and then if it's required we need to kill that process. [14:17] So what are the target outcomes here? Uh based on operations like you know we would we can [14:22] get like faster direction and recovery. Um and from the governance point of view we can audit [14:28] the decisions made and that and also uh we can apply the governance across all the components or [14:36] the layers within that AI infrastructure. From the economics point of view, uh we determine how how [14:42] um like the we determine the cost per successful business outcome [14:49] and then also like the capacities or the components used within the AI infrastructure. [14:56] So uh this one like is out of this um so autonomy is always earned and in revocable. If you check up [15:03] the the the L0 the observe part here the AI is not doing something like humans act L1 assist like AI [15:12] drafts something and the AI and the human use uh the AI drafts to execute an action. So uh L2 like [15:19] supervise here agent tax but humans will approve those high-risk actions and at loss is like [15:25] complete autonomous like we give everything to AI agents to perform all the steps. Um and then [15:33] um so how we push that to autonomous stage like we continuously evaluate the uh performance of the AI [15:41] agents uh based upon the SLO SLI metrics. uh if something goes wrong like we need to revoke that [15:50] autonomous from the AI uh agents um and then we need to involve the human in the loop process [15:57] to analyze like what's happened and then uh determine like what what is the next action. [16:05] So uh at last like uh I mean so the the reliability uh for uh an AI infrastructure [16:12] should be an operating discipline. So the infrastructure health is necessary [16:17] but the AI outcome is more important than like maintaining the infrastructure. [16:23] So here the AI reliability control plane u is the central part uh kind of uh for every [16:30] uh AI request. Um and that manages the uh the um every model. Um and then uh I mean also it uh [16:41] takes care of uh managing the AI request and it is also important that we uh know apply the um [16:51] the um reliability practices across the model platform agent and workflow. [16:58] Yep. Thank you. And any questions apart from this?