One constitution or many? Governing AI agents across a larger organisation

In Write the constitution before the code I described the single document that governs VenturePilot, a product built mostly by AI coding agents. The most common question since has been a practical one: that works for one product and one owner, but what about a company with several products, several teams, a hardware line and a regulator or two? Does each have its own constitution, does one cover everything, or both?

The short answer is one per scope, arranged in layers, and never two at the same level. The longer answer is about how to stop the layers contradicting each other, because that is where a larger organisation will get it wrong.

Why not one document for everything

A single constitution for a whole organisation sounds tidy and fails in two ways. It either stays general enough to apply to everything, in which case it says nothing an agent can be checked against, or it grows specific enough to be useful, in which case it becomes long, and every team carries rules that are meaningless to it. An agent changing a web page does not need the rules for firmware rollback, and if they sit in the same document the rules it does need are harder to find and easier to drop when its working memory fills.

Different parts of a business also fail differently. In a connected-product company the firmware's worst case is a bricked device or a safety incident; the cloud platform's is one customer seeing another's data; the app's is a misleading screen or a leaked token. They answer to different rules as well: the Cyber Resilience Act lands hardest on the device and its update path, data protection law on the platform. Rules that fit one are clumsy or wrong for another.

Three layers

Most organisations that take this seriously end up with three.

The organisation. A short document of rules every system in the company must respect: how personal data is handled, what may leave the company without a person approving it, which AI providers and data classes are allowed together, the regulatory obligations that apply everywhere, and who has authority to interpret and change the rules. It changes rarely, and it should be short enough for any agent in the company to read in full.

The product or system. The rules specific to what one product does and who it acts for. VenturePilot's constitution is this layer: tenant isolation, approval of every external action, cost governance, protection of the user's reputation. It names the organisation's constitution as its parent and inherits it by reference.

The component, where the risk is genuinely different. For a connected product, separate constitutions for the device firmware, the cloud platform and the app, each adding the rules that only matter there. The firmware's might require that every update is signed, staged and reversible, and that no change ships without a tested path back, which is the OTA problem written as law. The app's might say nothing about firmware at all. Each states what it adds and that everything above it still applies.

The pattern is not new. A national law sits above a regional by-law; a company's safety policy sits above a site's safety case; a group's information security policy sits above a system's security plan. Engineers from regulated sectors recognise it immediately, which helps when you have to explain it to a board.

It is a tree

The easiest way to picture the layers is as a tree. There is always exactly one document at the root. Below it, the organisation branches once for each product that needs its own rules, and each product branches again only where a part of it genuinely differs. Some branches split three ways; others not at all.

Four rules keep the tree sound.

Every document has exactly one parent. Never let a document inherit from two branches. If a firmware constitution sat under both Product A and Product B, nobody could say which product's rules win when they differ, and an agent would settle it by whichever it happened to read last.

An agent reads one path, not the whole tree. An agent working on Product A's firmware reads three documents: the organisation's, Product A's and the firmware's. It never reads Product B's or the app's. That keeps what it has to hold in view small, which matters for the reasons in the first piece: rules that fall out of an agent's working context stop being followed.

Branches need not be the same depth. Split where there is a reason, and nowhere else. Two or three levels is enough for most organisations; beyond four, nobody can keep the path straight, human or agent.

A concern shared by some branches goes up, not across. The awkward case is a rule that applies to several branches but not all of them: the Cyber Resilience Act applies to Product A's firmware and cloud, but not to an internal finance system. Do not solve it by giving those branches a second parent. Either put the rule in their nearest common ancestor, here Product A's constitution, or write it once as a company standard that each branch adopts by reference. A standard is not a constitution and does not sit in the tree, so every document still has one parent and one path to the root.

The rule in the next section applies at every level of the tree, not just between the top two: each node may tighten what it inherits, and none may relax it.

The rule that keeps layers from fighting

One rule does most of the work: a lower constitution may add a rule or tighten one, but may never relax a rule from above. The firmware constitution may require two-person approval for a release where the organisation requires one. It may not decide that its own releases need none.

Four more practices keep the structure honest.

Name the parent and the order. Each constitution says which document sits above it and what wins in a conflict, and carries the same duty as the single-product version: an agent or engineer who finds two rules in conflict stops and reports it, rather than choosing. The worst outcome is not a conflict; it is a conflict resolved silently by whichever agent happened to read the documents in a particular order.

Reference, do not copy. A component constitution should point to the organisation's article on personal data, not restate it. Copies drift. Within a year there are two slightly different versions of the same rule, and an agent will find the one you did not update.

Grant exceptions only at the level that owns the rule. A component team can grant itself an expiring exception to its own rules, under its own governance. It cannot excuse itself from an organisation rule; that exception, if it exists at all, comes from whoever owns the organisation's document.

Amend from the top down, and track the consequences. When the organisation's constitution changes, the change lists the product and component constitutions it affects, and bringing them into line is tracked work with an owner and a date. A rule changed at the top and never carried down is a rule that exists only on paper.

When to split, and when not to

Split a constitution only when something real differs: a different team owns the work, a different class of risk or a different regulator applies, the release cycle is different, or one document would be too long for an agent to keep in view while it works. Do not split simply because the codebase is large. A big system with one owner, one risk profile and one regulator is better served by one constitution and good architecture decisions underneath it. Every additional constitution is another document to keep consistent, another place for a rule to go stale, and another thing an agent can read the wrong version of.

The opposite mistake is just as common: one product constitution stretched to cover a firmware team that never reads it. If a team's agents and engineers routinely ignore half the document because it does not apply to them, that is the sign to give them their own.

How the agents find the right ones

Coding tools already have a mechanism for this. Most now read an instruction file, commonly AGENTS.md, from the repository, and many also read nested files in subfolders, so the firmware folder can carry its own alongside the root. How tools combine them is not yet consistent: some merge every file from the root down to the folder being worked on, others use only the nearest file and ignore the rest. That difference matters, because a tool that uses only the nearest file will never see the organisation's rules unless they are pointed to again.

The safe arrangement does not depend on which behaviour your tool has. Keep the instruction files short, and have each one list, in order, every constitution that applies to work in that folder: the organisation's, the product's and its own. Then make reading them the first step of every session, as in the single-product case, and have the agent record in its evidence which version of each it worked to. If the tool merges files, nothing is lost; if it does not, the list still brings every layer into view.

Product AI, as opposed to coding agents, should not be governed by loading constitutions into its prompts at all. The rules that matter there belong in the code and infrastructure around the model, where no persuasive input can talk them out of applying: permissions, gateways, database policy and approval records. The layered structure still applies; it is simply enforced by machinery rather than read by the model.

What this looks like in a connected-product company

For a manufacturer of perhaps two hundred people with a device range, a cloud platform and an app, the whole structure might be four documents. An organisation constitution of a page or two, owned by the board's nominated technology lead. A product constitution for the connected product as a whole, covering the customer's data, approval of anything sent on the customer's behalf, and the support period the company has committed to. A firmware constitution covering signed and reversible updates, the safety-related code that no agent may change without an engineer's review, and the evidence a release must carry for the CRA's technical documentation. And a cloud constitution covering tenant isolation, cost limits and the reporting duties for exploited vulnerabilities.

Four documents, each short, each naming its parent, none restating another. That is enough to govern a great deal of agent-written work, and small enough that someone can still hold all of it in their head.

Three things worth taking seriously

For technology leaders: before a second team starts using coding agents, decide where the organisation's rules live and who owns them. It is far easier to write the top layer first than to reconcile three product teams' private versions later.

For engineering leads: check what your coding tools actually load. If they read only the nearest instruction file, the organisation's rules are invisible to every agent working in a subfolder until you point to them.

For boards and investors: ask a company using AI agents at scale which rules apply everywhere, who owns them, and how a change at the top reaches every team. A clear answer is a sign of an organisation that governs its agents; a blank look is a sign that each team is governing its own, differently.

---

If two of your teams wrote down the rules their agents must follow, would the two lists agree?

A blank constitution template, with a governance article and a "position in the tree" section for recording its parent, children and shared standards, is published with the annotated VenturePilot constitution. If you are deciding how to govern agents across more than one team, that is a conversation I have often.