Guardrails Are Not Assumptions: A Context Hierarchy for AI Agents

One of the easiest mistakes in agentic design is to flatten every kind of instruction into a single category called rules.

That makes a system feel organised, but it hides an important difference. Some rules protect people. Some describe a current technical choice. Some are guesses about a future product. They should not all be obeyed, reviewed, or changed in the same way.

The distinction is especially important once an agent can use tools or take actions. OpenAI’s agent guidance treats instructions, guardrails, and tools as separate parts of the system. That separation is not cosmetic. A tool tells an agent what it can do. A guardrail tells it what it must not do. Neither should be confused with an untested belief about how the application ought to be built.

Four levels of context

I would organise an agentic system around four levels.

1. Constitutional constraints. These include privacy obligations, legal limits, secret handling, approval for destructive actions, and spending authority. The agent cannot casually reconsider them. A human may revise them through a formal process, but the runtime system treats them as hard boundaries.

2. Operating principles. These are durable standards such as cite important claims, preserve user intent, log consequential actions, or escalate material uncertainty. They can evolve, but not task by task.

3. Architectural decisions. These record the present arrangement: a particular database, model routing approach, storage layer, evaluation method, or service boundary. The agent usually follows them, but an exploration process may recommend a change with evidence.

4. Hypotheses and temporary choices. These are explicit bets: a dedicated research agent may improve quality; one retrieval approach may be enough; this prototype tool may be the right fit. They need an owner and a review date.

The difference can be summarised simply: a guardrail constrains behaviour because crossing it creates unacceptable risk. An assumption guides behaviour until evidence says it should not.

The cost of getting the levels wrong

Treat an assumption like a guardrail and you get rigidity. The agent keeps defending an obsolete pattern because the context tells it that the pattern is the world.

Treat a guardrail like an assumption and you get risk. An agent may discover a convenient way to act that violates a privacy boundary or sends an irreversible request without the required approval.

Neither error is fixed by a better model. Guardian agents explains why runtime oversight is necessary when agents have power to act. But oversight cannot compensate for a context layer that has failed to say what is actually non-negotiable.

NIST’s AI Risk Management Framework is helpful here because it treats governance as cross-cutting, rather than as a last check after the system is built. The framework’s map, measure, and manage functions are not a license to hard-code every early answer. They are a reminder that context, impact, and risk need to be revisited throughout a system’s lifecycle.

A review mechanism, not a revolt mechanism

Giving a system permission to question an architectural assumption does not mean giving it permission to rewrite production on a whim.

The practical pattern is a recommendation path:

1. The execution agent follows the current architecture.
2. The exploration agent or reviewer identifies a conflict, gap, or better alternative.
3. It presents evidence, tradeoffs, and scope of change.
4. A designated human approves, rejects, or defers the decision.
5. The context record is updated with the result.

That preserves operational reliability and makes learning possible. It is the system version of separating research from deployment.

Make every important rule answerable

For each context item, record its level, rationale, owner, evidence, and next review trigger. A review trigger can be a date, a failed evaluation, a security incident, a change in cost, or a product requirement that no longer fits.

This is a more useful idea than a giant instruction file because it lets the system know which questions are closed and which questions are still alive. AGENTS.md is not just documentation explains why that status has to be visible to the model as well as to the humans maintaining it.

An example of the hierarchy at work

Take a research agent working on a commercial decision.

It may have a constitutional constraint not to expose private customer information. It may have an operating principle to cite primary sources for material claims. It may have a current architectural decision to search an approved public database before the open web. And it may have a hypothesis that a dedicated retrieval system will eventually improve coverage.

Those four statements lead to four different responses. The first cannot be bypassed. The second is a quality requirement. The third should be followed in normal execution but surfaced if it repeatedly fails to answer valid questions. The fourth should inform an experiment, not quietly become a procurement decision.

When all four are written as “always do this,” the agent loses the ability to represent the difference. When they are labelled, both the agent and its human operator can reason about the correct next step.

The hierarchy also improves evaluation. You can test whether a system respects constitutional constraints. You can audit whether it follows operating principles. You can measure whether an architectural decision is still producing the desired outcome. And you can decide whether a hypothesis has earned promotion into a real decision. These are different tests, and they should not be collapsed into one score for “agent quality.”

References

• OpenAI, A practical guide to building agents
• NIST, Artificial Intelligence Risk Management Framework 1.0
• Related on this site: Guardian Agents, AGENTS.md Is Not Just Documentation