Guardrails, Memory, and Tool Permissions: The Agent Layers That Actually Save You

When an agent demo looks magical, stakeholders remember the chat UI. When an agent fails in production, engineers remember the missing permission check. This post is about the three layers that catch most of the damage before customers do.

1. Scope: what the agent may decide alone

Write a decision boundary document before you write prompts. What can the agent approve? What must escalate? What is never automatic? If that document does not exist, every tool call is improvisation.

• Auto-draft emails: usually fine
• Auto-send emails: rarely fine without policy gates
• Auto-refund / auto-provision / auto-delete: almost never fine without dual control

2. Memory: what already happened

Chat history is not memory. Memory is durable state: prior decisions, customer preferences, open tickets, failed attempts, and human overrides. Without it, agents re-ask, re-do, and re-break.

We store memory as structured records with provenance — who wrote it, when, and whether a human confirmed it — not as an ever-growing transcript the model is expected to 'just understand.'

3. Tool permissions: blast radius by design

Every tool should answer three questions: who can call it, on which objects, and with what side effects. Read-only enrichment tools are not the same class as CRM write tools. Treat them differently in the agent graph.

• Separate read MCPs from write MCPs
• Require human-in-the-loop for irreversible actions
• Log every tool call with inputs, outputs, and cost
• Cap retries so a bad loop cannot burn the budget

Get scope, memory, or permissions wrong and the rest of the stack — beautiful prompts included — does not matter. That is not pessimism. That is production.