Why does an AI email agent need a fixed action list?

01Why open-ended email automation goes wrong

AI makes email easy to generate. Give a model user data and a goal, and it will write a reasonable message. The temptation is to let it decide when to write one too: notice a pattern, draft a nudge, send it.

That is where things go wrong. An email is an action with consequences outside your product. It reaches a customer's inbox, it speaks for your brand, and it cannot be recalled. If the model decides when to send, you have given it what security people call excessive agency: more autonomy than the task needs. The OWASP guidance on this risk uses an email assistant as its example, and its advice is direct: limit the functions the model can call, and require approval for high-impact actions such as sending.

A fixed action list is how you apply that advice to product email.

02What the action list for an AI email agent contains

The list is a short, versioned document, or better, a configuration file, that your system reads. For each entry it says:

1. 01

   The trigger event.

   A concrete product event: an account created, a usage threshold crossed, a report finished, a subscription about to renew.

2. 02

   The criteria.

   The exact conditions under which the event leads to a message: which users, which plans, how often at most, and what suppresses it.

3. 03

   The template.

   A fixed HTML template with named slots. The structure, links and legal text never change.

4. 04

   What the AI may fill.

   For example, a usage summary, a short explanation of a change, or a personalized line. Everything else is fixed.

5. 05

   The data it may read.

   Only the fields needed for that message, scoped to that user or organization.

6. 06

   The owner.

   A named person or team who approves changes to that entry.

7. 07

   The send mode.

   Automatic, or drafted for a person to approve first.

If an event is not on the list, no email is sent. If the AI produces content that does not fit the slots, the message falls back to the template's default text or is held for review.

03Where AI adds value inside fixed actions

Fixing the actions does not make the emails dull. It moves the AI to the part of the job where it is useful and safe.

This split also makes the system easier to test. You can test the trigger logic as ordinary code. You can test the AI slots with a fixed set of inputs and check length, tone and grounding. And you can show a reviewer a complete list of every email the product can ever send.

04How to get the list written

The technical work is usually the easy part. The blocker is that nobody has written down which events should trigger which messages. Engineering assumes product will decide. Product assumes the AI will figure it out. Marketing has opinions but no access.

We handle this by making the list a deliverable with an owner before any automation is built:

• Ask for it explicitly. At scoping, ask the client to supply the list of actions and the criteria behind each. If they cannot yet, the automatic flow waits.
• Start small. Three to five actions are enough to prove the flow. Add more once the first ones behave.
• Write criteria as rules, not intentions. "Users who have not logged in for 14 days, at most once per month, not on a trial" is a rule. "Re-engage inactive users" is an intention.
• Version it. Changes to the list go through review, like code, because they are behavior changes.
• Log every send. For each email, record which action fired, which criteria matched and what the AI wrote in each slot.

For a broader view of keeping agents inside the workflow without letting them run unsupervised, see adding AI agents to existing SaaS without rebuilding.

05Trade-offs to accept

Less spontaneity. A fixed list will miss some moments where an email would have helped. That is the price of predictability, and it is usually worth paying. Missed opportunities can be added to the list later; an email that should never have been sent cannot be taken back.

Someone has to own it. The list needs an owner who will answer questions and approve changes. Without one, it goes stale or grows without review.

More upfront work. Writing criteria takes time before anything visible ships. It is also the work that prevents the slow, hard conversations later about why a customer received a message nobody intended.

06What we see in production

We worked on a multi-user, multi-model AI chat product for a generative AI startup, built on its own fork of an open source chat interface. The product already had custom features, including an admin dashboard and multi-user chat, on an outdated base. Our scope included migrating the fork to a current upstream version, moving model routing out to a separate service so the app could reach many model providers, a redesign to the client's own designs, hosting with separate development and production environments, automated deployment, and an automatic email flow with dynamic HTML templates.

When the client asked about fixed action types for the automatic email flow, that part of the work moved forward only after the client agreed to supply the list of actions and the criteria behind them. Until then, there was nothing safe to automate: the templates and the summaries could be built, but nobody had decided which events should send which messages. Once that decision had an owner, the dynamic templates and summaries were straightforward engineering. That is the lesson we carry into every automated communication project. The code is rarely the bottleneck. The decision about what the system is allowed to send is.

Frequently asked questions