AI Agents Internals — The AI Agent Is Not the System
Most AI project failures are instruction failures or context failures, not model failures. Here is what actually determines whether an agent is reliable — and how to evaluate a platform for it.
Six months into a pilot, the pattern is familiar. The system produces confident recommendations. And in a consistent fraction of cases — one in four, sometimes higher — the recommendation cannot be executed. A resource that was already committed. A constraint the agent did not account for. A window that had closed by the time the proposal reached the dispatcher.
The model gets blamed. Someone suggests trying a different one. That is the wrong diagnosis.
An AI agent has three components
An AI agent running in a production system is not a model. It is a system with three distinct parts: the language model (the reasoning engine that turns a described situation into output), the instruction set (what the agent is supposed to do), and the context (what it knows about the current state of the world).
These parts are not equivalent. Reasoning capability across frontier models has converged — the model is broadly a commodity. The differences between reliable and unreliable AI deployments live almost entirely in the quality of the instructions and the quality of the context. That is where the evaluation question should focus.
Why instructions and context are usually the weak point
Instructions delivered as a prompt are fragile. A prompt is a textual description written at a moment in time by someone who had to make explicit a set of rules that were previously implicit. It drifts from the operation it describes as that operation changes, until no one is certain which one the AI is actually following.
Context delivered as retrieved data has a matching problem. Retrieval returns facts, but the constraint that makes a recommendation invalid is rarely inside any single fact — it lives in the relationship between them: a resource already committed, an allocation that exceeds a window, a route that requires clearance a query would not surface. An agent reasoning over isolated facts can produce output that sounds right and is not.
What changes the failure pattern
The fix for both problems is architectural, not a bigger model. Instead of a prompt, the space of what the agent can do is constituted directly from its position in the operational system: valid moves are structurally expressible, invalid ones simply are not options. Instead of retrieved records, the agent reasons over a governed model of the current state — typed entities, live positions, and the constraints that relate them — so the structure that makes a recommendation valid or invalid is present before the agent reasons, not discovered after it proposes.
This structural envelope is what a harness provides: a governed layer, defined once, that every invocation of the agent operates inside. It is also stateless by design in a useful way — the agent itself holds no memory between invocations; the durable record of what is true right now lives in the operational model underneath it, not in the agent’s own memory of past conversations.
What this means for how you evaluate AI platforms
Two questions matter more than most feature comparisons. How are instructions delivered — a prompt whose reliability depends on who wrote it and how current it is, or a structure the platform derives fresh each time? And what does context carry — isolated records the agent has to interpret, or a governed model that already enforces the constraints?
The model is not the system. The instructions and the context are the system. Evaluating AI platforms by model quality alone is optimizing the wrong component.
Next — Step 2: Context Engineering, on why agents with good data still get things wrong, and how to fix it at the architectural level.
Sources
- Process Metronome — Platform architecture — /platform
- Mikhail Gorelkin — From Hallucinations to Categorical Machines — medium.com/@magorelkin