Model a Sales Reminder as a State Machine, Not a Prompt

By Tej Pandya, founder of GrowEasy.ai

A reminder agent needs somewhere to store what it owes. If the only record is the conversation, developers cannot reliably tell whether an action was planned, attempted or completed.

This example is a design sketch for an appointment-led sales workflow. It is not a deployed customer result or a GrowEasy.ai feature claim.

Keep scheduling state separate from message text

Store an appointment revision, confirmed time, consent state, contact route and reminder status. A change to the appointment should invalidate pending work tied to an older revision.

The model can extract a proposed time from a message. Application logic validates it before updating the record. Unknown consent stays unknown; it is not filled from the model's confidence.

An illustrative transition sketch:

requested -> confirmed -> reminder_eligible -> attempted
attempted -> delivered | retryable_error | permanent_error
retryable_error -> reconciled | retry_pending | needs_human
needs_human -> assigned -> accepted -> completed

These states are not a universal standard. Choose them around the real work and the provider's actual receipts. Do not interpret "delivered" as "attended".

Reconcile ambiguous tool results before retrying

When a request times out, it may already have succeeded. Look up the provider result or reuse a supported idempotency key before repeating the side effect.

A key might identify the appointment revision and reminder type. It must not suppress a genuinely new reminder after the buyer changes the appointment.

Temporal's documentation recommends idempotent Activities because retry behavior can repeat execution. Durable state and safe side effects solve different problems; you need both.

Put eligibility checks immediately before the effect

Before a reminder sends, re-check current appointment state, consent, permitted time and destination. A job that was eligible when queued may no longer be eligible when it runs.

Treat refusal and revoked consent as stop conditions. Distinguish temporary transport errors from permanent failures. A retry budget is an application decision, not something the model should improvise indefinitely.

Give the human fallback a real lifecycle

An exception record needs a question, current evidence, requested time and owner. Assignment is not acceptance. An overdue unaccepted task should remain visible to the team.

Do not tell the buyer that a callback is confirmed if the application only emitted a notification. Gate that sentence on the state that proves a responsible person and valid time exist.

Test changed state and repeated execution

Test a cancellation after queueing, duplicate webhook delivery, two workers claiming the same job, a provider success followed by a lost response, an unavailable owner and an explicit request for a person.

Check the resulting records and external actions, not only the agent's wording. Compare the design with a simpler deterministic baseline. Anthropic's workflow guidance is useful here: add model-driven flexibility where it is needed rather than turning every predictable step into an autonomous decision.

A clean state machine cannot fix bad rules. It can make those rules, and their failures, visible enough to test.

Sources:
https://www.anthropic.com/engineering/building-effective-agents
https://docs.temporal.io/activity-definition
https://temporal.io/blog/idempotency-and-durable-execution