guerrilla2799 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.
| Pre-check | Why | Cost of skipping |
|---|---|---|
| CRM conflict check | The account may be in an active deal | A rep's deal disrupted by an automated touch |
| Suppression list check | Customers, competitors, do-not-contact | Prospecting a board member |
| Balance and ceiling check | Spend is about to happen | The credit fire |
| Freshness check | The data may be stale | Confident outreach on a person who left |
| Clearance check | Proof points may be uncleared | An uncleared metric on a public surface |
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.
| Placement | Strength | Use for |
|---|---|---|
| Written in the skill body | Advisory. A determined instruction talks past it | Style rules, preferences, budgets |
| Enforced by a hook | Hard. Not subject to persuasion | Mandatory logging, spend pre-checks |
| Configured in the vendor account | Hard. Fails closed | Spend ceilings, rate limits |
| Human approval gate | Hard, and slow, which is sometimes the point | Sending, spending, writing to systems of record |
| Absent from the tool entirely | Absolute | Capabilities the agent should simply not have |
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.
| Trip rate | Reading |
|---|---|
| 0% | The guardrails are not real. Nothing is being tested |
| 2 to 10% | Healthy. They are catching real cases |
| Over 20% | Scope is wrong. The agent is being asked for work it should not do |
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-controlfor the spend side - Hands off to:
agent-rollout - See also:
docs/build-surface.mdon hooks,docs/field-notes.mdstory 1