KM

Context Architecture: Designing AI Systems That Know What to Question

Published 6 min read
  • AI
  • AI agents
  • AI tooling
  • Compliance

A mature AI system knows which rules are fixed, which decisions are provisional, and when evidence requires review. Context architecture makes that distinction explicit, owned, traceable, and operational across the lifecycle.

Context Architecture: Designing AI Systems That Know What to Question

The strongest agentic systems will not be the ones with the longest instruction files. They will be the ones that know the authority of what they have been told.

An agent should know that it cannot expose a credential. It should know that a production database choice is current, not eternal. It should know that a proposed research workflow is a hypothesis. And it should know when observed evidence should be escalated to a person who can change the system.

I call that context architecture: the deliberate design of the information that surrounds a model, including its source, authority, freshness, and route for review.

This is the practical conclusion of the series. Awareness before architecture is the principle. Context architecture is the operating model.

Context has to carry more than instructions

Most agent context answers a single question: what should the model do?

That is necessary but insufficient. Reliable systems also need to answer:

  • Why does this rule exist?
  • How certain are we that it is still right?
  • Who owns the rule?
  • What evidence could challenge it?
  • What happens if the agent encounters a conflict?

Without those answers, every piece of context is forced into a false binary. It is either followed as a permanent command or ignored. Real systems need a third option: follow the current decision, record the conflict, and route it to review.

A practical context record

Every consequential instruction should have five fields.

Field Question it answers
Authority Is this a hard constraint, operating principle, decision, or hypothesis?
Rationale What problem was it meant to solve?
Evidence What supports it, and what evidence is missing?
Owner Who may approve a change?
Review trigger When or why should it be reconsidered?

The record can live in a decision log, policy registry, or structured section of repository context. The format matters less than the behaviour it enables.

A model does not need to read every historical decision for every task. Progressive disclosure is better. Give it the hard constraints and task-relevant current decisions by default. Make supporting rationale and open hypotheses available when it needs to investigate a conflict.

That keeps the context useful instead of turning it into a dumping ground. It also gives agents a basis for explaining why they stopped, escalated, or recommended a different approach.

Here is the level of detail that is usually enough for one record:

Decision: Use the approved public-source database as the first research step.
Authority: Current architectural decision, not a constitutional constraint.
Reason: It provides auditable coverage for the questions currently in scope.
Owner: Research systems lead.
Review trigger: Three material unanswered questions in one review period, or a source-quality failure.
Escalation: Report the gap and request approval before using an additional source.

This is not a prompt template. It is an accountability template. The agent receives an actionable instruction, while the people maintaining the system retain the reason, boundary, and route for changing it.

The review loop is part of the product

Context architecture requires a live review loop:

  1. Define the system goal and hard boundaries.
  2. Record architectural choices as choices, with evidence and owners.
  3. Mark hypotheses as unproven and attach a review trigger.
  4. Monitor execution for exceptions and unexpected outcomes.
  5. Let exploration produce bounded recommendations.
  6. Update the record only through accountable human decisions.

The loop is deliberately conservative. An agent does not gain the power to rewrite its own constitutional constraints. But its observations can improve the architecture around it.

This draws the correct line between guardrails and assumptions. One protects the system from unacceptable action. The other remains available for evidence-led review.

What to review first

Most teams do not need to rebuild their entire context layer at once. Start with the instructions that have the most authority or the largest downstream effect:

  1. Tool permissions and destructive-action controls.
  2. Rules that decide where the agent may obtain information.
  3. Assumptions that determine workflow routing or model choice.
  4. Definitions of success, completion, and escalation.
  5. Any sentence that begins with “always,” “never,” or “must” but does not identify its rationale.

For each one, ask whether it is truly a hard boundary. If it is, make its authority explicit and ensure it is enforced beyond plain text where possible. If it is not, give it an owner and a review trigger. This is how a static set of instructions becomes an architecture capable of learning.

Where context architecture lives

This is not an argument for putting every decision in one enormous AGENTS.md file. Good context architecture is distributed, but connected.

Hard controls should live where they can actually be enforced: permission systems, tool confirmation steps, secret handling, scoped credentials, and approval gates. Durable working principles can live in repository instructions or a shared operating guide. Architectural decisions belong in a decision log close to the code they affect. Hypotheses and experiments belong in a review queue, where they are visible without being mistaken for policy.

The agent should receive a concise, task-relevant view of that system. It does not need the entire organisational archive in its prompt. It needs to know the boundary it cannot cross, the decision it should currently follow, and the escalation route if the task exposes a conflict. Supporting material should be discoverable when a review task calls for it.

This separation also makes maintenance less fragile. Updating a hypothesis does not require editing a safety policy. Retiring an implementation choice does not erase the rationale for why it existed. A new human contributor can trace how a rule moved from experiment to decision, or why it was removed.

Context is often described as something a model consumes. In a mature system, it is also something the organisation curates. That is where accountability lives: not in the model’s confidence, but in the evidence and ownership behind the information it is asked to trust.

What this changes in practice

For a coding agent, it means AGENTS.md stops being a flat list. It becomes a map of non-negotiables, current repository conventions, active decisions, and open questions. AGENTS.md is not just documentation explains why that matters.

For a research agent, it means sources, confidence, gaps, and escalation criteria are first-class outputs, not apologetic footnotes. For a business workflow, it means an agent can follow the approved path while reporting when the path produces recurring failure.

For leadership, it changes the question from “how autonomous is the agent?” to “what can this system decide, what can it challenge, and who remains accountable for the answer?”

A system that keeps learning without losing control

The false choice is between rigid automation and unbounded autonomy. Context architecture offers a better balance.

Make the safety boundaries firm. Make the operating principles clear. Make the architectural choices visible. Make the hypotheses reviewable. Make dissent evidence-based. Keep a human accountable for changing the rules that shape future decisions.

A mature AI system does not only know its rules. It knows which rules it is allowed to question.

References