Enterprise agent systems have matured enough that the interesting problems are no longer about access or intelligence. Retrieval works. Tools execute. Models reason well enough. What now differentiates serious deployments is something more prosaic and harder to fake: whether the system can be trusted to act inside an organization shaped by policy, risk, precedent, and drift.
This is why the concept of “context graphs” entered the conversation, and why they matter. The recent framing is precise. Context graphs are not knowledge graphs. They are decision trace graphs. They preserve what mattered at decision time so that justification, precedent, and accountability do not dissolve into chat logs.
That is a meaningful advance. It is crucial to include historical decisions, exceptions, and edge cases when making decisions about how to act. But over the last year, when actually implementing enterprise wide production systems, we quickly found that it is not the end state.
The mistake many teams make is subtle. They correctly observe that decision traces are consulted during agent reasoning, and then quietly slide from “informs action” to “authorizes action.” Once that line is crossed, the architecture starts to accumulate risk in ways that only appear months later.
What follows is the perspective that emerged when we treated decision traces as advisory reasoning surfaces, and deliberately placed authority elsewhere.
Why The Context Graph Concept Invites Overreach
In practice, the strongest solutions in this area are active participants in agent reasoning. They are queryable during planning and execution in order to surface precedent, exceptions, constraints, and prior approvals. Used this way, decision traces materially improve reasoning quality. They ground agents in organizational memory, reduce hallucination, and make decisions legible after the fact. This is precisely what makes the graph concept so tempting to treat as a source of authority. Graph nodes look executable. They encode conditions, actions, and rationale. It is easy to slide from “this informs what we should do” to “this permits us to do it.”
That slide is where risk accumulates. A true context graph would preserve what mattered at decision time, but would not enforce what is valid now. When allowed to authorize action, three failure modes reliably appear. Precedent outlives policy because time is represented but not enforced. Rare exceptions become reusable templates as agents optimize for citation rather than validation. As graphs grow richer, systems become better at justifying actions than at checking whether they are still allowed. These are not flaws in graph design. They are the natural outcome of treating memory as control.
Separately, in our practical experience, we found that trajectories solve a different and equally important problem. A trajectory is the time ordered trace of how work actually unfolds, including goals, actions, failures, escalations, overrides, and outcomes. Reasoning over trajectories shifts agents away from inventing plans and toward reproducing successful ones. Recovery improves because failure patterns are visible. Planning becomes empirical rather than speculative. But trajectories are descriptive, not normative. They explain how work gets done here, not what is permitted to run.
Behavior Before Permission
The missing primitive is executable authority. Rather than storing justification as narrative memory, we embedded it into time versioned units of execution - skills. A skill is not a suggestion. It is an enforcement point. Each skill defines the action it permits, the preconditions that must hold, the authoritative sources it may consult, and the subsequent deterministic validations that must be passed, including business rules, policy constraints, and risk controls. It also specifies any approvals or exceptions required, the evidence that must be emitted, and the window in which the skill is valid. Skills are evaluated synchronously at execution time and fail closed. If the rules no longer pass, the policy no longer applies, or the justification has expired, the action does not run. This is the moment where “why” stops being an explanation and becomes control.
Time bounding is the property that turns governance from an aspiration into a system behavior. Without it, organizations slowly accumulate what we came to think of as precedent rot. Temporary workarounds harden into defaults. Policy interpretations linger long after their intent has expired. Nothing breaks loudly, but authority quietly drifts. By contrast, a time bound skill expires in the open. It must be refreshed from sources, revalidated against policy, or deliberately replaced. Drift becomes visible and actionable instead of silent. Decision traces remain invaluable in this process because they preserve the history of how and why decisions were made. But they can only observe drift. Skills are what stop it.
When combined deliberately, the division of labour becomes clear. Different primitives serve different roles, and problems that once felt entangled separate cleanly. Trajectories ground agents in how work actually succeeds by exposing real sequences of action and recovery. Decision traces ground reasoning by preserving precedent, rationale, and explanation. Skills sit at execution time and decide what is allowed to run now, under current conditions. Agents consult all three continuously, but only one has the authority to say yes. This resolves a tension many teams feel but rarely articulate. Decision traces (or implementations of context graphs) should absolutely influence what an agent proposes to do. They simply should not be the thing that permits it.
From Reasoning to Control
The enterprise choice is straightforward. Either reasoning is allowed to imply permission, or permission is enforced independently of reasoning. Only one of these scales safely. Systems built on trajectories and skills are much easier to transition from prototype to production, and far harder to break once they are there.