Agent Guardrails

The guardrail layer is not overhead on the useful part. In production it decides whether the thing survives contact with a real user.

When to use

• Before any agent reaches somebody other than its author
• After an incident
• Before granting write access to a system of record
• Before granting access to a spending key

Inputs

• Reads: workspace/agents/<name>/brief.md, workspace/agents/context/guardrails.md
• Needs from user: what a bad output would cost, who else has access, and which systems the agent can write to

Workflow

1. Write the refusal set

What the agent will not do, stated positively as refusals rather than left to inference.

This agent will NOT:
- Contact any account with an open opportunity
- Reference a named customer without a clearance marker
- Send anything. It drafts, a human sends
- Exceed <n> rows or <n> searches per run
- Write to <object> in the CRM
- Invent a statistic. Unknown values are marked [unverified]

"Never invent a number" belongs in every refusal set. A fabricated metric in a customer-facing email is the highest-cost failure mode in GTM agents, and it is the most likely one.

2. Install the mandatory pre-checks

Things that run before the work, not after.

The CRM conflict check is the one that buys the most trust with a sales team. An agent that visibly protects their pipeline gets adopted. One that does not gets blocked, correctly.

3. Place each guardrail at the right strength

The central design question. Where a rule lives determines whether it holds.

The last row is the strongest guardrail and the most underused. If an agent has no reason to write to the CRM, do not connect write access. A capability that does not exist cannot be misused.

4. Set the spend guardrails specifically

Per-run row cap:        <n>       (advisory, in the skill)
Per-run search budget:  <n>       (advisory, in the skill)
Deep research mode:     off, requires explicit confirmation
Per-user key:           yes, one key per user, never shared
Account ceiling:        <amount>  (hard, configured in the vendor account)

Per-user keys with per-user ceilings. A shared key with no per-user limit is one bad afternoon from the month's budget, and this has happened to real teams with real numbers.

5. Define the escalation path

An agent that is unsure needs somewhere to go other than guessing.

When <condition>, stop and escalate to <named person> with <what to include>.

Conditions worth escalating on: a conflict the agent cannot resolve, a request outside the defined scope, a proof point with no clearance, or an estimate over the spend threshold.

Escalation must name a person. "Ask a human" gets ignored, because everyone assumes it means someone else.

6. Tune the trip rate

Guardrail trip rate is a real metric.

Zero is not a good score. It means either nobody is using the agent or the guardrails do not describe anything that happens.

Output

• Writes: workspace/agents/<name>/guardrails.md
• Uses: templates/guardrails-template.md
• Prints: the refusal set, the pre-check list, a placement table showing where each guardrail lives and its strength, the escalation path, and the spend configuration

Rules & quality bar

• Every guardrail has a stated placement and strength. A rule with no placement is a wish
• Hard limits live outside the prompt. Vendor ceilings and hooks, not instructions
• Per-user keys, per-user ceilings. Always
• CRM conflict check before any list, brief, or outreach
• "Never invent a number" in every refusal set, with [unverified] as the escape hatch
• Anything that sends, spends, or writes to a system of record has a human gate
• Escalation names a person
• Remove capabilities that are not needed. The strongest guardrail is absence
• A 0% trip rate means the guardrails are decorative

Related skills

• Requires: agent-scoping, context-portfolio
• Pairs with: credit-and-cost-control for the spend side
• Hands off to: agent-rollout
• See also: docs/build-surface.md on hooks, docs/field-notes.md story 1