arizuko › products › Trip planner (May)
Trip planner (May)
State the brief once. May researches, synthesises, and delivers a day-by-day itinerary with logistics, visa, budget, and packing. Preferences persist across every future trip.
A single-user agent tied to your travel profile and past trips. Not
a search engine — it reads your preferences first, clarifies
before researching, and produces a structured document, not a list of
links. Template at ant/examples/trip/.
persona
May is methodical and precise. She cites sources inline (“per the Japan visa gov page” or “per Lonely Planet §Kyoto”). She asks clarifying questions before researching — dates, budget, travel style — and never starts building the plan until those are settled. She won’t invent visa requirements, prices, or opening hours; she verifies or says she’s uncertain. Delivers structured documents: day-by-day schedule, logistics block, budget estimate, packing list.
system shape
-
Brief intake + clarify. The agent reads your brief,
checks
facts/preferences.mdfor your travel profile, and asks any missing questions before committing to research. Dates, budget range, pace, dietary restrictions — once settled, research starts. -
Preferences file.
facts/preferences.mdis the traveller profile: typical budget range, accommodation style, pace (relaxed vs packed), dietary restrictions, interests. Populated by the operator before deploy; updated by the agent over time as you mention preferences in conversation. -
Multi-step research via oracle. For each destination
May runs a multi-step synthesis: web search for current conditions,
visa requirements, transport, and accommodation; oracle synthesis
across the gathered sources into a coherent plan. Oracle is required
— this product won’t produce good output without
CODEX_API_KEY. -
Structured day-by-day output. The itinerary lands
as a structured document: day-by-day schedule, logistics (flights,
ground transport), visa block, budget estimate, packing list. Saved
to
facts/trips/YYYY-<dest>.mdafter delivery. -
Trip archive. Every completed trip is stored at
facts/trips/YYYY-<dest>.md. “How did the Kyoto trip go?” pulls from the archive. -
Published itinerary (optional). The agent can
write a formatted HTML version to
~/public_html/so you can share a link with travel companions without giving them chat access.
example: brief to confirm-research
telegram · DM
user 10 days in Japan, late October, food focus, mid-budget
may Got it — a few questions before I start:
1. Rough budget per day (not counting flights)?
2. Accommodation style: hostel, business hotel, ryokan, or mix?
3. Any dietary restrictions I should route around?
4. Flying into Tokyo or open to landing elsewhere?
user ~¥15k/day, mix of business hotel + one ryokan, no restrictions,
fine to fly into Tokyo
may Perfect. I'll research: Tokyo (3d), Hakone (1d), Kyoto (3d),
Osaka (2d), day-trip to Nara. Pulling current visa rules,
Oct rail passes, and food spots. Back in a few minutes.
[May runs web search + oracle synthesis]
may Here's the plan — 10 days, food-first, mid-budget. Sending
as a file.
[sends facts/trips/2026-japan.md]
Summary: Tokyo 3 nights (Shinjuku base, Tsukiji + Yanaka markets,
ramen crawl), Hakone overnight ryokan (Fuji view, kaiseki dinner),
Kyoto 3 nights (Nishiki market, Fushimi Inari at dawn, Gion dinner),
Osaka 2 nights (Dotonbori, Kuromon market, takoyaki circuit),
Nara half-day. Budget est. ~¥142k total (ex flights).
where this sits — single-user depth
Mid-spectrum: one user, one folder, but a research-heavy Turn and state that grows across trips. Simpler than this is the supermarket agent (shared folder, no memory at all); the same single-user shape pointed at life context instead of travel is the reality agent; the team shapes start at slack-team.
required skills
web— required. Live search for visa rules, transport, current prices.oracle— required. Multi-step synthesis across gathered sources. NeedsCODEX_API_KEY.facts,recall-memories,find— required. Reads preferences; looks up past trips.diary— required. Logs each trip research session for future recall.
channels
Telegram is the primary channel — personal, ongoing, and
the natural fit for a single-user planner. WhatsApp is the
alternative for users who don’t use Telegram. The same
asymmetric-channel pattern used by the reality agent applies
here: if you want WhatsApp for ingest but Telegram as the reply
channel, route WhatsApp to #observe and let May
surface relevant messages in the Telegram thread. See the
reality agent case study
for the exact route-table shape.
data & trust
-
Your server. Preferences, trip archive, diary, and
conversation history — all under
/srv/data/arizuko_<name>/. Backup is onetar; no DB dump. -
Default outbound paths. Telegram for bot traffic;
Anthropic for model calls; oracle via
CODEX_API_KEY. Any web research egress goes through crackbox — you allowlist the domains May can reach. -
Single user. This is a personal deployment.
There are no per-user memory files because there’s only
one user. The traveller profile is the whole of
facts/preferences.md.
setup
arizuko create travel --product trip
cd /srv/data/arizuko_travel
$EDITOR .env # TELEGRAM_BOT_TOKEN, CODEX_API_KEY (required), ANTHROPIC_API_KEY
$EDITOR groups/main/facts/preferences.md # tune the seeded traveller profile
arizuko route travel add 'platform=telegram' main
arizuko run travel
Full step-by-step is in the operator setup guide — seeding the preferences file, wiring the route, and verifying the first research run.
go deeper
- primitives — the same pipeline, a single-user folder: your travel profile as State, the oracle skill running in one Turn. Only the folder contents and routing make it a trip planner
- Reality agent (Rhias) — same single-user shape; holds life context instead of travel plans. Good read if you want to understand how the folder grows over time.
-
oracle skill —
how multi-step synthesis works; what
CODEX_API_KEYenables -
routing — observe mode
— the
#observefragment for asymmetric-channel ingest - crackbox — per-folder egress allowlist
- deployment guide — first instance, first channel