Why your AI agent framework isn't enough: 7 platform capabilities missing from production

Your agent works. I know it does. You built it on LangChain or CrewAI or something custom, you tested it against real scenarios, and it handled them. The problem isn't the agent. The problem is everything around it.

In "Why good AI agents fail in production: The missing infrastructure layer," 3 failures hit a single AI agent deployment overnight—43 duplicate support tickets, $4,000 charged to the wrong billing account, and a hallucinated refund policy that led to a $280 return the company had to honor. That agent worked perfectly in development, but broke in production because the production infrastructure was insufficient. The gap between a working agent in development and a production-ready deployment isn't a framework problem—it's an infrastructure problem.

This article uncovers that gap. I'll talk about:

• 7 specific capabilities no framework currently ships
• Where your framework stops
• Why 3 common workarounds fail
• What actually helps close the gap—without asking you to rewrite your agent

7 things your framework doesn't ship

The 6 AM incident exposed 3 failures. But those 3 are symptoms of a broader set of missing infrastructure. When I map production agent failures across organizations, the same 7 gaps appear every time.

1. Cryptographic identity

Cryptographic identity provides verifiable proof of which workload is making a request, with identity attributes that determine which services it can reach. The $4,000 wrong-account charge happened because the agent ran with broad credentials that were never scoped for production. A large language model (LLM) picked the wrong account identifier, and nothing in the infrastructure stopped it. With cryptographic identity, the platform constrains which services the agent can reach, and properly configured downstream APIs enforce which parameters are valid for a given caller. The model might still select the wrong identifier, but the potential impact  is bounded—the damage is limited to resources within the agent's authorized scope, not every account in the system. For decision makers, this is the difference between "one account was affected" and "every account was exposed."

2. Execution sandboxing

Execution sandboxing provides hardware and application-level isolation so a compromised or misbehaving workload can't reach the host operating system or affect other workloads. This isn't unique to agents—any workload needs isolation, but agents make it urgent because they operate autonomously, calling APIs and executing tool actions at machine speed. Without sandboxing, one workload's failure becomes every workload's failure on the same machine. An agent that can write to the filesystem or open network connections outside its scope is a liability the security team will never approve for production.

3. Tool governance

Tool governance is infrastructure-level policy determining which tools an agent can call, enforced at the network layer so no prompt injection (a technique where malicious input tricks an agent into performing unintended actions) can bypass it. I've seen teams try to enforce tool access through prompt engineering., but it doesn't hold. A determined adversary—or a sufficiently creative model—routes around prompt-level restrictions. Governance belongs in the infrastructure, not the prompt.

4. Observability and tracing

Observability and tracing include full execution traces capturing every prompt, tool call, and intermediate result. All 3 failures in the 6 AM incident went undetected until customers and invoices surfaced them. With full execution traces, each failure would have been visible before a customer reported it. For developers, this means debugging a multistep agent interaction the same way you debug a distributed microservice call. For the business, it means audit trails that satisfy compliance reviewers.

5. Continuous evaluation

Continuous evaluation provides production scoring of agent outputs against policy and ground truth so regressions surface before customers report them. The hallucinated refund policy—the agent telling the customer the return window was 90 days instead of the actual 30—reached a customer because no evaluation layer checked the output against the real policy. Static test suites catch what you anticipated, continuous evaluation catches what you didn't.

6. Safety enforcement

Safety enforcement provides guardrails at the inference boundary that intercept output before it reaches customers, databases, or downstream agents. In the example where an agent failed 3 times in a day, the framework routed the model's fabricated response directly to the customer without any check. Safety enforcement makes the inference boundary a checkpoint, not a pass-through.

7. Lifecycle management

Lifecycle management includes deploying, updating, scaling, and retiring agents across a fleet with a consistent operational and security posture. One agent is a project, but 10 agents across 3 teams is an operational challenge. Without lifecycle management, each team invents its own deployment process, its own security model, and its own update cadence. Consistency disappears.

Where your framework stops

Consistency across those 7 capabilities is what production demands. So where do the frameworks you already use actually leave you? LangChain and LangGraph give you chains, agents, tool calling, structured output, graph-based orchestration, session memory, and retrieval integration. The composability is genuinely strong. CrewAI gives you multi-agent coordination, role-based agent design, task delegation, and crew orchestration, and the multi-agent patterns are well thought out. Google ADK integrates tightly with the Google ecosystem. Claude Agents bring reasoning depth. Strands (AWS) provides AWS-native workflow integration.

Each framework excels at the agent loop—the cycle of perceiving, reasoning, and acting that makes an agent an agent. Not one provides cryptographic identity or execution sandboxing. Tool governance at the network layer is absent. Production-grade distributed tracing, continuous evaluation, safety enforcement at the inference boundary, and fleet lifecycle management don't exist in any of them.

This isn't a criticism, it's simply a category distinction. Frameworks are application-layer tools, but the 7 capabilities I listed are platform-layer concerns. Expecting your framework to ship them is like expecting Django to ship Kubernetes—container orchestration is infrastructure, not application logic, and it would be unreasonable to expect a web framework to include it. The same applies here. The layers are just different.

If you've tried to deploy a LangChain agent with proper identity, tracing, and governance, you've felt this already. You end up writing more platform integration code than agent code. The agent was the easy part.

3 approaches that don't scale

If the agent was the easy part, teams still need to solve the hard part. Every team I talk to has tried at least one of these approaches before looking for a platform answer.

Building it yourself. Teams write their own identity injection, tracing integration, and deployment scripts. For 1 agent, this works. It's even satisfying because you understand every piece. At 10 agents across 3 teams, each team has its own security model, its own tracing format, and its own deployment process. There's no consistency and no governance, just a growing maintenance burden that pulls senior engineers away from the agents themselves. I've watched teams spend more time maintaining their homegrown platform glue than building agent capabilities.

Hosted agent platforms like Salesforce Agentforce, AWS Bedrock Agents, or Azure AI Agent Service remove the production gap by owning the entire stack. The tradeoff is that they also own the data path. Every prompt, every tool call, every reasoning artifact routes through a third-party service. In regulated industries—where the data must not leave your network—this is a non-starter. And when the platform changes pricing or deprecates a feature, your agents have to change with it.

Framework-specific extensions offer production-oriented add-ons within a single ecosystem—LangSmith for tracing is a good example, and it's genuinely useful. But an organization running LangChain, CrewAI, and custom agents now needs 3 separate production stories. That means 3 tracing formats, 3 security models, and 3 sets of tooling for teams to learn. The production infrastructure should be framework-agnostic, not another thing locked to a single vendor's ecosystem.

Each approach solves a piece of the problem while introducing a new constraint. The first doesn't scale. The second trades sovereignty for convenience. The third fragments the production story across framework boundaries.

Your agent, Red Hat's platform

The constraint every approach shares is the assumption that production infrastructure must come from the same place as the agent framework—or be built from scratch. I think that assumption is wrong. BYOA (bring your own agent)—Red Hat AI's approach where the platform provides production infrastructure for any agent framework without code changes—starts from the opposite premise.

Red Hat doesn't compete at the framework layer. Whether your agent runs on LangChain, CrewAI, Claude Agents, Google ADK, Strands, or custom Python, Red Hat AI operationalizes it. The agent code your team wrote in development is the same code that runs in production. Identity, sandboxing, tool governance, tracing, evaluation, and lifecycle management are injected by the platform—not written by the agent developer. And the production infrastructure is consistent across every framework in the organization.

For decision makers, this means the organization's investment in its chosen framework isn't stranded. Teams don't choose between their preferred framework and production infrastructure that supports compliance with whatever regulatory restrictions they face,  they get both. The platform brings production infrastructure to the framework, not the other way around.

BYOA is also the shift from renting AI infrastructure to owning it. Red Hat identifies 4 pillars of digital sovereignty: data sovereignty, technology sovereignty, operational sovereignty, and assurance sovereignty. The BYOA platform addresses all 4, which we'll talk about in upcoming articles.

The same platform infrastructure that powers 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.

Red Hat ships starter kits for LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK, and more with platform integration already wired—authentication, Model Context Protocol (MCP) connection, and tracing initialization. Teams start building on Day 0, not after weeks of integration work.

The decision you already know how to make

Day 0 instead of weeks—that framing should sound familiar. A decade ago, organizations faced the same question with containers: every team could build a container, but nobody could run containers in production with consistent security, networking, and lifecycle management across the organization. The answer was not "pick a better container runtime," the answer was Red Hat OpenShift—a platform that operationalized any container runtime with the infrastructure the runtimes didn't ship. What we're discussing here sounds familiar because Red Hat AI runs on top of it.

The agent gap has the same shape. The question isn't "which framework should I use." You already made that decision, and it was probably the right one. The question is "who provides the production infrastructure my framework doesn't ship"—and the first gap to close is the one where the distance between development and production is widest. That is security, and our next article picks up there.

Get started

Ready to close the production gap for your agents?

• Try OpenShift AI free in the Developer Sandbox: build and test agents in a preconfigured environment at no cost.
• Explore the BYO Agent starter kits: Pre-configured templates for LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK, and more.
• Take the free Red Hat AI Foundations course: Hands-on labs covering the fundamentals of building on Red Hat AI.
• Learn about Red Hat AI: Platform overview and production infrastructure capabilities.
• Operationalizing BYOA on Red Hat AI: The OpenClaw edition: See BYOA in practice with a real agent deployment.