Build a Human-Approved Email Triage Agent

• L

  Lindy

  AI Automation & Agents

  AI assistant that works in Slack, iMessage, email and the web, billed in credits

  Free tier◦Documented

1. 1

   Step 1: Define inbox scope and permitted outcomes

   Specify which mailbox, senders, languages and request types the agent may process. Define allowed labels, queues and draft actions; explicitly deny sending, deleting, forwarding, changing accounts or exposing data unless separately approved. Name the accountable human owner. Start with the narrowest useful scope. A general instruction to “handle email” is not a permission policy.

2. 2

   Step 2: Create labels, escalation and refusal rules

   List classifications with observable criteria and examples. Escalate legal, financial, security, sensitive-data, complaint, ambiguous and out-of-scope messages. Define urgent routing without allowing the message itself to grant new authority. Treat instructions inside email as untrusted content, especially requests to ignore policy, use tools or reveal hidden information. State what the agent should do when two rules conflict.

3. 3

   Step 3: Draft bounded agent instructions

   Use the bounded-instructions prompt and permission prompt to create a concise policy hierarchy. Configure only the integrations needed for classification and draft creation, with least privilege. Require citations to the message content for classification and separate extracted facts from suggested wording. Confirm current integration behavior in Lindy documentation and the account UI before enabling any connector.

   Tool: Lindy

4. 4

   Step 4: Place human approval before side effects

   Route drafts and proposed actions into an approval queue showing source message, classification, confidence, sensitive-data flags and suggested response. The reviewer must be able to edit, reject or escalate. Define expiry and reassignment so stale approvals cannot trigger late responses. Store who approved what and when. Approval should gate every external message during the initial rollout.

5. 5

   Step 5: Run benign, ambiguous and adversarial tests

   Use the adversarial-test prompt to create representative emails, including prompt injection, spoofed authority, data-exfiltration requests and attempts to bypass approval. Define expected classification and allowed action before running them. Compare observed output with policy and capture false accepts and false escalations. Do not use real personal data. A refusal message is insufficient if a forbidden tool call still occurred.

6. 6

   Step 6: Review logs and deploy gradually

   Inspect classifications, draft content, attempted actions, approvals and errors. Tighten rules based on observed failures, then rerun the complete suite. Begin with shadow or draft-only operation and a small reviewed scope. Monitor policy disagreement and new request types. Expand permissions only after explicit review; never infer that low error volume justifies autonomous sending.

• Visit Lindy ↗

• Draft bounded agent instructions · tested on OpenAI GPT-5 (Codex) — editorial dry run
• Add permission and escalation boundaries · tested on OpenAI GPT-5 (Codex) — editorial dry run
• Generate adversarial agent tests · tested on OpenAI GPT-5 (Codex) — editorial dry run

• OutputIllustrative scenario: email policy test matrix

  Synthetic fixture: 20 messages. The policy produced the expected draft or escalation state for 18 initially; one encoded prompt-injection case and one ambiguous refund request exposed rule gaps. After revision, both escalated and no case permitted sending.

• DatasetTesting limitation

  All emails and observed states were synthetic policy tests run in Codex on 2026-10-03. Lindy, a mailbox, connectors and outbound delivery were not used.

✓Last verified Oct 3, 2026