Raman Varma, founder and CEO of Kestrel AI, published an operational framework in Forbes Business Council arguing that CTOs deploying AI agents into production infrastructure are applying the wrong evaluation model. The distinction: a chatbot that gives an engineer a bad answer creates confusion. An agent with production access can create downtime and security issues costing millions of dollars, according to the Uptime Institute’s 2025 Annual Outage Analysis.
Varma’s central point is that most AI agent evaluations focus on response quality, measuring whether the agent understood the prompt or generated a useful answer. For production infrastructure, that metric is insufficient. The question is not whether the agent’s answer is plausible, but whether the action is safe and recoverable.
What Agents Actually Touch
Production AI agents interact with Kubernetes clusters, IAM policies, infrastructure-as-code modules, deployment pipelines, cloud networking, secrets, and databases. These systems are interconnected: a bad production rollout triggers customer-facing downtime, an overly permissive IAM change increases the blast radius of a security breach, and a networking change can break inter-service communication.
Varma argues CTOs should evaluate AI agents like production automation, requiring boundaries, identity, and auditability, rather than as productivity software. He cites NIST’s AI Risk Management Framework, organized around govern, map, measure, and manage functions, as a model for determining where agents can act and how their risk should be monitored.
The Four Principles
The framework rests on four deployment principles:
Scoped permissions. Every agent should have its own identity rather than borrowing a human admin’s credentials. A properly scoped agent might read logs, metrics, and deployment history but can only recommend fixes or open pull requests that require human approval. High-risk agents that can change network policies, delete resources, or rotate credentials need additional controls.
Observability. Black-box operational agents produce investigation trails showing relevant alerts, logs, metrics, deployment events, and dependencies. Remediation agents show proposed commands, code fixes, and configuration changes before applying them. Post-action monitoring checks whether the incident improved, stayed the same, or worsened.
Compressed detection and investigation. The goal is not to replace site reliability engineers but to reduce the time from detection to safe remediation. Varma argues the slowest part of incident response is not human intelligence but that relevant context is scattered across disconnected tools. Agents consolidate that context, shifting the human role toward judgment, policy setting, and deciding which remediations become permanent improvements.
Operational discipline. Start with read-heavy workflows and low-risk actions, then expand agent autonomy after implementing approval gates and audit trails. Cutting agents off from production entirely is not the answer; granting access while preserving least privilege, auditability, reversibility, and accountability is.
Context for Agent Builders
The framework arrives as agent deployments are moving from productivity tools to production infrastructure at speed. The 2024 DORA State of DevOps Report documented measurable benefits of AI across cloud operations workflows, but the shift from summarizing tickets to executing infrastructure changes introduces a category of risk that most enterprise governance models were not designed for. Varma’s framework is practitioner guidance, not a standard. But the checklist it proposes, treating agents as operational actors that need the same discipline as CI/CD pipelines and human engineers, matches the pattern emerging across enterprise deployments.