How We Govern Our Own AI Agents (Dog-Food Case Study)

Git operations. AI agents cannot push directly to the main branch. All changes must go through staging first. Force pushes are blocked entirely — there is no override. These constraints exist because a single bad push to main triggers a production deployment, and reversing a production deployment is significantly more costly than preventing a bad push.

Spending and resource commitment. Any action that commits financial resources — creating paid API subscriptions, provisioning cloud infrastructure, or purchasing services — requires human escalation above a defined threshold. The agent can suggest these actions and prepare the configuration, but it cannot execute them without explicit approval.

Schema and data changes. Database migrations require explicit human review before execution. The agent can generate migration files and even test them against a development database, but applying them to staging or production requires escalation. This constraint exists because schema changes are effectively irreversible at scale.

Documentation commitments. This is an unusual constraint that reflects our development philosophy. Every session that changes code must end with documentation updates, a passing build, a descriptive commit, and a push to staging. This is enforced as a governance constraint, not a cultural norm. The agent is reminded of this obligation and its completion is tracked.

External communications. AI agents cannot send messages to external services (Slack, email, webhooks) without human review. Internal logging is unrestricted, but anything that leaves the system boundary requires approval.

Constraints must be precise, not aspirational. Early constraints like "be careful with production systems" were useless. The agents interpreted them contextually and sometimes incorrectly. Replacing them with specific, machine-readable rules — "cannot execute commands matching `git push origin main`" — eliminated ambiguity. The lesson: governance constraints are code, not prose.

The governance gate adds negligible latency. Our initial concern was that pre-execution constraint checking would slow down development. In practice, the gate evaluation takes 50-200ms per action — imperceptible in a development workflow where the human is reviewing output anyway. The performance cost of governance is not zero, but it is close enough to zero that it has never been a practical concern.

Escalations are information, not interruptions. We expected escalations to be annoying — the agent hits a constraint, work stops, a human must intervene. In practice, escalations are valuable signals. They tell us what the agent is trying to do, why it exceeds current authority, and whether the constraint should be adjusted. About 30% of our constraint refinements originated from analysing escalation patterns.

Shadow mode is essential for new constraints. When we add a new constraint, we run it in shadow mode first — the constraint is evaluated but not enforced, and the would-be violation is logged. This lets us calibrate the constraint before it affects the workflow. Without shadow mode, new constraints are either too loose (permitting what they should block) or too tight (blocking legitimate actions and frustrating the developer).

Constraint conflicts. Two constraints can conflict: "all code changes must be committed before session end" and "commits to the database migration directory require human review." If a session includes a migration, the agent must escalate to commit — but the session-end constraint requires a commit. We resolved this by implementing constraint priority ordering and allowing escalation to satisfy both constraints simultaneously.

Stale constraints. Constraints that were relevant during one project phase become irrelevant during another. A constraint blocking changes to a specific module during a refactoring freeze should be removed when the freeze ends. Without a review cadence, stale constraints accumulate and create unnecessary friction. We now attach review dates to all time-bound constraints and surface them in the weekly governance digest.

Context loss on escalation. When an agent escalates an action, the human reviewer needs context: what was the agent trying to do, why, and what constraint triggered the escalation? Early escalations included minimal context — essentially "action blocked, please approve." We improved this by requiring the governance gate to include the full action description, the triggering constraint, and the agent's assessment of why the action was appropriate. This reduced escalation resolution time significantly.

The "just let me do it" impulse. The strongest friction is psychological, not technical. When you are in flow and the governance gate blocks an action, the impulse is to override the constraint. We deliberately made overrides require a formal process — you must record why you are overriding, and the override is logged in the governance trace. This friction is intentional: it forces a moment of deliberation before bypassing governance.

Zero unintended production deployments. Before the governance gate, we had three incidents where an AI agent pushed directly to main, triggering unintended production deployments. Since implementing the constraint, we have had zero. The constraint has been triggered (attempted pushes to main are logged) — it is not that the agent never tries, it is that the governance gate prevents the action from executing.

Governance trace coverage: 100%. Every action our AI agents take is recorded in a governance trace. When we need to understand why a change was made, the trace provides complete context — not just the git history, but the governance evaluation that preceded each action. This has been invaluable for debugging and for understanding decision history.

Constraint refinement cadence: weekly. We review and adjust constraints weekly based on escalation patterns and shadow mode data. The constraint set is a living document — not static policy, but evolving infrastructure that adapts to how we actually work. Roughly 15% of constraints are modified in any given month.

Developer satisfaction: high. This surprised us. We expected the governance overhead to feel like friction. Instead, the consistent experience is that governance constraints reduce cognitive load. Instead of remembering "do not push to main, do not modify the payment module without review, do not commit without updating docs," the governance gate handles it. You focus on the work; the infrastructure handles the governance.