The agent ran in the demo. It answered questions, called tools, produced structured output. Two weeks into production: it accumulated context until the responses degraded, invoked tools without validating inputs, lost state between runs, and had no mechanism to escalate when it encountered something outside its training. The post-mortem identified the root cause as “LLM limitations.” The actual root cause: the team built the agent by giving a model access to tools, and called that a system.
It was not a system. It was an LLM with API keys.
The Category Error Causing Agent Failures
When an enterprise team builds an agent by connecting a model to tools and prompting it to figure out the rest, they have delegated system design to the model. The model will decide what context to retain, when to call which tool, what constitutes success, and whether to stop. It will make those decisions inconsistently, because those decisions require deterministic rules, not language modeling.
The 12-Factor Agents framework, developed by Dex Horthy at HumanLayer, names this the category error: treating the LLM as the system rather than as one component in a system. The reframe: the model generates tokens (and nothing else). Deterministic code executes tools, validates state, manages context, persists results, and decides when to pause or escalate.
This reframe changes what you build. It also changes how you debug it. When an agent fails, the question is no longer “what did the model do wrong?” The question is “which component failed, and which software test would have caught it?”
The Core Principle: Own the Loop
Every agent is a loop: observe, think, act. Observe means read context, including current state, previous tool results, relevant memory, and anything else the model needs to reason about. Think means plan the next action given the goal and the observed state. Act means execute the action, whether a tool call, a file write, an API request, or an output.
Owning the loop means making every part of that cycle explicit and controlled by software, not implicit and delegated to the model.
Own what enters the observation window. The model reasons over what is in the context window. Context window contents should be assembled by deterministic code that loads exactly what this step requires. Not “here is everything, model, figure out what matters.” Framework magic that injects memory, conversation history, and tool results implicitly produces context windows that are unpredictable in production and impossible to debug when the model degrades.
Own the structure of the thinking step. Chain-of-thought, scratchpad reasoning, structured output schemas, and output validation are all mechanisms for making the thinking step produce inspectable, testable outputs. A model that writes unstructured text before taking action is harder to validate than a model that produces a structured decision object.
Own the constraints on action. Every tool call should be preceded by schema validation. Every action with consequences should be preceded by a reversibility classification. Some actions should require human approval before execution. These are software components, not model behaviors.
For enterprise: owning the loop also means owning the audit trail. Which context window produced which decision, at which step, in which run. That is a compliance requirement in regulated industries, not a logging convenience.
The Most Useful Factors for Production
The full 12-Factor framework is available in the source material. The factors that most directly prevent the failure modes observed in enterprise deployments:
Own prompts token by token. Know exactly what is in the context window at every step. No implicit injection. If a framework is adding memory, history, or tool results to the context without explicit instruction, that is a production risk. “The framework handles context management” is a sentence that should produce concern, not reassurance.
Assemble context explicitly. Load only what is needed for this step. A research step needs web search results and a goal statement. It does not need the full conversation history, the user’s profile, and the contents of three other documents. Context bloat degrades quality and increases cost. The context window is a resource, not a scratchpad for everything that might be relevant.
Treat tools as typed schemas plus deterministic code. Define input and output schemas for every tool. Validate inputs before execution. Test tools independently from the agent loop. A tool that writes to a database should be testable without running the entire agent. If the tool cannot be tested independently, it is not a tool. It is undifferentiated code with an API.
Separate execution state from business state. The agent’s progress through steps (which step it is on, which tools it has called, which outputs it has produced) is execution state. The business object being modified (a purchase order, a customer record, a compliance finding) is business state. These live in different places. Conflating them makes state recovery after failure complex and error-prone.
Keep agents small. Three to ten steps with clear entry conditions and clear exit conditions. Agents with 30+ steps and open-ended loops are debugging nightmares. When the task requires more than ten steps, it is almost always decomposable into two or three smaller agents with a handoff protocol.
Summarize errors before reinjecting. When a tool call fails, the raw exception trace consumes tokens and frequently confuses models. Compress the error: “tool X failed because Y; the last three attempts produced Z.” Give the model structured information about failure, not a wall of stack trace.
Human approval as a system component. For high-stakes or irreversible actions, human approval is not an exception path added when something goes wrong. It is a designed step in the workflow, with a defined approval interface, a defined timeout policy, and a defined escalation path. Build it before you need it.
MCP as Governed Tool Infrastructure
Model Context Protocol (MCP) is the standard for exposing tools to agents as governed, versioned, auditable connectors. MCP defines how an agent discovers tools, calls tools, and receives results, with authentication, schema validation, and audit logging built into the protocol layer.
As of December 2025, MCP was donated to the Agentic AI Foundation under the Linux Foundation, now co-governed by Anthropic, OpenAI, Google, Microsoft, and AWS. Over 10,000 MCP servers are active, with 97 million monthly SDK downloads. MCP has become the de facto standard for agent tool connectivity, not a vendor-specific solution.
For enterprise: MCP transforms every tool into a governed interface with defined scope, authentication, rate limiting, and an audit log for every invocation. Instead of each agent making direct API calls with its own auth management and its own error handling, MCP provides a shared infrastructure layer. Permissions are managed at the MCP layer, not replicated per agent.
The risk worth naming directly: MCP without governance is a well-labeled attack surface. Every MCP server connecting to production systems needs explicit whitelisting, authentication, and audit logging. The April 2026 discovery of an RCE vulnerability class in MCP protocol design reinforced that MCP servers, like any software component, require security review and patching. The existence of a standard does not substitute for security practices.
LangGraph for Enterprise Agent Orchestration
For agents that require state management, branching, human-in-the-loop steps, and parallel execution, LangGraph provides an explicit state graph where every state transition is visible, pausable, and resumable.
The architectural distinction that matters for enterprise: LangGraph is stateful. The agent’s execution state persists between steps. If an agent pauses for human approval, the state is preserved. If an agent fails mid-execution, the state can be inspected and resumed. This is not the default behavior of most agent frameworks.
Production adoption includes deployments at Cisco, Uber, LinkedIn, and JPMorgan as of 2026. The platform is not experimental.
LangSmith, the associated observability platform, traces every step of agent execution: what was in the context window, which tools were called, what they returned, and how long each step took. For enterprise deployments where explaining agent behavior to a compliance team is a requirement, LangSmith provides the trace. Langfuse is the self-hosted alternative for data-residency-sensitive environments.
When Not to Use an Agent
Most tasks that are proposed as agent workflows are better served by deterministic automation or a single LLM call.
An agent is appropriate when: the task requires multiple heterogeneous tool calls where the sequence is not fixed in advance, intermediate results inform which tools to call next, and the space of possible paths through the task is not enumerable before execution begins.
An agent is wrong when: the task follows a fixed procedure, the tools are always called in the same order, and every execution takes the same path. That is a workflow automation. Zapier, n8n, or Trigger.dev handle it more cheaply and more reliably than an agent. The model adds cost and non-determinism without adding intelligence.
The diagnostic question from the 12-Factor framework applied as a pre-build gate: does this task require language understanding at decision points, specifically to decide which action to take next? Or does it just require automation of a fixed sequence?
If the honest answer is automation, build automation. The agent framing will make it more complex to debug, more expensive to run, and harder to explain when something goes wrong.
Multi-agent architectures apply the same logic one level up: more agents is not more intelligence. The decision is whether the task structure actually requires it.
For enterprise teams evaluating where agents create genuine value versus where they add complexity without return, the AI Opportunity Sprint maps the decision.