GuildBuild Inc.
← All insights

KN-07 · Agent governance case study

Writing a constitution for agents: seven drafts, two harnesses, and what broke

Claude Code and Codex teams shared one operator and one machine. Each had its own lead, workers and habits. The team wrote a common set of rules so both could review the same proposal.

5 min readGuildBuild Team
AI agentsAgent governanceHuman oversightAgent teams
In this article

The status of the draft

The proposed constitution collected rules with their sources. In the version studied, every chapter remained marked draft. Active rules already had their own authority through seat instructions and hooks.

One writer, two reviewers

  1. An advisor wrote the draft. Both team leads submitted requirements before drafting began.
  2. The leads from both harnesses reviewed six rounds in one day.
  3. Both leads signed version six.
  4. Version seven added six articles at the operator’s direction and still awaited both signatures in the record.

The team preserved the files cited in the draft byte for byte and recorded their hashes in a manifest. Each article named the sources behind it.

Each rule names its enforcement

Each article recorded the rule type, its origin, its enforcement and its sources. Enforcement could be a seat instruction, a control already in force, or no mechanism at all.

Under the draft’s proposed process, stable chapters would become instructions in both setups. A lead’s signature committed their team to incorporate chapters once stable. Ratification remained with the human operator. The signatures on version six did not give the draft itself authority.

Figure 01Process trace

What the two lead signatures established

  1. Source the rule

    One advisor drafts for both teams.

    Each rule names its origin and what would enforce it. The team preserved the cited files with hashes.

  2. Review the draft

    Both leads sign version six.

    Their signatures record a commitment to incorporate stable chapters. Version seven added six articles and awaited new signatures.

  3. Ratify and apply

    The operator holds the ratification decision.

    After ratification, the proposal would still need to become active instructions or controls in each setup. A relay about the proposal does not grant that authority.

One team reviewed six rounds in one day. The draft remained unratified in the record. Existing instructions and controls supplied the authority in use.

A relay carries a claim

When an agent passed on what the operator had said, the recipient treated it as a claim to check against its own brief. An advisor could recommend a change. A seat acted on authority granted in its assignment. A summary between sessions helped the recipient find context.

This mattered when a request moved across teams. If a relay alone could grant authority, any agent that quoted the operator could redirect another team.

What broke in practice

  1. A worker acknowledged its brief, said it would read it next, and ended the turn. It sat idle for five hours while its lead reported it as working. The team added a direction to keep working in the same turn and checked live worker state before reporting progress.
  2. In another case, a request for acknowledgement produced corrections and a debate. The operator wanted the teams to acknowledge receipt and continue their work.
  3. An acknowledgement can wake an idle seat, causing it to reread its context. The team reasoned that fewer wakes may save more than shorter messages. It did not measure the two approaches against each other.

What to record in a shared rule

  1. Assign one writer who can work across the teams.
  2. State where each rule came from, what enforces it and whether the mechanism is active.
  3. Preserve the evidence and keep lead signatures separate from operator ratification.
  4. Log incidents and verify a seat’s state before reporting its progress.