Founder Journal #12 — The Rules AI Agents Must Never Forget
"A production engineering system needs more than intelligence. It needs principles that remain stable when everything else changes."
Every Serious Organization Has Rules
Software engineering teams rarely operate without rules.
Even when nothing is formally documented, there are usually expectations:
- How code should be written.
- How architecture should evolve.
- How security should be handled.
- How changes should be reviewed.
- How documentation should be maintained.
- What can and cannot reach production.
Over time, these rules become engineering culture.
Humans learn them through experience.
AI agents need something different.
They need them explicitly defined.
Why AI Needs a Constitution
An AI coding agent can execute instructions extremely well.
But execution is not the same as judgment.
Consider a simple request:
"Add a new payment service."
There are hundreds of technically valid ways to implement it.
The agent needs to know:
- Which architectural boundaries apply?
- Which security requirements are mandatory?
- Which dependencies are allowed?
- What testing standards apply?
- What documentation must be created?
- Which existing decisions must be preserved?
These answers should not depend on whatever happens to be inside the current conversation.
They should come from a stable engineering authority.
That is the purpose of the Engineering Constitution.
What Is an Engineering Constitution?
The Engineering Constitution is the highest-level collection of engineering principles governing a project or organization.
It defines the rules that should remain stable across:
- Developers
- AI agents
- Repositories
- Tools
- Workflows
- Technology changes
It is not a coding style guide.
It is not a prompt.
It is not a project README.
It is a set of non-negotiable engineering principles.
Constitution vs. Policy
These concepts are related but different.
The Constitution defines principles.
Policies define enforceable rules derived from those principles.
For example:
Constitution
Security must be treated as a first-class engineering concern.
Policy
Secrets must never be committed to source control.
The Constitution establishes the principle.
The Policy operationalizes it.
This separation is important because principles tend to remain stable while policies may evolve.
A Constitution Can Have Multiple Domains
NAEOS does not assume that one document should contain every rule.
Instead, the Constitution can be organized into domains.
For example:
Engineering Constitution
Defines general engineering principles.
Architecture Constitution
Defines architectural boundaries and design principles.
Security Constitution
Defines fundamental security principles.
Documentation Constitution
Defines how engineering knowledge must be maintained.
Testing Constitution
Defines quality and verification principles.
AI Constitution
Defines how AI agents are allowed to operate.
This creates a hierarchy of engineering authority.
Example: Architecture Constitution
Imagine a system with clearly defined bounded contexts.
The architecture constitution could state:
Services must communicate through explicitly defined interfaces.
An AI agent attempting to bypass that boundary should not simply receive a suggestion.
The engineering system should recognize that the proposed change conflicts with an architectural principle.
That is the difference between guidance and governance.
Example: Security Constitution
A security constitution might establish principles such as:
- Least privilege.
- Defense in depth.
- Secure defaults.
- Explicit trust boundaries.
- No secrets in source code.
- All external input must be validated.
These principles remain relevant even when the technology stack changes.
The implementation may change.
The principle does not.
Example: Documentation Constitution
Documentation is part of engineering knowledge.
Therefore, an organization might define:
Significant architectural decisions must be recorded.
From that principle, a policy can require:
Every change affecting system boundaries must include an Architecture Decision Record.
Again:
Principle → Policy → Enforcement
This relationship becomes central to NAEOS.
The Constitution as AI's Engineering Compass
Imagine an AI agent entering a large repository.
It has access to:
- Source code
- Documentation
- Tests
- APIs
- Configuration
But without a constitution, it still has to infer what matters most.
The Constitution gives the agent a hierarchy of principles.
When multiple solutions are technically possible, the agent can evaluate them against those principles.
Instead of asking:
"What solution can I generate?"
The agent can reason:
"What solution is permitted within this engineering system?"
That is a much stronger foundation.
What Makes a Good Constitution?
A useful Engineering Constitution should be:
Explicit
Principles should be written down.
Stable
Core principles should not change casually.
Versioned
Changes must be traceable.
Machine-readable
AI agents should be able to consume it reliably.
Human-readable
Engineers must understand and review it.
Testable
Important principles should eventually connect to enforceable policies or quality gates.
Auditable
Teams should be able to determine which version governed a decision.
These properties turn a document into engineering infrastructure.
The Constitution Should Not Become a Giant Rulebook
There is an important distinction.
A constitution should define principles, not every implementation detail.
If the constitution contains thousands of tiny rules, it becomes difficult to maintain.
Instead, think in layers:
Constitution
│
▼
Principles
│
▼
Policies
│
▼
Standards
│
▼
Workflows
│
▼
Implementation
Each layer has a different responsibility.
This separation keeps the system flexible without sacrificing control.
Why This Matters for AI Agents
AI models change.
AI tools change.
Repositories change.
Programming languages change.
Cloud platforms change.
But an organization's fundamental engineering principles often change much more slowly.
That makes the Constitution an anchor.
The model can be replaced.
The agent can be replaced.
The IDE can be replaced.
The engineering principles remain.
This is one of the key ideas behind NAEOS:
The engineering system should be more stable than the intelligence operating inside it.
From Constitution to Runtime
A constitution is useful only if its principles influence actual engineering work.
That raises the next question:
How do principles become enforceable?
This is where the Policy Engine enters the architecture.
The next article will explore how NAEOS transforms engineering principles into machine-enforceable policies—and why governance should happen continuously rather than only during code review.
Discussion
If you were writing the first five principles of an AI Engineering Constitution, what would they be?
Would you prioritize:
- Security
- Architecture integrity
- Testing
- Documentation
- Maintainability
- Privacy
- Reliability
- Developer autonomy
What principle would you consider absolutely non-negotiable?
Top comments (0)