Operationalizing agentic AI: The Day 0-2 blueprint for enterprise infrastructure

Your agent works. It reasons, calls tools, and returns answers in the demo that impress everyone. But between that notebook and a production deployment sits a gap having nothing to do with your model or your framework. Three failures hit a single AI agent deployment overnight—43 duplicate tickets, $4,000 charged to the wrong account, and a hallucinated refund policy leading to a $280 return the company had to honor. The agent ran on LangChain. It worked perfectly in staging. Every failure was an infrastructure failure, not an intelligence failure.

I've watched teams spend months closing that gap by hand—wiring identity, bolting on tracing, building bespoke governance. Some give up and move to a hyperscaler platform offering a guided path from experiment to production. They get the path. They also get the lock-in. Bring your own agent (BYOA) is Red Hat AI's approach: the platform provides production infrastructure for any agent framework without code changes. The question isn't whether your agent needs production infrastructure, it's how your team gets there.

The answer is a 3-phase journey.

• Day 0: Experiment without risk
• Day 1: Deploy with infrastructure injected automatically
• Day 2: Operate with observability and governance running continuously

This article follows a team through each phase using Red Hat's own production agents as proof the platform works, because the most credible evidence is that Red Hat deploys its own production agents on this platform.

Day 0: Find out if it works before you commit

Day 0 answers the question: will this work for our use case? The goal is to answer it before committing engineering resources to operationalization.

Gen AI studio (a governed sandbox within Red Hat AI for experimenting with models, agents, Model Context Protocol (MCP) servers, and guardrails before deployment) provides the Day 0 environment. A team can point an agent at different open-weight models running on vLLM (a self-hosted inference engine providing OpenAI-compatible endpoints), connect MCP servers to see what tools the agent can reach, and apply NVIDIA NeMo Guardrails to test safety behavior—all in a governed space where experiments don't touch production data or production infrastructure. I think of it as the lab bench: real reagents, real equipment, no risk of contaminating the production line.

For teams that know which framework they want, starter kits provide the Day 0 starting point. Preconfigured templates for LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK, and more ship with Red Hat AI platform integration already wired. The agent connects to vLLM for inference and to MCP Gateway (an Envoy-based proxy, currently in tech preview, governing tool access via token claims rather than prompt content) without the team writing integration code. These aren't "hello world" demos. They include the platform integration patterns—authentication, MCP connection, tracing initialization—teams would otherwise spend weeks building from scratch.

For the decision maker, Day 0 is where the risk is lowest. Experiments in gen AI studio use governed resources with no production impact. The investment before Day 1 is 1 team, 1 sandbox, and controlled cost. For the developer, the starter kit code is the same code running in production. Nothing gets thrown away at the boundary between experimentation and deployment.

Day 1: Deploy without rewriting

The infrastructure from Day 0 experimentation carries forward. Day 1 is where the agent moves from sandbox to production—and where the platform takes over the hardest part.

A developer packages their agent as an Open Container Initiative (OCI) container (the standard container format used across cloud-native infrastructure—the same format as Docker images), writes an AgentCard (a machine-readable description of the agent's capabilities and tool requirements), and deploys it to Red Hat OpenShift AI. From there, OpenShell (an open source agent runtime developed in collaboration with NVIDIA) will handle operationalization automatically—wrapping the agent in a protected sandbox including identity, policy enforcement, and security observability, all without requiring changes to the developer's original agent code.

OpenShell wraps the agent and provides the production infrastructure the developer never wrote:

• Cryptographic identity via Secure Production Identity Framework for Everyone (SPIFFE) / SPIFFE Runtime Engine (SPIRE) (a standard for giving each agent a verifiable digital identity that can't be faked or shared)—so every action traces back to a verified identity. The OpenShell supervisor issues SPIFFE JSON Web Token SPIFFE Verifiable Identity Document (JWT-SVID) tokens and supports OAuth2 client assertion flows using the agent's SPIFFE identity.
• Distributed tracing via MLflow (an open source platform for tracking agent execution) and OpenTelemetry (OTEL) (a standard for collecting observability data)—so every reasoning step, tool call, and model invocation is recorded. OpenShell sandboxes export OTEL traces via configurable collector endpoints.
• Tool governance via MCP Gateway—so tool access is controlled by token claims, not prompt content.
• Sandboxed execution via Kata Containers (hardware-isolated container execution giving each agent its own kernel) and OpenShell's application-level sandboxing (kernel-level filesystem isolation via Landlock, syscall filtering via seccomp, network namespace isolation, and in-process Open Policy Agent (OPA) policy enforcement)—2 independent layers of defense, each holding even if the other fails.

The developer will write none of this. OpenShell provides it as a platform concern, not a developer concern. The agent never sees raw credentials—the OpenShell supervisor proxy intercepts API calls and injects credentials at the network boundary.

I keep coming back to this shift because it's the most consequential in the series: on hyperscaler platforms, developers write agents to the platform's security model. On Red Hat AI, developers write agents. The platform brings the security model to the agent. The code a team wrote on Day 0 is the same code running in production. No refactoring. No platform-specific software development kit (SDK) imports.

For the decision maker, every agent deployed through OpenShell will have identity, tracing, and governance as minimum requirements—not as optional add-ons individual teams may or may not implement. The security posture will be consistent across every agent in the fleet. For the developer, the framework migration that teams dread never happens.

Day 2: Operate what you deployed

Deployment isn't the finish line. Day 2 begins after the first deployment and doesn't end. This is where the real work of running agents at scale lives—and where the 6 AM incident would have been caught before it became a crisis.

Ask yourself: Can you answer these questions about your deployed agents right now?

• Which agents called which tools in the last 24 hours?
• What did each agent spend on inference—and is that number trending up?
• Has output quality changed since the last model update?
• If an agent produced a bad result overnight, can you reconstruct exactly what happened?

If the answer to any of these is "no," Day 2 operations are the gap. MLflow tracing and evaluation (covered in depth in "AI agent observability: Building a production-grade operational layer") run continuously in production. Cost tracking surfaces anomalous spend before it becomes a line-item surprise. Large language model (LLM)-as-Judge evaluation (a technique where a capable LLM scores another model's outputs for quality and faithfulness) flags output quality regressions before users report them.

The $4,000 wrong-account charge from the 6 AM incident would appear as a spike in per-agent cost metrics—caught by Day 2 operations, not discovered on Monday morning when someone reviews the invoice. The 43 duplicate tickets would show up as an anomalous burst of identical tool calls in the trace data. I've seen teams discover agent failures from customer complaints filed days after the fact. Day 2 operations don't prevent every failure. They make failures visible, bounded, and diagnosable—in minutes, not business days.

The MCP catalog (currently in developer preview) already provides a discovery layer for tools: teams can find which MCP servers are available, what capabilities they expose, and how to connect. An agent registry (planned for Red Hat AI) will extend that discovery to agents themselves—other teams will find a deployed agent by capability, review its AgentCard, and delegate work to it without building a parallel capability. The MCP lifecycle operator (currently in developer preview) manages MCP server deployments alongside the agents that consume them. What one team builds becomes a reusable organizational capability—the network effect turning individual agents into an agent-capable organization.

Red Hat runs its own agents on this platform

The most persuasive evidence a platform works is the people who built it use it. Red Hat runs production agents on the same infrastructure this series describes. Three of these illustrate the range.

The autonomous SRE agent

The Ambient/Agentic Framework is Red Hat's policy-driven AI agent living inside the Red Hat OpenShift cluster. It detects issues via Prometheus alerts, spawns analysis sub-agents capable of spawning further sub-agents for parallel investigation, executes remediation in a sandboxed environment, runs verification steps to confirm the fix worked, and escalates to human engineers when policies require it.

Every capability from this series shows up in a single agent: orchestration, sandboxed tool execution, human-in-the-loop approvals, observability, and identity. The same platform infrastructure powering an autonomous site reliability engineer (SRE) agent can support a human resources (HR) onboarding assistant, a procurement approval workflow, or a customer service escalation bot—the infrastructure is domain-agnostic even when the use cases differ.

The developer's agent

Red Hat Developer Lightspeed provides AI-assisted pipeline authoring, code refactoring, and onboarding guidance directly in the developer workflow. It connects to OpenShift MCP servers accessible from VS Code, Cursor, GitHub Copilot, and Claude Desktop. A developer queries live cluster state and troubleshoots deployments without leaving their IDE.

The agent knows the cluster because the platform provides the capability to scope its MCP server access via token-based policies—not because someone gave it broad credentials and hoped for the best. By default, MCP server access leverages the developer's kubeconfig credentials; the governed, scoped access requires configuring MCP Gateway to enforce identity-based filtering.

The sovereignty agent

SOS Clean AI operates within Confirmed Sovereign Support (Red Hat's premium in-region operational service keeping diagnostic data, support interactions, and personnel access within a defined geographic region). Regionalized AI agents perform multipass review and sanitization of diagnostic data before any snippets can leave the regional boundary. All AI processing stays within the jurisdiction. I find this especially compelling because it's the same platform infrastructure—identity, sandboxing, guardrails—applied to Red Hat's own support operations. The agent protecting your sovereignty is itself sovereign.

The conditions that make agents trustworthy

The production gap was never about building better agents. It was about building the conditions those agents require before they deserve trust. These are the conditions trustworthy AI requires in practice—the same properties the EU's Ethics Guidelines for Trustworthy AI and the NIST AI Risk Management Framework identify as requirements: transparency, accountability, robustness, human oversight, and privacy. The difference is they're enforced by infrastructure, not promised by policy.

The teams succeeding with agents at scale aren't the ones writing the best agent code. They're the ones who stopped treating production infrastructure as an afterthought and started treating it as the reason agents become trustworthy in the first place. That's a platform problem, not a model problem, and not a framework problem.

You bring the agent—your LangChain agent, your CrewAI agent, your custom Python agent. Red Hat provides the production infrastructure. Every layer runs on your infrastructure, under your jurisdiction, with your audit trail—the sovereignty that makes the shift from renting AI to owning it real. Your agent already works. Now it can work in production.

Get started

Your Day 0 starts now. Here is where to begin:

• Try OpenShift AI free in the Developer Sandbox—models, agents, MCP servers, and guardrails preconfigured
• Start with the BYO Agent starter kits—preconfigured templates for LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK, and more with Red Hat AI platform integration
• Walk through the agentic AI interactive demos—MCP servers, vLLM, and end-to-end agent deployment
• Start the OpenShift AI learning path—hands-on tutorials from model serving to ML pipelines
• Read the full Red Hat AI documentation—platform reference for everything covered in this series
• Red Hat AI and OpenShell: Driving security-enhanced agent execution for enterprise AI—OpenShell integration with Red Hat AI for secure agent execution
• Bringing Claude self-hosted sandboxes to OpenShell on Red Hat AI—coding agent sandboxing with OpenShell
• Deploying agents with Red Hat AI: The curious case of OpenClaw—step-by-step agent deployment with 3 inference paths
• Explore Red Hat digital sovereignty solutions—sovereignty across your full infrastructure stack
• Take the Digital Sovereignty Readiness Assessment—establish your organization's sovereignty baseline