Skip to content
cd ..

Email Templates with Variable Substitution and Natural Language Scheduling

// · 5 min read

Sending a single email is straightforward. The challenge is everything around it: templates that agents reuse across many recipients, scheduled sends timed to the recipient’s timezone, drafts that agents can revise over multiple turns, and organizational tools like tags and filters that keep a busy mailbox manageable.

The features route module in AgenticMail handles all of this. It’s 18 endpoints that turn basic email sending into a proper workflow toolkit.

Templates with variable substitution

Agents frequently send structurally identical emails to different recipients. A weekly report to stakeholders, a follow up after a meeting, an onboarding welcome message. Writing the full email body from scratch every time is wasteful and error prone.

AgenticMail templates use {{variable}} syntax for substitution. A template might look like:

Hi {{first_name}},

Here's your {{report_type}} report for {{period}}.

{{report_body}}

Let me know if you have questions.

{{signature}}

When an agent sends from a template, it provides a key/value map of variables. The system substitutes each {{variable}} with the corresponding value and sends the result. If a variable is referenced in the template but missing from the map, the send fails with a clear error identifying which variables are missing.

Templates are stored per agent. Each agent can create, update, list, and delete its own templates. The API supports template versioning, so an agent can update a template without affecting emails that were already queued using the previous version.

Natural language scheduling

Sometimes an agent needs to send an email at a specific time. “Send this Monday at 9am,” “follow up tomorrow afternoon,” or “deliver this in 3 hours.” The scheduling system accepts natural language time expressions and converts them to precise timestamps.

The parser handles expressions like:

“tomorrow at 9am” resolves to the next calendar day at 09:00 in the agent’s configured timezone.

“next Monday” resolves to the coming Monday. If today is Monday, it means the following one, not today.

“in 2 hours” adds two hours to the current time.

“March 15 at 3pm” resolves to an absolute date and time.

“end of business” maps to 5pm in the agent’s timezone.

The parsed timestamp gets stored with the email in the scheduled queue. A background worker checks the queue every minute and releases emails whose send time has passed. The granularity is per minute, which is precise enough for email. Nobody notices whether a scheduled email arrives at 9:00:00 or 9:00:45.

If the server restarts, the scheduled queue is persistent. Emails don’t get lost because the process bounced. The worker picks up where it left off on startup.

Drafts

Drafts let agents compose emails over multiple interactions without sending prematurely. An agent might create a draft, work on other tasks, come back to revise it, get feedback from its operator, revise again, and finally send.

Each draft has a unique ID and supports the full set of email fields: recipients, CC, BCC, subject, body, attachments. Updating a draft replaces the specified fields while leaving others unchanged, so an agent can update just the body without re specifying the recipients.

Drafts also track a revision count. This is mostly useful for observability. If a draft was revised 12 times before sending, that tells you something about the agent’s composition process.

Signatures

Agents can have multiple signatures and select which one to use per email. A formal signature for external communication, a brief one for internal messages, a branded one for marketing outreach.

Signatures are stored as HTML with a plain text fallback. When the email is assembled, the selected signature gets appended to the body. The system handles the formatting boundary between the email body and the signature, including the conventional separator line.

Tags for message organization

Tags are simple labels that agents can apply to messages. Unlike folders, a message can have multiple tags simultaneously. An agent might tag a message as both “customer” and “urgent” and “Q1 review.”

The features route supports creating tags, listing all tags, applying tags to messages, removing tags, and querying messages by tag (including boolean combinations like “customer AND urgent” or “urgent NOT spam”).

Tags are lightweight by design. There’s no hierarchy, no color coding, no metadata on the tags themselves. They’re strings that stick to messages. Simple, but effective for the kind of organizational patterns agents need.

Email rules and filters

Rules let agents automate mailbox management. A rule has a condition (sender matches a pattern, subject contains specific words, message size exceeds a threshold) and an action (move to folder, apply tag, mark as read, auto reply, forward).

Rules evaluate in priority order. Multiple rules can match the same message, and all matching rules execute unless a rule explicitly includes a “stop processing” flag. This lets agents build layered filtering: first tag by sender, then move by subject, then auto reply if both conditions are met.

Rules integrate with the SSE event system. When a new email arrives, rules evaluate inline before the agent receives the notification. The agent sees the post rule state, not the raw inbox state.

Eighteen endpoints might sound like a lot for “features.” But each one removes a piece of tedious work from the agent’s plate. Templates save composition time. Scheduling handles timing. Drafts enable iterative writing. Tags keep the mailbox organized. Rules automate the repetitive stuff. Together, they let agents focus on the actual content of their email communication rather than the mechanics of managing it.

Source Code

View the full source on GitHub

// share

// subscribe

New posts and updates straight to your inbox. No noise.

cd ..