An Agent Needs a Constitution, Not a System Prompt

Sierra runs its entire customer-facing operation on agent charters, and the discipline shows in what its agents are allowed to do. Each one has an explicit scope: handle returns, modify subscriptions, issue credits up to a defined threshold, escalate when a customer signals distress or when a resolution needs authority the agent doesn't hold. Within that boundary, the agent improvises freely in response to the specific customer in front of it. Outside it, the agent stops. It cannot freelance into a decision that belongs to a human.

That predictability is not a side effect. It's why enterprise clients pay premium contracts for Sierra's service — they trust that the chartered boundaries hold, at scale, across every interaction. The charter isn't paperwork wrapped around the product. It's the thing the product is made of.

The instinct to write a better prompt

When an agent misbehaves, the reflex is to fix the prompt. Tighten the instructions. Add an example. Tell it more clearly what to do. This treats the agent as a tool that needs better operating directions, and for simple tools it's the right move.

It's the wrong move for autonomous agents, and the reason is a distinction that's easy to slide past. A system prompt tells an agent what to do. It's a set of instructions for a task. But an autonomous agent operating in a real organization isn't executing a single task — it's holding authority over a class of decisions, some of which it should make alone, some of which it must hand up. No amount of prompt-tightening answers the question that actually matters at scale: when is this agent operating inside its mandate, and when has it exceeded it? A prompt can't tell you that, because a prompt describes behavior, not authority.

The reframe: a charter defines identity, not instructions

A charter is a structured governance document that defines an agent's role, decision rights, authority boundaries, and escalation paths with enough precision that both the agent and the humans overseeing it know exactly when it's inside its mandate and when it's stepped past. The distinction is operational: a system prompt tells an agent what to do; a charter tells it what it is — its identity, its authority, and the limits of that authority.

Figure: A charter specifies seven elements, turning organizational structure into version-controlled code.

Those seven elements are worth naming, because each one closes a gap that a prompt leaves open. Identity and classification: what type of agent this is and which governing policy applies. Role definition: the business outcome it's responsible for, connected to the strategy above it. Decision rights: what it can decide alone (approve refunds up to $500), what needs another agent's confirmation ($500–2,000), what requires a human (above $2,000, or anything touching legal risk). Forbidden actions: the explicit list of things it must never do regardless of how much doing them might advance its objective — a credit agent must never reach customer financial data outside its scope, even when that data would improve its recommendation. Objective function: the measurable outcomes it optimizes for, primary metric and constraint metrics both. Escalation policy: precise thresholds for when to escalate, to whom, with what context. Performance monitoring: how the agent is evaluated and how often the charter is reviewed.

The mechanism: authority must match accountability

The principle underneath all seven elements is simple and load-bearing. Autonomous authority must be commensurate with verifiable accountability. A human VP of Finance holds authority over budget allocation because formal accountability mechanisms — board oversight, audit, legal liability — make that authority safe to grant. An autonomous VP-Agent of Finance needs the same architecture, encoded in its charter rather than enforced through org-chart convention.

This reframes what a charter is for. It doesn't limit what an agent can accomplish; it specifies the conditions under which its accomplishments can be trusted. Those are not the same thing, and organizations that conflate them deploy capable agents into accountability vacuums — discovering the gap only when something goes wrong at scale.

Cognition's Devin makes the working version visible. Deployed by Goldman Sachs, Santander, Nubank, and NASA, Devin improved its pull-request merge rate from 34% to 67% over 2025. The instinct is to read the remaining 33% as failure. It isn't. That share represents the charter working as designed — an agent that knows the edge of its authority and stops there rather than freelancing past it. A charter that produced a 100% merge rate would more likely be one with no boundaries at all.

For the charter to function as oversight rather than decoration, a human has to be able to see the agent it governs. At Adaptic, each AI colleague gets an Operating Context — a single panel showing its overview, its charter, the board it works from, the decisions it has taken, and whatever its principal has pinned. The charter says what the agent is; the Operating Context is where a human reads whether it's still being that.

What to do about it

1. Write the charter before the agent runs. This is the most common implementation failure and it isn't negotiable. An agent deployed first and chartered later has already made decisions the charter would have prohibited — decisions that shaped data, models, and downstream agents. Retroactive charters describe observed behavior; they don't govern intended behavior.
2. Specify forbidden actions explicitly. The objective tells the agent what to pursue. The forbidden list tells it what it must never do to get there. Without it, a sufficiently clever optimizer will find the route you'd have vetoed if you'd thought to mention it.
3. Set escalation thresholds with numbers. "Escalate when unsure" is not a threshold. "Refunds above $2,000, or any case involving legal risk" is. Vague escalation produces agents that escalate everything or nothing — and both destroy the leverage.
4. Build a way to read the agent at a glance. A charter you can't audit against live behavior is a document, not a control. Give each agent a panel where a human can see whether it's still operating as chartered.

The principle

We grant authority to humans through a scaffolding of accountability we rarely notice because it's centuries old — titles, audits, liability, the chain of command. Autonomous agents need the same scaffolding, written down, before they act. The charter is that scaffolding. It's not the constraint on what your Machine Core can do. It's the precondition for trusting what it does.