The public site tells the travel story. This page explains the operating model behind it: how AI helped move one real project from first idea to finished public artifact.
The project was simple on the surface: a solo kite trip from Pirna to Montenegro and back. The system behind it handled planning, risk checks, route decisions, private context, family communication, field-note intake, content structure, static-site publishing, privacy review, and post-trip storytelling.
The point was not to automate the human out of the project. The point was to keep momentum: a tired human sends a short Telegram message, a rough thought, a photo, or a correction, and the AI layer helps turn it into structured, privacy-safe public material across the map, diary, gallery, missions, and route status.
The detailed travel plan lives in a private Notaica workspace: booking references, exact lodging, transport codes, payment artefacts, contact data. The public site never reads from there directly. Approved story material is hand-translated into public-safe summaries before it touches the repo.
During travel, dispatches arrive as short Telegram messages — a sentence, a photo, sometimes a voice note. The agent (Hermes / "Ron") categorises them: which day, which mission, which place, what's publishable. Editing and privacy review happen before anything becomes a diary entry.
Astro 6, no client-side frameworks, scoped CSS tokens. The public magazine ships as static language routes with shared content rules, ready to grow beyond the first two languages. Netlify builds and serves. A single Netlify function handles the contact form. There is intentionally no live database, no API, and no live map service.
It was never meant to run itself. The deal was simple: a tired version of me sends a phone message from Velika Plaža, and a readable update appears the next morning. The agent does the structuring. I keep the say over taste and what stays private.
Short Telegram message: a sentence, a photo, sometimes a voice note. Free form. No template needed when you are tired.
The agent maps the message to the right surface: a day entry, a field note, a mission update, a place. It keeps the public language versions aligned and flags anything sensitive for human review.
A nightly commit triggers a Netlify build. The privacy scanner runs first. If the build is green, the new content is live in under a minute.
The build runs a regex-based privacy scanner on every commit. If any of the following appear in content files, the build fails:
This is a safety net, not a substitute for editorial judgment. The agent and the human both treat it as the last line of defence — and the failure mode is "build doesn't deploy," which is the right failure mode for a trip site.
Private booking codes, prices, contact data, payment details and access information stay out of the public site.
This is also why none of this language shows up on the homepage. Nobody should have to understand the workflow to read about a beach. If you went looking for the wiring, though, here it is.
The magazine is for everyone. The workshop is one route, opt-in, off the homepage. Friends and family can read the trip; curious builders can open the system behind it. Same codebase, different depth.
I didn't want the automation to be the show. It runs quietly and never posts on its own, so if it's working you mostly forget it's there. The interesting part is supposed to be the trip, not the plumbing.
Categorisation, drafting, multilingual mirroring: automated. Final edit, photo selection, privacy approval: human. The agent never auto-publishes.
None of this is “AI writes a blog.” It's a project loop with me in it: plan the trip, build the site, take a one-line note from my phone, and push it out across the map, the diary, and the gallery at once — after something has checked I didn't paste a booking code into a caption.
The intelligence sits in the workflow, not in the browser. The public site stays static and reliable; the agentic part lives in planning, context, review, and publishing operations.
A travel project is only one example. The same pattern fits work where the hard part is not having ideas, but finishing them.
A launch or workshop has research, decisions, assets, communication, follow-up, and a public story. The workflow keeps those pieces connected instead of scattered across chats, notes, and half-finished drafts.
A project with other people has context, approvals, documentation, risks, and lessons learned. AI becomes useful when it preserves the thread and helps the team move from decision to deliverable.
A relocation, trip, event, course, or field report has the same hidden problem: too much context, too many small decisions, and not enough momentum. The operator pattern gives the project a spine.
The Montenegro project is the case study. The transferable part is the operating model: how to design an AI-supported workflow around one real outcome.
Turn an idea into scope, constraints, risks, decisions, private context, public outputs, and review points.
Design a lightweight way to capture field notes, voice snippets, photos, corrections, and decisions without forcing the human into a rigid template.
Separate private context from public output, add privacy checks, keep surfaces synchronized, and publish only after human review.
The practical promise is simple: leave with a blueprint for one real project you can move forward with AI. Not a collection of tricks. A working project operating model.