Trigger map vs cron job: a schedule is one row, not the map

A cron job fixes when a task starts; a trigger map records which event starts which agent role, under what condition, with which input, and when the work goes back to a person. A schedule is one row type on that map, not the map. It can start a calendared route. It cannot decide where a client request, a new draft or a repeated form submission belongs.

Here, cron job means only a task a scheduler runs at fixed times. The Agent Dream Team calls the trigger map the T in ROSTER: a standing routing decision, made once and deliberately, then applied every time the event recurs. It can guide a person who opens the right agent, or a tool that starts one. Writing it down does not prove that the tool follows it.

Imagine a hypothetical solo founder whose Monday research brief starts at 09:00. An hour later, an active client asks for a revised proposal and a supplier asks to move a call. The clock has done its job; the founder still has two routing decisions to make. If those routes live only in the founder’s head, every new arrival forces the same decision again.

What does a fixed schedule decide?

A fixed schedule supplies a time. Any role, input or instruction you write beside it is your choice, not the clock’s. The gap shows as soon as the event is a message or a file.

Decision	Fixed schedule alone	Trigger map
When does work start?	At a set time	At a set time or after a qualifying event
Which role owns the work?	Only if you name it separately	Each route names one role
Which arrivals qualify?	A time cannot sort incoming items	An activation condition separates similar items
What does the role receive?	Arranged separately, if at all	The starting input and its source are specified
When does a person take over?	The schedule sets no boundary	An escalation condition names it

A Monday reminder to open the Research Specialist with a brief you wrote the evening before is a sound calendared route. A job that runs an agent with no brief is a start signal without a task. Neither tells you what to do with Tuesday’s client email.

What is ROSTER? sets out all six decisions. In the book, roles, objectives and tool permissions come before triggers, because a route can only name a specialist whose job is already defined.

When should a route be calendared, event-driven or manual?

Chapter 6 separates three trigger types. Calendared triggers fire on a fixed schedule; the clock fires them. Event-driven triggers fire when something changes, such as a form submission or a file landing in a named folder, and need a detection mechanism. Manual triggers fire when you decide, because the case is unusual, one-off or needs judgment first.

Its three questions settle the type:

1. Is the timing predictable or variable? A weekly review fits a calendar block. A proposal request arrives when the client sends it.
2. Can the event be detected reliably without your attention? A folder path or form field may be specific enough. “Something important arrived” is not a detection rule; without one, the event may need to stay manual.
3. Does the event need human judgment before the agent starts? Then the trigger needs a condition layer that separates “route to the agent” from “handle it myself”, or the event stays manual.

The book keeps recurring manual patterns in a separate note titled “manual routing patterns”, outside the routing table. Listed beside automated rows, manual rows look wired, and a month later you are waiting for a trigger that never existed.

What belongs in one trigger-map row?

Chapter 6 gives every row five fields. Write them so that two people would route the next arrival the same way.

1. Triggering event: What happened? “Client email” is too broad when clients send proposals, invoices and scheduling notes.
2. Activation condition: Which observable fact makes this event a trigger for this role? Name the sender tag, subject terms, form field, folder or calendar block.
3. Role activated: Which single named role handles it? If two roles seem to own the same kind of event, fix that overlap in their charters first.
4. Starting input: What does the agent receive, in what format, and from where? Name the source, not only the artifact.
5. Escalation condition: When does the agent hand back to you before proceeding? “If complicated” activates on everything; “if the email signals a contract change or legal question” names a boundary.

In design, the map is a decision tree: recognize the event, test the condition, select the role, pass the input, stop at the boundary. An item that fits no condition stays with you until you can describe its route.

Every automated row also gets a delivery note: four lines, filed on the page facing the map.

• De-duplication key: The field that makes the source event unique, such as a form’s submission ID, an email’s message ID, or a file path plus modification timestamp. A transport’s delivery ID changes on redelivery; the source event’s ID does not. If you cannot name a key, the trigger is not ready to run unattended.
• Second-delivery class: Harmless, expensive or dangerous, and what the handler does: proceed, skip, or stop and notify you.
• Failure route: Where a failed run lands so that you see it. Silence is not a failure route.
• Off switch: How you disable the trigger, in which tool, and how many seconds that takes.

Calendared rows usually need only a failure route and an off switch. Event-driven rows need all four lines, because a platform can deliver the same event twice.

Worked example: Elena’s four routes

Elena is the book’s composite founder, not a documented company. These four rows come from her chapter 6 map.

Event	Activation condition	Role	Starting input	Escalate when
Monday 09:00	Weekly calendar block	Research Specialist	One-paragraph weekly focus brief	The brief conflicts with an active proposal deadline
New active-client email	Sender tagged “active-client” in the CRM; subject contains “proposal,” “scope” or “deliverable”	Draft Editor	Forwarded email and relevant charter section	The email signals a contract change or legal question
New scheduling or logistics email	Sender tagged “active-client” or “vendor”; subject contains “reschedule,” “invoice,” “confirm” or “call”	Ops Coordinator	Forwarded email	The email involves a commitment beyond one week
Website inquiry form submitted	Contact form; message field is not empty	Research Specialist	Submission payload plus the submission ID	The inquiry names a budget, a deadline or a legal question

There are two email rows because her first version had one: every client email went to the Ops Coordinator, and in the first week two of three activations were wrong. Splitting the row separated project mail from logistics. It cannot settle a message that is both: a client can ask for a revised scope and a meeting in one email. The book’s rule is to route to the role that owns the primary task, here the Draft Editor, and handle the meeting afterward as a manual step or a follow-up trigger. Deciding which task is primary stays your job.

Her two file rows, E3 and E4, split the shared folder by path: /drafts/inbox/ goes to the Draft Editor, /research/inbox/ to the Research Specialist, and the roles save their output to out subfolders that no trigger watches.

The form row carries the submission ID for a reason. In Elena’s Roster Log, a slow handler meant the form platform never received its acknowledgment in time, so it marked the delivery failed and sent it again, and again. One inquiry became nine deliveries, nine research runs and nine near-identical summaries by Tuesday lunchtime. The repair: acknowledge first, run the agent second, log every processed submission ID and drop the repeats. Her first delivery note: dedupe on submission ID; a second delivery is expensive, not dangerous; failures go to the flagged folder; off switch is the toggle in the form tool, ten seconds. The vignette shows a design, not a production test.

What if the signal is repeated or wrong?

The book draws the line in two sentences: a duplicate delivery is the same event arriving twice; a false trigger is the wrong event arriving once. They look alike in the inbox and are fixed in different places.

For a duplicate, the key is necessary, not sufficient. Two deliveries can arrive at once, and an action can succeed a second before the process that records it dies. Chapter 6 therefore asks for one run per key at a time and a durable record of pending, succeeded, failed and uncertain runs. Where the receiving system has its own duplicate check, such as an invoice number, use it: the safest place to stop a duplicate is at the side effect.

A false trigger activates the wrong role, or the right role at the wrong time or with the wrong input. Chapter 6 corrects it in three steps:

1. Identify the misroute: Which event fired, which condition misclassified it, and where does the written row differ from what happened?
2. Update the condition: Exclude the misrouted event, surgically. Over-correcting stops valid events from firing, which is a different failure.
3. Add the excluded type: If it is real work, give it a row for another role or put it in your manual routing patterns note.

A de-duplication rule cannot repair a misroute; the wrong item is a different event.

The book draws one line it calls non-negotiable: a trigger whose second run is dangerous (a second client email, a second invoice, a second published post) does not get wired until it has a de-duplication key. Beside it sits the author’s approval rule, stated as an operating rule rather than a finding: every irreversible, public, financial or client-visible action is reviewed before it ships. Routing a draft to an agent does not authorize sending it.

How do you check the map and stop a route?

Chapter 11 builds a five-minute midweek trigger check into the 30-minute weekly ritual, on Wednesday, or Tuesday in a short week. Compare what fired with what the map said should fire, and look for false positives (a role activated outside its mandate), false negatives (an event that should have activated a role and did not) and activation delays. Chapter 6 adds that a double activation on one event counts as a misfire, and asks whether any event arrived without a trigger or any trigger fired without usable input. The book calls the five minutes a starting timebox, not a guarantee.

A well-written row is no evidence that an email rule, folder watch or form connection is configured the same way. Elena’s own check in chapter 11 finds a client brief that sat in /research/inbox/ for a day: the folder watcher behind E4 was narrower than the map row and skipped a file without an extension. When the map and the tool disagree, flag it and fix one of them.

Prove you can stop an agent covers the drill for a running agent and makes the point that a line in a prompt is not a stop. For triggers you also need the route’s own off switch and a failure route you will actually see. And ask whether the task needs an agent at all: When not to use an agent covers work better served by a script, one model call, a draft-only assistant or a person.

Try this today (20 minutes)

1. List the last ten tasks you handed to an agent or assistant. For each, write the event that made you start, the role you chose, the condition that set it apart from a similar task, and whether the start was calendared, event-driven or manual.
2. Circle the event you routed by hand most often. Write one five-field row for it: event, activation condition, role, starting input, escalation condition. If nothing recurs, pick one candidate and mark it unproven.
3. Replay the row against your ten tasks. Does it catch what it should and exclude the nearest lookalike? Then imagine the same source event arriving twice. Which identifier exposes the repeat, and what happens to the second copy?
4. Write down the gap. If you cannot name a reliable condition or de-duplication key, keep the route manual and add it to your manual routing patterns note. If the row passes, compare it with the next real arrival.

The replay tests whether you can state a routing decision consistently. It does not test a scheduler, an event detector or duplicate control in a live tool.

Cite this:Trigger map vs cron job: a schedule is one row, not the map.Len P. van der Hof. https://lenvanderhof.com/en/blog/trigger-map-vs-cron-job/ · Published 28 October 2026.