Context Engineering — Your AI Agent Has the Data. So Why Is It Getting Things Wrong?

A barge dispatcher has a problem. Her company deployed an AI agent to help assign vessels to missions. It has access to the fleet database, the mission queue, and the route schedule, and it produces recommendations in seconds. A meaningful share of those recommendations fail at execution anyway: a vessel that turns out to be already committed, a departure window that conflicts with a lock closure the agent did not account for, a weight assignment just over the regulatory limit for that stretch of river.

The agent had the right data and drew the wrong conclusion from it. This is the most common failure mode in operational AI, and it is widely misdiagnosed as a data or model problem.

The problem is not the data. It is what the data lacks.

Operational data describes facts in isolation: a barge’s capacity, a mission’s tonnage requirement, a lock’s schedule. What it usually does not describe is how those facts relate to each other and what those relationships constrain. An experienced dispatcher does not look at the three facts separately — she knows, from the relationship between them, whether this barge on this route through these locks satisfies the assignment. That relationship is not in any single record.

An AI agent retrieving those three records and reasoning about them without the relationship between them is pattern-matching across fields that happen to share a context window, not reasoning within a governed model of the operation. The output looks the same either way. The reliability does not.

What an ontology is, in plain terms

The fix is a governed model of the operation — an ontology, though the word does more harm than good in most conversations. In practical terms, it is the precise, enforced answer to three questions every operations team already answers implicitly: What kinds of things exist here? (barges, missions, routes, not “entities” in the abstract). What relationships between them are valid, and what do those relationships mean? (a barge allocated to a mission is committed — its capacity and time window are consumed). What rules govern what is allowed? (a barge’s committed tonnage cannot exceed its regulatory limit).

A schema tells you what data can exist. An ontology tells you what is operationally valid and why, encoded so the platform enforces it — rather than something an agent is told in natural language and expected to apply correctly every time.

That model is organized in three layers that build on each other: concepts define what exists and what’s valid (the typed grammar of the domain); facts are the live state — every actual barge, mission, and allocation, validated against the concepts layer the moment it enters; operations — the tasks, decisions, and process instances — are generated from the live facts and bounded by the concepts layer, so an operation that would contradict current reality or violate a constraint cannot be created in the first place.

Two properties fall out of this that determine whether an AI roadmap holds up in production: the agent always reasons from the current, validated state of the world at the moment it acts — not a stale export — and every action it takes, human or AI, lands in the same record, auditable without a separate reconciliation step.

Function-calling schemas (the kind most AI APIs offer today) are a real improvement over unconstrained output, but they only validate that one call is well-formed — they cannot know that a resource committed in one call is being proposed again in the next, because that depends on live state the schema itself doesn’t track. Structural enforcement at the model level closes that gap: the constraint isn’t checked after the agent proposes, it isn’t available to propose against in the first place, and where it would be, the platform can return exactly what was violated so the agent can revise instead of failing silently.

What this requires, honestly

Building this structure deliberately is harder up front than pointing an agent at existing systems and letting retrieval do the work. It requires real domain knowledge to encode correctly, and an ongoing obligation to keep the model current as the business changes. For operations with reasonably stable rules, that cost is bounded. For operations where the rules change constantly, keeping the model current is a real, recurring line item — and worth budgeting for rather than discovering later.

What to ask when evaluating a platform

Three questions cut through most comparisons. Where do constraints live — in a prompt that drifts, or in the model itself, enforced before the agent reasons? What does the agent inherit when a step is created — records it has to assemble meaning from, or a governed context that’s already structurally complete? Is the audit trail shared, or is AI activity a separate log someone has to reconcile by hand?

Next — Step 3: Agent-Human Interactions, on how AI and human workers actually share a task, and why chat is the wrong default for teams.

Sources

1. Process Metronome — Platform architecture — /platform
2. Process Metronome — Fluvial Logistics Case Study — /industries/fluvial-logistics
3. LangChain — State of AI Agents — langchain.com/stateofaiagents