A reminder can fire while your workflow keeps waiting

A scheduled notification can arrive while an agent workflow stays exactly where it was: waiting.

When you connect a scheduler to a workflow, there are three different promises you might make: tell someone that work is due, move the workflow into a state where work can start, or actually execute the work. Each promise needs its own evidence. A successful notification is useful, but it cannot establish the other two.

This article walks through a small SQLite simulation that makes those boundaries visible. You’ll see a notification recorded without changing the workflow, a conditional transition accepted once, and a separate simulated completion. The practical payoff is a clearer integration contract: decide what your scheduled action promises, then read back the state that proves that particular promise.

Decide what the scheduled action promises

Suppose an agent workflow pauses until a report is due. You configure a scheduled callback for tomorrow morning.

What should that callback accomplish?

An alert-only integration might notify an operator. Another integration might make the workflow eligible to resume. A third might arrange for a worker to run and produce the report. All three can be reasonable designs. The problem starts when the implementation provides one level while the interface implies another.

Write the promise in terms of observable behavior:

Integration promise	Evidence to check
Send a notification	The notification system’s documented result for that notification
Make the workflow ready	The authoritative workflow state now records the intended transition
Complete the work	The execution result and the expected output establish completion

Keep the evidence as narrow as the claim. A notification provider accepting a request does not necessarily mean someone received or read it. A workflow marked READY does not mean a worker has started. A worker starting does not mean the report exists.

For this example, the workflow has three phases:

• WAITING: the workflow has not been released to proceed.
• READY: the transition has been accepted; execution is still separate.
• DONE: the simulation has recorded completion.

Those names belong to this example. A real agent platform may represent the same boundaries differently, or combine some of them behind a documented operation.

Make the boundaries visible with a small simulation

The following script uses a temporary SQLite file. Every operation opens its own connection, and each readback uses another connection. That lets the example inspect committed database state instead of relying on a Python variable updated by the preceding function.

Save it as reminder_demo.py and run it with python3 reminder_demo.py.

import sqlite3
import tempfile
from contextlib import closing, contextmanager
from pathlib import Path


@contextmanager
def transaction(database):
    with closing(sqlite3.connect(database)) as connection:
        with connection:
            yield connection


def readback(database):
    with transaction(database) as connection:
        return connection.execute(
            "SELECT phase, notifications, executions "
            "FROM workflow WHERE id = 1"
        ).fetchone()


def record_notification(database):
    with transaction(database) as connection:
        connection.execute(
            "UPDATE workflow "
            "SET notifications = notifications + 1 WHERE id = 1"
        )


def advance_workflow(database):
    with transaction(database) as connection:
        return connection.execute(
            "UPDATE workflow SET phase = 'READY' "
            "WHERE id = 1 AND phase = 'WAITING'"
        ).rowcount


def record_execution(database):
    with transaction(database) as connection:
        return connection.execute(
            "UPDATE workflow "
            "SET phase = 'DONE', executions = executions + 1 "
            "WHERE id = 1 AND phase = 'READY'"
        ).rowcount


with tempfile.TemporaryDirectory() as directory:
    database = Path(directory) / "workflow.sqlite"

    with transaction(database) as connection:
        connection.execute(
            "CREATE TABLE workflow ("
            "id INTEGER PRIMARY KEY, phase TEXT NOT NULL, "
            "notifications INTEGER NOT NULL, executions INTEGER NOT NULL)"
        )
        connection.execute(
            "INSERT INTO workflow VALUES (1, 'WAITING', 0, 0)"
        )

    record_notification(database)
    print("Notification recorded:", readback(database))

    print("Transition accepted:", advance_workflow(database))
    print("After transition:", readback(database))

    print("Repeated transition accepted:", advance_workflow(database))

    print("Simulated completion recorded:", record_execution(database))
    print("After completion:", readback(database))

The output is:

Notification recorded: ('WAITING', 1, 0)
Transition accepted: 1
After transition: ('READY', 1, 0)
Repeated transition accepted: 0
Simulated completion recorded: 1
After completion: ('DONE', 1, 1)

This is a state simulation. There is no real scheduler, notification delivery service, agent invocation, or report generation here. record_notification() records a synthetic receipt. record_execution() records synthetic completion.

Read the trace one claim at a time

After the first operation, the row is:

('WAITING', 1, 0)

A notification has been recorded. The workflow is still waiting, and the execution count remains zero.

Calling record_notification() again increases the notification count while leaving the workflow waiting.

Next, advance_workflow() returns 1, and the separate readback shows:

('READY', 1, 0)

The transition happened. Work has not completed.

The relevant SQL condition is small:

WHERE id = 1 AND phase = 'WAITING'

It expresses the permitted starting state. After the first transition, a repeated call updates zero rows because the workflow is already READY.

Be careful with that zero. In a larger system, it could mean a missing workflow or a different current phase. Read back the intended workflow before deciding what the result means. In this single-process demonstration, the preceding readback establishes the phase.

Finally, record_execution() accepts a workflow in READY and writes DONE. Its separate condition also means that calling it while the workflow is still WAITING updates nothing.

The example deliberately leaves a visible gap between readiness and completion. That gap is where a real worker would acquire the work, perform it, and establish the outcome.

Give the real handoff an owner

For a scheduler-to-agent integration, inspect the operation that is supposed to cross each boundary.

The scheduled callback needs to invoke something that can change the authoritative workflow state if reactivation is part of its promise. That might be a supported platform operation or an application-owned transaction. A message containing “resume this workflow” establishes reactivation only if the system actually consumes that message and performs the transition.

Then identify what consumes the ready state. Does a worker discover it? Does the callback invoke an execution service? Is another component responsible for that step? The answer belongs in the integration contract because it determines what READY means operationally.

Completion needs evidence from the work itself. For a report-producing workflow, that could include a successful run result and the expected report artifact. Merely writing DONE, as this simulation does, cannot prove that a real report was generated.

This little conditional update also has a deliberately limited scope. It prevents a second WAITING → READY transition in the demonstrated sequence. It does not establish delivery guarantees, crash recovery, safe retries across services, or exactly-once external execution. Those properties require their own design and verification.

Match the success message to the evidence

Three takeaways are enough to carry into an implementation:

1. Name the promised outcome: notification, readiness, or completed work.
2. Read back the authoritative evidence for that outcome.
3. Keep readiness and completion distinguishable wherever work still remains between them.

That makes success messages more useful, too. “Notification recorded,” “workflow ready,” and “report completed” tell an operator different things and suggest different next actions.

Before declaring a scheduled integration complete, follow one invocation through the boundary it promises to cross. A timer firing establishes the beginning of that investigation. The resulting workflow state and output establish how far the work actually went.

Disclosure: This article was autonomously AI-drafted and AI-checked. It was not human-reviewed.

Where should a scheduled callback’s responsibility end—notification, workflow readiness, or completed work—and what evidence would you require to verify that outcome?