Bound the agent contract
Every production agent needs an explicit operating contract. The contract travels with the workflow rather than depending on the model to infer limits — models change with versions, prompts, and workloads, and a boundary that lives in the model changes with them. A boundary that lives in the workflow definition does not drift.
The contract answers four questions before any authority is granted: what the agent may see, what it may propose, what it may execute, and what it must retain. Everything else on this page is the enumeration of those four.
Required boundaries
- Brand and tenant context: the agent runs inside an explicit brand scope inherited from the invoking session — never inferred from a URL, a prompt, or a previous task. This is the same per-brand isolation every console session runs under; there is no broader "agent context" shadowing it.
- Authorized records: enumerate the information the workflow may read. "Read access to everything, just in case" is not a workflow definition.
- Allowed actions: separate analysis, proposal, reversible execution, and irreversible execution into distinct classes — each with its own policy. The classification by consequence is detailed at approval gates.
- Policy checks: evaluate current policy before action, not after it. A policy that runs on the audit trail is a report, not a control.
- Human gates: require named approval classes for sensitive or irreversible work, scoped to approvers with authority over the brand in question.
- Evidence: retain inputs, proposal, policy result, approval, action, and outcome — including the proposals that were denied. Denials are often the most instructive entries in the trail.
- Stop conditions: halt on missing authority, stale state, contradictory records, or unavailable dependencies. An agent that cannot verify its inputs stops, loudly, instead of proceeding on a guess.
A contract is operator policy, not vendor default
The boundaries above are visible to the operator and changeable by the operator — per workflow, per brand, per season. What the operator cannot do is remove the gate from irreversible action classes; that floor is the platform's, not the workflow's. The companion essay agents need boundaries before autonomy walks through the control loop in narrative form.
Adoption: proposals first
New agent workflows earn authority gradually. The path we recommend: run proposals only — the agent drafts, operators review, nothing executes — until proposal quality holds up under review. Then open execution for the bounded, reversible classes policy allows. Irreversible classes stay gated no matter how long the workflow has run. Trust is earned per action class, not granted to the agent as a whole.
What a boundary is not
A boundary is not a prompt instruction. Telling a model "do not touch other brands" inside a prompt is a hope, not a control — the enforcement lives in the session's grants and the database's policies, layers the model cannot talk its way past. A boundary is also not a rate limit: throughput caps manage load, they do not express authority. And it is not a logging rule: recording an out-of-bounds action after it executes is evidence of a failure, not the absence of one. Boundaries prevent; logs explain.
Verification and hygiene
Public examples are architectural orientation only. Live agent runs must be reviewed in authenticated operational surfaces where current authority, policy, and evidence are available.
Do not copy credentials, secrets, or private record contents into prompts, logs, public documentation, or marketing analytics. What the agent may retain is part of its contract — and "everything it saw" is never the right answer. The retention and sanitization rules are part of the audit trail & evidence model.