Article 2026-07-24

Executable Context

AI coding tools are becoming more capable of acting independently.

They can inspect repositories, generate code, modify infrastructure, select libraries, create APIs, run commands, execute tests and review implementations.

As they become more capable, they also receive more context.

Repositories contain code.

Agents have instruction files.

Documentation can be retrieved.

Policies can be placed into prompts.

MCP servers and other tools can expose additional information.

The problem is no longer simply: how do we give the AI more context?

The more useful question is: how do we determine which context should influence this particular decision?

This is where architecture becomes important.

The Context Problem

Organisations contain enormous amounts of information that could theoretically be supplied to an AI agent.

That information may include:

  • security policies
  • standards
  • architecture documents
  • regulatory requirements
  • control catalogues
  • coding standards
  • cloud standards
  • threat models
  • risk assessments
  • previous architectural decisions

Giving all of this to every agent for every task is neither practical nor necessarily desirable.

More context is not necessarily better context.

The agent needs information relevant to the work being performed.

That may depend on:

  • the component being changed
  • the assets involved
  • the data being handled
  • the trust boundaries being crossed
  • the technology being used
  • the security objectives that apply
  • the organisational policies relevant to those conditions

Architecture provides a way to determine those relationships.

From Architecture to Context

Architecture already provides contextual information about a system.

An Architecture Model may tell us:

  • this component is an API
  • this asset contains confidential information
  • this connection crosses a trust boundary
  • this workload is internet-facing
  • this component executes in AWS
  • this identity is privileged

Security analysis can add objectives.

For example:

Customer Data -> Confidentiality: High

Policy can then determine what that means:

Confidentiality: High + Database -> Encryption Required

That can become Executable Context for an implementation task:

This database stores confidential customer information. Encryption at rest is required. Use the organisation's approved encryption mechanism. Do not create an unencrypted storage resource.

The context presented to the agent has therefore been derived from the architecture rather than being an arbitrary prompt.

Architecture can determine which context matters.

Executable Knowledge vs Executable Context

In Architecture as Executable Knowledge, I described architecture as more than static documentation.

Architecture as Executable Knowledge is the broader idea of representing Architectural Intent, security analysis and policy in a structured, machine-consumable form.

Executable Context is what happens when the relevant portion of that knowledge is selected for a particular task or decision.

Executable Knowledge is what the architecture knows. Executable Context is what the agent needs to know now.

Conceptually, the relationship is:

Architecture -> Executable Knowledge -> Executable Context -> Action -> Evaluation

Executable Context means structured, task-relevant context that can actively guide, constrain and evaluate the actions of humans and AI agents.

Executable does not mean the context itself is source code.

It means the context participates directly in an activity rather than existing only as passive documentation.

For AI-assisted software development, Executable Context might contain:

  • Architectural Intent
  • security objectives
  • applicable policies
  • required controls
  • constraints
  • implementation guidance
  • rationale
  • evaluation criteria

The important distinction is between having information and putting the relevant information into action at the point where a decision is being made.

Executable architectural knowledge makes it possible to determine the context. Executable Context puts it to work.

Context Should Preserve the Why

Executable Context should ideally preserve not only the instruction but the reasoning that caused the instruction to exist.

Compare this:

Use encryption.

with this:

Customer Database -> Confidentiality: High -> Data Protection Policy -> Encryption Required

The first instruction may be useful.

The second representation can be understood, reviewed, challenged, changed, traced and evaluated.

The context should therefore preserve relationships between:

Asset -> Security Objective -> Policy / Threat / Risk -> Control -> Guidance -> Evaluation

This is particularly important for AI agents because architectural decisions can otherwise disappear into transient prompts and conversations.

A prompt may tell an agent to use encryption.

A governed context can explain what data requires encryption, which policy selected the control, which component it applies to, and how the implementation should later be assessed.

That difference matters for implementation.

It also matters for review, governance and assurance.

Different Agents Need Different Context

Executable Context can be considered a task-specific view over a larger body of Executable Knowledge.

The underlying architectural knowledge remains governed and structured.

Different participants receive different views of it.

A developer implementing an API might receive:

  • authentication requirements
  • authorisation constraints
  • approved API patterns
  • relevant implementation guidance

An infrastructure agent might receive:

  • network boundaries
  • encryption requirements
  • approved cloud services
  • logging requirements

A testing or review agent might receive:

  • expected controls
  • prohibited configurations
  • evaluation criteria
  • evidence requirements

They originate from the same Architectural Intent, but they produce different Executable Contexts.

The objective is not to put the organisation's entire security policy into an agent's context window.

It is to determine which parts matter to the decision the agent is making.

Executable Context and AI Agents

A human developer has substantial implicit organisational context.

They may know why an architectural decision was made.

They may know what the organisation normally permits.

They may know who to ask when something is unclear.

They may know which standards matter, what a diagram means, and which exceptions are acceptable.

AI agents do not necessarily possess this institutional context.

As their autonomy increases, the gap becomes more significant.

An agent that can independently implement a feature also needs a reliable mechanism for discovering the architectural and governance context relevant to that feature.

Executable Context provides one possible model for doing this.

It does not require every agent to understand the entire organisation.

It requires the task to be connected to the relevant architecture, security objectives, policies, controls and evaluation criteria.

Executable Context and AI Governance

Many AI governance approaches focus on important operational questions:

  • which models may be used
  • what data may be supplied to them
  • approval processes
  • logging
  • monitoring
  • human oversight

These are necessary.

But governance also needs to consider another question: what rules should govern the software engineering decisions made by the agent?

Executable Context provides a potential bridge between organisational governance and individual agent actions.

The relationship can be described as:

Governance -> Policies -> Architecture -> Security Objectives / Controls -> Executable Context -> Agent -> Implementation -> Evaluation / Evidence

The architecture provides the context needed to determine which organisational policies actually apply to the task.

This makes governance contextual rather than simply asking agents to follow organisational policy.

An agent implementing an internal reporting page, an internet-facing API and a confidential customer database should not necessarily receive the same context.

The relevant controls, constraints and evaluation criteria depend on the architecture.

Guidance Is Not Enforcement

Providing an AI agent with Executable Context does not guarantee that it will follow it.

AI models remain probabilistic.

Executable Context can:

  • guide
  • constrain
  • inform
  • provide criteria
  • improve traceability

But deterministic controls may still be required where a requirement must be enforced.

Examples include:

  • policy-as-code
  • IAM controls
  • CI/CD gates
  • schema validation
  • infrastructure policies
  • automated tests
  • independent evaluation

This creates a useful distinction.

Executable Context tells the agent what should happen.

Deterministic controls can prevent certain things from happening.

Evaluation determines whether the resulting implementation satisfies the intended controls.

The purpose of Executable Context is not to pretend that prompting guarantees compliance.

Its purpose is to make the expected behaviour, rationale and evaluation criteria visible at the point where implementation decisions are being made.

Context Through the Lifecycle

Executable Context is not limited to code generation.

The same underlying architectural knowledge can provide context throughout the lifecycle.

Design

Executable Context can help humans or agents identify applicable requirements and controls while the system is still being shaped.

Implementation

It can guide coding agents towards architecture-consistent implementations.

Review

It can tell reviewers and review agents what decisions and controls should be present.

Evaluation

It can provide criteria against which the implementation can be assessed.

Change

It can be recalculated when architecture, policy or security objectives change.

That makes Executable Context part of a feedback loop rather than a one-time prompt.

From Secure by Design to Secure in Reality

Secure by Design determines:

  • the intended system
  • its security objectives
  • the controls required

Executable Context provides a mechanism for carrying the results of that design-time analysis into implementation.

The relationship can be described as:

Secure by Design determines what should be true.

Executable Context carries that intent into implementation.

Secure in Reality determines whether it became true.

This is important because many security failures are not caused by a lack of policy.

They are caused by a break in the chain between policy, architecture, implementation and evaluation.

Executable Context is one way to keep that chain visible.

iSecureByDesign

iSecureByDesign is one implementation of these ideas.

It uses structured architecture models, security objectives and policy definitions to determine context-specific requirements, controls, constraints and implementation guidance.

That output can then be used by humans or AI-assisted development tools.

The broader concept is not dependent on any one product.

The engineering argument is that individual implementation decisions should be connected back to governed Architectural Intent.

Conclusion

The challenge for AI-assisted software engineering is not merely giving agents access to more information.

The challenge is connecting individual agent decisions to governed Architectural Intent.

Executable Context is a way of describing that connection.

It derives the requirements, controls, constraints, rationale and evaluation criteria relevant to a particular task from a structured representation of architecture, security objectives and organisational policy.

More context is not necessarily better context.

The right context is the context that should influence the decision being made.

Architecture provides the knowledge.

Context makes it actionable.