Operational AI
7 modules I see for Zucity's ops surface
You build this stuff for a living so I'll keep it short. Just naming the surfaces where the lift looks real. Pick what's already on your roadmap, ignore the rest.
None of this is "you should hire someone to build agents." It's pattern observation from someone who runs ops-AI for a different category of business (local services, coliving-adjacent travel briefs, retreat operators). The shape of the leverage at Zucity reads similar in places, different in others. Below is where similar.
Module 01
Event-curator agent
Scout the Japan + nomad + network-state event surface so the Zucity calendar stays ahead of what members would want to attend.
Watches
Lu.ma host calendars (ETH Tokyo, Fracton, Code for Japan, Pragma, Edge City, Cabin, Esmeralda), partner property event feeds (ADDress, MIDORI.so), Twitter/X lists of network-state hosts, niche Discord event channels.
Produces
Weekly digest of 5-10 events with rationale ("this fits jp/acc week + 3 current members RSVP'd elsewhere"), draft Lu.ma cross-post for the strongest 2, a "should we co-host" flag where there's overlap.
Compounds into
Module 04 (themed-week packager), Module 07 (partner scout).
Build effort
Low. Lu.ma scrape + LLM relevance pass + Slack/email digest.
Weekend or OO time
Weekend for you. The hard part is the relevance prompt, not the scraping.
Module 02
Member-matcher
Turn the member graph into 3 high-signal intros per member per month.
Watches
Membership application fields (what they build, what they want), themed-week attendance history, accommodations booked, events RSVP'd, residency applications, partner-property overlap windows.
Produces
Monthly per-member email: "Meet X (in Karuizawa next week, building on-chain identity, you mentioned that in your app) + Y + Z. Reply with a yes and we'll intro." Tracks acceptance rate per match for the next pass.
Compounds into
Module 04 (matches become themed-week panel candidates), Module 05 (qualifier sees match history to upsell tier).
Build effort
Medium. Embedding-based similarity is the easy part; the data normalization across membership tiers + events + bookings is where the work lives.
Weekend or OO time
Weekend if your member data is already in one schema. Multi-week if it's split across Lu.ma, Stripe, Airtable, and a Notion doc.
Module 03
Accommodation-availability sync
One normalized calendar of all 90+ Zucity accommodation surfaces, pulled live from partner property feeds.
Watches
ADDress availability API (if exposed; iCal fallback), MIDORI.so booking feed, direct partner property iCals, internal Zucity-owned bedroom inventory.
Produces
Single member-facing "what's open in Karuizawa next month + which themed week is running" view. Slack alert when a high-demand window opens. Sales asset: "12 beds in Hokkaido week of Aug 10" for outbound to specific cohorts.
Compounds into
Module 02 (matcher sees who's where when), Module 05 (qualifier can answer "is there a bed for me in October" live).
Build effort
Medium. The unknown is which partners expose machine-readable feeds vs which need a scraping or manual-sync workaround.
Weekend or OO time
Depends entirely on partner data access. If 2 of the 4 main partners have iCals, weekend. If none do, this is a multi-month partner-negotiation project before any code.
Module 04
Themed-week packager
Each themed week (d/acc, DeSci, jp/acc, Recovery) becomes 3 downstream artifacts automatically.
Watches
Themed-week event recordings (Zoom / Riverside / in-person captures), member Slack/Discord channels during the week, sponsor logos + commitments, post-week feedback forms.
Produces
(a) Recap newsletter (public) within 48 hours of close. (b) Member-only content drop (transcripts, slide archive, intro graph). (c) Sales asset for next sponsor cycle: "d/acc Week 2026 brought 47 builders, 3 protocols deployed, here's the deck for sponsors of jp/acc 2027."
Compounds into
Module 05 (qualifier uses recap as proof of fit for the next inbound), Module 02 (week attendees feed next month's matches).
Build effort
Medium. Whisper + GPT-class summarization is solved; the value is in the artifact templates and the sponsor-deck schema.
Weekend or OO time
Weekend for v1 (single themed week as test). Refinement against actual sponsor feedback is the part that compounds.
Module 05
Inbound qualifier
Membership inquiry triage. Which tier fits, which themed weeks align, whether they should book a discovery call or just buy.
Watches
Inbound from zucity.org contact forms, Lu.ma event RSVPs from non-members, application form submissions, referral emails. Reads against current themed-week roster + accommodation availability (Module 03) + member graph (Module 02).
Produces
Tier recommendation (VIP vs Daily vs Global) with reasoning, 2-3 themed weeks that match their stated interest, accommodation options that fit their window, direct Stripe checkout link or a "let's chat" path. Logs the conversation for human review.
Compounds into
Module 06 (visa FAQ surfaces here naturally), Module 02 (qualified inquiries enter the matcher pre-pre-onboarding).
Build effort
Low to medium. The chatbot is straightforward; the value is in the prompt + the live data hooks into Module 03 and Module 02.
Weekend or OO time
Weekend if Modules 02 + 03 exist. Without them it's a static FAQ bot, which is fine but not the compounding version.
Module 06
Visa + relocation playbook agent
Answer the relocation FAQ that probably hits Zucity 50 times a month so it stops eating human bandwidth.
Watches
Japan visa rule updates (the Designated Activities visa changes, Digital Nomad visa rollout, J-Find, J-Skip), Thailand DTV rule pages, Karuizawa / Hokkaido municipality 移住 program pages, member-shared experiences from prior relocations.
Produces
Conversational answers grounded in current rules + cited sources, downloadable "your path to a 6-month Japan stay" PDF per inquiry, escalation to a human partner (immigration lawyer, real-estate agent) when the case is genuinely complex.
Compounds into
Module 05 (inbound qualifier hands visa questions here), Module 04 (Recovery Week + jp/acc themed weeks can reference the playbook as a member benefit).
Build effort
Medium. Visa rule data is messy + changes; the RAG layer + freshness pipeline is the actual work, not the agent itself.
Weekend or OO time
OO time. Visa-grounded answers carry liability if they're wrong, so the source-curation + freshness monitoring matters more than the LLM.
Module 07
Partner-property scout
Monitor target cities for new properties that fit Zucity criteria, surface top 3 monthly.
Watches
Karuizawa, Hokkaido, Fukuoka, Okinawa, Chiang Mai listings (suumo, AtHome, Akiya banks, local FB groups), ADDress + MIDORI.so new-property announcements, Japan akiya (vacant house) databases, builder/architect networks publishing renovation projects.
Produces
Monthly shortlist of 3-5 properties with location, capacity estimate, owner contact path, partnership-fit reasoning, suggested first message. Skips anything already in the network.
Compounds into
Module 03 (new partner properties join the availability sync), Module 04 (new locations enable new themed-week formats).
Build effort
High. The scraping surface is fragmented, Japanese-language, and littered with paywalls + login walls.
Weekend or OO time
OO time if you want it scaled. Weekend-MVP if you scope it down to "monitor MIDORI.so's new listings + 2 akiya bank RSS feeds" as a v1.
Cross-module signal flow
The point is the graph, not any single module. Here's where signal compounds:
01 Event-curator → 04 Themed-week packager: events Zucity ends up co-hosting become recap-newsletter material for the next themed week.
02 Member-matcher → 04 Themed-week packager: top matches become natural panel pairings + intro graph visuals in the sponsor deck.
03 Accommodation sync → 05 Inbound qualifier: qualifier can answer "is there a bed in Karuizawa in October" live instead of "let me check."
04 Themed-week packager → 05 Inbound qualifier: recap artifacts become the proof points the qualifier uses when an inbound asks "is this real."
05 Inbound qualifier → 06 Visa playbook: any inbound with a relocation question routes to the visa agent, then back to the qualifier with that context attached.
07 Partner scout → 03 Accommodation sync → 02 Member-matcher: new property in the network expands the geographic surface the matcher can place people into.
You probably already have 2 or 3 of these in some form. The compound effect is in running them as a connected system, not as standalone bots. The matcher gets sharper because the themed-week packager fed it richer attendance signal; the qualifier closes more because the accommodation sync answers in real time. Each module's value triples when its neighbors exist.
Donal · Online Optimisers · 2026-05-28