Weekly "this week in your city" live events digest

Build an agent workflow that publishes a "this week in [city]" live events digest to our Local Live Events Notion database every Monday at 8am, so the marketing team can pick activations, brand tie-ins, and content angles to chase for the week ahead.

Workflow type: agent. Trigger: cron, weekly on Monday at 8am in the city's local timezone.

Inputs to configure when the workflow is installed: target city display name (e.g. "Austin"), latlong as a "lat,long" string, search radius in miles, the Notion database id for the Local Live Events database, and the Ticketmaster classification segments we care about (default: Music, Sports, Arts & Theatre, Family).

Run order each week:

1. Compute week_of as the ISO date of this Monday in the city's timezone, and the end of the window as Monday + 7 days.

2. Resolve classification segment IDs. Keep a hardcoded mapping of the common Ticketmaster segment IDs in the agent's instructions so we avoid calling List Classifications on every run. The first time the workflow runs, the agent should call Ticketmaster's List Classifications operation, capture the segment IDs for Music, Sports, Arts & Theatre, and Family, and persist them into its own instructions for reuse. If a configured segment is missing from the mapping, or once a month as a freshness check, refresh by calling List Classifications again.

3. Check Notion for an existing digest. Query the Local Live Events data source filtered on the week_of property equal to this Monday. If a page already exists for this week, log "digest already exists for week_of=<date>, skipping" and exit cleanly so we never produce duplicates.

4. Pull events from Ticketmaster. Call Search Events for the configured latlong and radius, with startDateTime set to this Monday at 00:00 local time and endDateTime set to next Monday at 00:00 local time, and segmentId filtered to the configured segment IDs (comma-separated). Paginate using the page and size parameters until you have exhausted results or hit Ticketmaster's 1000-result hard cap (page * size < 1000). Read the events out of _embedded.events on each response. Throttle to about 4 requests per second, and on a 429 back off exponentially starting at 1 second up to 5 retries.

5. Cluster results by segment (Music, Sports, Arts & Theatre, Family, plus any extra segments configured). Within each cluster, rank events by a simple importance signal: prefer events with a populated priceRanges field, then by venue size hints if available, then by date ascending. Pick the top 5 to 8 headliners per cluster.

6. Draft an editorial summary per cluster. One short paragraph of 3 to 5 sentences in plain editorial voice covering: what is happening this week in that category, why it matters for our marketing team, and a concrete suggested angle (activation, content piece, social moment, partnership opportunity). Then surface the 3 most notable events across all clusters as the week's overall "top picks".

7. Create a single Notion page in the Local Live Events database with these structured properties: week_of (date, this Monday), city (text, the configured city name), headliner_count (number, total headliners across clusters), top_picks (multi-select or text, the names of the top 3 events overall), recommended_angles (multi-select or text, the 3 to 5 marketing angles surfaced), source_event_count (number, total events seen before clustering). The body of the page should contain one section per cluster: a heading with the cluster name, the editorial summary paragraph, and a bulleted list of headliner events showing event name, date, venue, and a link back to the event on Ticketmaster.

8. Log a one-line success summary with week_of, total events processed, the per-cluster counts, and the new Notion page URL.

Edge cases: if Search Events returns zero events for the week, still create the Notion page with a note that no major events were found, so the marketing team has a confirmed signal rather than silence. If Notion's Query a Data Source returns multiple existing pages with the same week_of (data drift), pick the oldest one as canonical and log a warning.