A walkthrough of Lonely Pine AI: the live client systems, the architecture underneath them, and the three projects you could start on.
Lonely Pine AI is a founder-led studio based in Tokyo, serving clients in Hawaii and beyond. After a decade at a Fortune 10 company, Nalu left in June 2025 to build AI systems for real operators: restaurants, vacation rental managers, boutique resorts, painting contractors. Not demos, not decks. Production systems that answer phones, write orders, and run back offices every day.
Every system below is deployed and in use today. The architecture line under each card is the part you asked about. If a term on it is new to you, that is fine: section 03 walks the whole stack from the top.
Hoku, an AI phone agent that takes food orders on the main line, prices them from the live Square catalog, writes real orders into Square, and texts payment links. Around it: an order tracker that reconciles phone revenue against real payments, a review detection and response layer, and a Telegram control the owner uses to pull an item off the menu, which moves the database and the live voice prompt in one tap.
Steward, a Claude-powered operations platform the whole company uses: pipeline intelligence rebuilt on a reconciled data warehouse, a knowledge graph of the org where document sensitivity inherits role visibility, 21,073 jobsite photos mirrored and joined to the production board, weekly scorecards into Slack, and Quinn, their outbound sales voice agent. A daily job asks the assistant ten questions and checks each answer against the database, so a wrong number pages us instead of reaching an owner.
Malia, a guest-facing voice agent that handles arrival questions and weekly check-in logistics, plus an operations dashboard behind magic-link auth. Underneath it, a full interval-ownership model: 1,617 deeds, 839 owner entities reconstructed from a source that carries no owner key, and a live review queue where staff resolve what the data cannot decide on its own.
Lani, a voice agent that quotes live availability sourced from the real booking site, refreshed by a pre-warming cron across all 72 units. Plus a daily operations board for the front desk where the build fails if a door code, pool code or Wi-Fi password ever appears in the output, a social publishing queue, automated newsletters, and a monthly reporting suite.
Blu, a document-intelligence assistant for a hospitality group managing about 50 associations: ingestion pipelines over their file corpus, threaded conversations, and locked-template reports on scheduled crons. Its document editor returns a list of edits, each carrying a fingerprint of the text it expects to find, and if one anchor fails to match, nothing is written at all.
Operations dashboard on a real database: guest check-in forms routed straight into D1, client-editable tour content, competitor-listing suppression on a scheduled job, and an automated monthly owner report. Guest broadcasts fan out one message per guest, which is how a tropical storm advisory reached the property when a single bulk email would have been rejected outright.
A native mobile app for an international parish, live on the public App Store since July and in tester rollout on Android. Mass and confession schedules, ministry rosters, a weekly bulletin archive, announcements in six languages, a beta feedback pipeline writing into a database, and admin dashboards for the parish office.
The studio's own operating cockpit, on the desktop and now as a native iOS app on TestFlight: daily pulse across every client system, task boards, and an ingest pipeline that captures anything saved into a Slack channel, stores it first and classifies it second. The phone carries a scoped device token, never the master key.
Also live: Gabby, Lonely Pine's own receptionist, answering questions about the business from a searchable corpus of its documents; hawaiicustomtreasures.com, a pro bono small-business site; and Wayfinder AI, the studio's own newsletter and funnel.
Everything runs on the same layered pattern. A client engagement is mostly configuration and integration on top of proven plumbing, which is why one person can run eight production systems. Each layer below says what it is for first, then what it is built with.
What it does: answers and places real phone calls. The customer talks to an AI agent instead of a menu tree. Each agent has its own script, its own list of things it is allowed to do, and rules for how it says numbers out loud, because a phone number read as a figure is useless to the person writing it down.
Why it is a layer: the agent knows how to hold a conversation but nothing about the business, so mid-call it calls our own backend for live answers.
What it does: the actual reasoning. Claude runs the conversations, reads the documents, drafts the reports, and answers questions about a client's own files by searching them first and citing what it found.
Why it is a layer: the model is given tools rather than trusted from memory. It searches, it computes, and every fact on a client surface traces back to something we can point at.
What it does: the code that actually runs. Small TypeScript services deployed to servers we never manage, plus scheduled jobs that fire on their own: nightly reports, hourly syncs, health checks.
Why it is a layer: it started as one shared service and has been split into a dedicated one per client, so a bad deploy for one client cannot touch another. Anything automated fails loud. A broken report pages us; it never silently skips.
What it does: remembers things between calls and between days. Three kinds: a real SQL database for records, a fast key-value store for settings and cached answers, and a vector store that finds documents by meaning rather than by exact wording.
Why it is a layer: every client gets their own database with ownership checks, so one client's data has no path to another's screen.
What it does: talks to the software the client already pays for, in both directions. Their point of sale, their CRM, their call tracking, their email, their chat.
Why it is a layer: this is where most of the real difficulty lives. Vendor systems rewrite their own history, truncate their exports, and report failure as success, so the interesting work is deciding what to trust and proving it.
What it does: the screens people actually use. Staff dashboards, owner consoles, guest forms, and native mobile apps when the product calls for it.
Why it is a layer: every screen is gated. Some by company sign-in, some by a one-time link emailed to a guest. Who can see which rows is a decision made in the backend, never in the page.
What it does: the entire studio is built and operated through Claude Code. Design, implementation, tests, deploys and reporting all run as deep AI-collaborative sessions, with quality rules enforced by machine rather than by memory.
Why it is a layer: this is the actual product of working here. It is the part most shops have not figured out yet, and it is the skill that transfers to anything you do next.
Rather than hand you a task, here are the three live tracks with room on them right now. They are genuinely different kinds of work, so the choice is really about what you want to get good at. We scope the first piece on the call.
The Tokyo parish app, already live on the App Store with real users. The next build is a schedules and assignments layer for ministries that currently open to an empty screen. Self-contained mobile work with people waiting on the other end of it.
A single-page site for a family art gallery and farm shop on the road to Hana. Small on purpose: it is the entire arc of a client engagement, design through launch, compressed. Nalu meets the family next week, so the start date is genuinely open.
Operations tooling for the resort's front office. The nearest piece is letting staff upload a two-page schedule instead of one, which sounds small and is actually the thing standing between the client and running this herself.