Automations-as-code: building lifecycle email an agent can edit

Events trigger everything

Modern lifecycle email is event-driven: your app fires an event (user.created, cart.abandoned, trial.ending) and the ESP runs a sequence. Resend's Automations, Customer.io's Track API, and Loops' event triggers all follow this shape. The agent's job is to define the trigger and the steps that follow.

await resend.automations.create({
  name: "Welcome series",
  status: "disabled",
  steps: [
    { key: "start", type: "trigger", config: { eventName: "user.created" } },
    { key: "welcome", type: "send_email",
      config: { template: { id: "tmpl_123" } } },
  ],
  connections: [{ from: "start", to: "welcome" }],
});

Conditions, delays, and branching

Real flows need waits and branches. Resend's Automations support time delays and conditions (equals, contains, greater-than, and/or). Customer.io's journeys go further with deep conditional logic across channels. Expressing these as data structures means an agent can propose a change as a reviewable diff rather than a screenshot of a canvas.

• Keep copy in reusable templates so editing words doesn't touch logic.
• Represent branches as data an agent can read and modify.
• Version your automation definitions like any other code.

Prompt-built flows

The newest approach skips the canvas entirely: describe the automation in plain English and let the platform build it. Brew generates multi-step automations — welcome, onboarding, re-engagement, abandoned-cart, transactional — from a single prompt, producing copy, design, audience logic, and structure together. For an agent, this is the highest-leverage interface: intent in, on-brand flow out.

The pragmatic stack often mixes both: prompt-built creation for the on-brand assets and code-defined triggers for the deterministic plumbing.