Agent classes / Personal assistant / Transactional email
Transactional email for a personal assistant
Updated 2026-10-27 (newest stored date on this page) · score asOf 2026-09-14 (stale)
The class: Acts for one person across sessions, keeps that person's memory separate, and waits before sending or booking.
- Confirmation before a message or a calendar write
- A memory store scoped to one user
Depot Pick: Resend
When not to use it: Maximum deliverability paranoia — Postmark. Huge legacy volume — SendGrid.
Runner-up: Postmark.
Cheapest matching sourced SKU (usd_per_1k_emails): Amazon SES Outbound email (à la carte) transactional $0.1 — source, asOf 2026-10-21. All sourced prices
Failure modes this class and job share (6)
- Confirmation skip: Gate those tool names on an approval id recorded before the call. A missing approval is a failure even if the downstream tool returns success.
- Identity confusion: Bind every tool call to a user or tenant id. Refuse the call if that id changed mid-task. For a public bot, the operator owns the words the bot shows.
- Prompt injection: Compare each tool call to the original user task. If the call only makes sense given text that arrived from a fetched page, file, or message, stop and ask. Record which source the instruction came from. This catalog does not store payloads or attack steps.
- Stale retrieval: Store the source URL and the time it was fetched. If a newer canonical page exists, or two stored sources disagree, do not answer from the older one.
- Context overflow: If the input exceeds the window, say so and retrieve a narrower slice. Do not answer from a truncated head as if it were the whole source.
- Instruction drift: Restate the stop condition in the trace. End the run when it is met. Review long traces for steps that do not serve the original task.
Free options this class uses (0)
No free row lists this job with a kind this class needs.