Governing AI Agents: Why Your LLM Needs a Constitution

The first time I gave an LLM unconstrained access to the assembly hub codebase and asked it to "implement the BOM normalization improvements we discussed," it produced 847 lines of code across 11 files in under 3 minutes. Some of it was good. A significant portion was subtly wrong in ways that only became apparent after two hours of debugging. And it had also, helpfully, "refactored" three unrelated modules it decided were "inconsistent with the new patterns."

I had not asked it to touch those modules. It did so because they were there, and because nothing told it not to.

This is the governance problem with multi-agent AI development. LLMs are capable, fast, and confidently wrong in ways that are hard to detect without deep context. Deploying them against a complex codebase without explicit behavioral constraints doesn't accelerate development — it creates entropy that experienced engineers then spend their time reversing.

The assembly hub's solution is a governance constitution: a structured system prompt document that defines exactly what AI agents are and are not permitted to do.

The Architect/Worker Hierarchy

The foundational design decision is separating planning from execution. The governance document defines two agent roles with strict, non-overlapping responsibilities:

The Architect has read access to the entire codebase and is responsible for one thing: producing an Implementation Plan. The Architect is explicitly forbidden from writing code blocks longer than 20 lines. Its output is a structured document that describes: which files will be modified, which functions will be added or changed, what the dependency implications are, and what the expected behavior change is. Nothing more.

The Worker receives the Architect's plan and executes it. The Worker is forbidden from deviating from the plan to "improve" unrelated code, refactor adjacent modules, or add features not specified in the plan. Its job is surgical implementation of exactly what the Architect specified.

This separation solves the problem that burned me in the example above. An unconstrained agent is simultaneously Architect and Worker, which means it makes architectural decisions at implementation time without the planning step that would surface their implications. Separating the roles forces the architectural reasoning to happen explicitly, in a reviewable document, before a single line of code is written.

Immutability Constraints

The second governance layer is immutability. The constitution designates specific files and modules as immutable — meaning no agent may modify them without explicit human authorization. For the assembly hub, the immutable list includes:

• The SQLite schema migration files (a bad schema change is catastrophic and irreversible without data loss)
• The Eel WebSocket initialization module (threading bugs here are subtle and break the entire UI)
• The normalization engine's core regex battery (changes here affect 20,000 component records)

When an agent's implementation plan includes changes to an immutable file, the governance system surfaces this for explicit human review before execution proceeds. The agent doesn't just do it — it flags it, explains why it needs to touch the protected file, and waits for approval.

This layer catches the class of error where an agent "helpfully" solves a problem by modifying a foundational module in a way that introduces a regression in a completely different part of the system.

Scope Confinement

The third layer is scope confinement: every agent session begins with an explicitly declared scope — a set of files and modules the agent is permitted to read and modify. Work outside the declared scope requires explicit escalation.

In practice, this looks like opening an agent session with a preamble:

SCOPE: components/normalization/regex_engine.py, 
       components/normalization/family_profiles.py
PERMITTED OPERATIONS: modify, test
FORBIDDEN: cross-file refactors, schema changes, UI modifications
PLAN REQUIRED: yes, before any code generation

The scope declaration is not just documentation — it's a behavioral constraint embedded in the system prompt that the agent actively references when deciding whether an action is in bounds.

The Context Archive

A persistent challenge in multi-session AI development is context loss. When you close an agent session and open a new one, the new agent has no memory of the decisions made in the previous session. Without a mechanism for preserving context, agents re-discover the same constraints, repeat the same architectural reasoning, and occasionally reverse decisions that were made deliberately.

The governance framework addresses this with a CONTEXT_ARCHIVE.md file — a running log of significant architectural decisions, including why they were made and what alternatives were rejected. Before any agent session begins, the relevant sections of the context archive are included in the system prompt.

This transforms context from an ephemeral property of a single session into a persistent document that accumulates over the project lifetime. An agent working on the normalization engine today has access to the reasoning that shaped that engine six months ago — not because it remembers the session, but because the decisions were documented in a format that can be included in its context window.

Why This Is Infrastructure, Not Overhead

The governance framework takes real upfront investment. Writing the constitution, maintaining the context archive, and enforcing the planning step before execution adds time to each development cycle. Engineers who haven't experienced the alternative — unconstrained AI making confident architectural mistakes in critical infrastructure — sometimes push back on this overhead.

My response is consistent: the governance framework is not overhead on top of AI development. It is the infrastructure that makes AI development sustainable over a codebase with real production stakes.

The assembly hub has been under AI-assisted development for over a year with this framework in place. In that time, there has not been a single agent-introduced regression that required more than 20 minutes to identify and reverse. Before the framework existed, that kind of regression happened every other week.

Good governance doesn't slow down development. It removes the hidden tax of debugging confident mistakes — which, compounded over a year, is the difference between a codebase you trust and one that scares you.