Fan-out: one input, multiple outputs. For each email you read, you create both a task and a calendar event. How would you track what got created?
Two separate counters inside the loop? Increment one when a task is made, increment the other when an event is made, return both in a dict?
Exactly. Two counters, one dict at the end, one loop body with both calls inside:
tasks_created = 0
events_created = 0
for msg in messages[:3]:
title = msg.get("snippet", "No subject")[:80]
Why [:3] — why cap at three emails instead of running the fan-out on the whole list?
Two writes per email adds up. Three is enough to show the pattern without flooding your calendar or task list during testing. In production you would pick a cap that matches how many items you actually want triaged in one run:
def full_inbox_triage(max_results: int) -> dict:
emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results})
messages = emails.get("messages", [])
tasks, events = 0, 0
for msg in messages[:3]:
title = msg.get("snippet", "No subject")[:80]
toolset.execute_action(Action.GOOGLETASKS_INSERT_TASK, {
"title": title, "tasklist_id": "@default", "status": "needsAction",
})
tasks += 1
toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
"summary": title,
"start": {"dateTime": "2026-05-01T10:00:00"},
"end": {"dateTime": "2026-05-01T11:00:00"},
})
events += 1
return {"tasks_created": tasks, "events_created": events}
If the Tasks call fails mid-loop, the event for that same email still runs. Is that a problem?
It is — you end up with half-processed emails. In real automations you would wrap each write in try/except and track successes separately. For now the simple version builds the pattern; next track adds the defensive wrapping.
So one run of this function turns three unread emails into three tasks and three calendar blocks — triaged in seconds instead of minutes?
Seconds instead of minutes. That is the moment automation stops being a concept and starts giving you your morning back.
TL;DR: One source, multiple destinations — track each outcome with its own counter, return them together.
[:3] caps the write volume during testing{"tasks_created": N, "events_created": N} dict for the caller| Pattern | Why |
|---|---|
| one total | hides which destination failed |
| per-destination | tells the caller exactly what landed |
Fan-out: one input, multiple outputs. For each email you read, you create both a task and a calendar event. How would you track what got created?
Two separate counters inside the loop? Increment one when a task is made, increment the other when an event is made, return both in a dict?
Exactly. Two counters, one dict at the end, one loop body with both calls inside:
tasks_created = 0
events_created = 0
for msg in messages[:3]:
title = msg.get("snippet", "No subject")[:80]Why [:3] — why cap at three emails instead of running the fan-out on the whole list?
Two writes per email adds up. Three is enough to show the pattern without flooding your calendar or task list during testing. In production you would pick a cap that matches how many items you actually want triaged in one run:
def full_inbox_triage(max_results: int) -> dict:
emails = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results})
messages = emails.get("messages", [])
tasks, events = 0, 0
for msg in messages[:3]:
title = msg.get("snippet", "No subject")[:80]
toolset.execute_action(Action.GOOGLETASKS_INSERT_TASK, {
"title": title, "tasklist_id": "@default", "status": "needsAction",
})
tasks += 1
toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
"summary": title,
"start": {"dateTime": "2026-05-01T10:00:00"},
"end": {"dateTime": "2026-05-01T11:00:00"},
})
events += 1
return {"tasks_created": tasks, "events_created": events}If the Tasks call fails mid-loop, the event for that same email still runs. Is that a problem?
It is — you end up with half-processed emails. In real automations you would wrap each write in try/except and track successes separately. For now the simple version builds the pattern; next track adds the defensive wrapping.
So one run of this function turns three unread emails into three tasks and three calendar blocks — triaged in seconds instead of minutes?
Seconds instead of minutes. That is the moment automation stops being a concept and starts giving you your morning back.
TL;DR: One source, multiple destinations — track each outcome with its own counter, return them together.
[:3] caps the write volume during testing{"tasks_created": N, "events_created": N} dict for the caller| Pattern | Why |
|---|---|
| one total | hides which destination failed |
| per-destination | tells the caller exactly what landed |
Create a free account to get started. Paid plans unlock all tracks.