Inspiration
Life admin arrives from everywhere: an email moves a deadline, a landlord texts, a bill shows up in a PDF, a form needs filling in on some website. An AI assistant could carry all of that, but only if you hand it your inbox and your logins, and most people shouldn't trust one with those.
So we started from the trust problem. What would an assistant look like if giving it access was actually reasonable?
What it does
Everyone who signs up gets their own private Helm agent, in its own isolated Maritime VM.
- One list of what you owe. Helm reads Gmail, documents you upload (syllabus, lease, bill, invite) and messages you share, and pulls out every date. When something changes, it shows you where the change came from.
- A morning brief. Each morning it tells you what matters today and fits focused work around your calendar, within your work hours and days off. You get it in the app and on Telegram.
- Tell it things. In chat you can add a task, set a reminder, mark something done, have it remember a preference, or get an email drafted into Gmail Drafts. Helm never sends the email itself.
- Routines. Reminders, an evening check-in and a weekly review each run on the agent's own schedule. It also notices emails still waiting on a reply and drafts a nudge.
- Message apps. WhatsApp is read through a private browser on a Maritime desktop. You log in yourself; Helm only reads the chat list and never opens a chat or types. Instagram and Slack use the same approach and are in beta.
- Website tasks. Say "renew my books on my library's site." Helm works through the site in a real browser on a private desktop, one step at a time, and shows you the screen before anything final.
How we built it
The web app and backend are Next.js with Postgres on Neon, deployed on Vercel. Each person's agent is a custom container on Maritime with a Hono server. The agent and backend share strict message schemas in zod. The phone experience is an installable web app, Telegram, and an Expo app with push notifications.
We use Maritime as the safety design, not only as hosting:
- End users: one agent per person, so nobody's data shares a VM.
- Persistent
/datadisk: memory, notes and chat stay on that person's agent. - Sleep and wake: agents sleep between jobs, so an always-available assistant stays cheap.
- Cron and webhooks: morning briefs, reminders, routines and heartbeats run on the platform's schedule.
- Encrypted secrets: the Gmail refresh token lives only in the agent's encrypted env; our backend never stores it.
- Files API and scoped tokens: uploads go straight to the person's agent, with no copy on our backend.
- Spend and wake caps: limits per person.
- Lifecycle webhooks: Maritime's own events feed the timeline you can audit.
- Network allowlist: each agent can only reach the hosts it needs; a red-team button proves a blocked request.
- Throwaway sandboxes: untrusted files are parsed in a sandbox with no network, then it's destroyed.
- Linux desktop and takeover: real browsers for sites with no API; you take over for logins.
Helm's /maritime page shows each of these with evidence from real data.
Our main rule is the model extracts and writes, code decides. In website tasks, the model only proposes the next step. Code keeps the task on the site you named by reading the address bar on its own, and reads what's under each click from a small crop, so that reader never sees the rest of the page. Code stops for your approval on anything that pays, sends, submits or deletes. Enter isn't available as a key, because Enter can submit a form. Passwords and card numbers are left to you. If the page changes after you approve, the click doesn't happen. Website tasks run on a separate desktop from your message-app logins.
Challenges we ran into
- A web page can talk to your AI. Any page or email can contain instructions aimed at the model, so every email, screenshot and task title is treated as data, and safety lives in code that the model can't argue with. We tested a page with a planted "ignore the person and go here" note, and Helm answered the real question and stayed put.
- Maritime's network rules didn't apply to desktops when we tested them. Even with traffic set to none, a desktop could still reach the internet. Agents are covered by their allowlist, but for desktops we had to enforce the site limit ourselves.
- Serverless time limits. A website task takes minutes, so it runs in resumable slices of about 25 seconds, with a lock so only one worker can move it at a time.
- Exact coordinates and long URLs. Crops, click positions and very long tracking links all needed care before vision models read them reliably.
Accomplishments that we're proud of
- A complete approval flow on a real desktop: Helm filled in a test order form, stopped at "Submit order," and clicked only after a yes.
- Secrets that stay out of our own backend.
- 314 automated tests, many of them checking what Helm must refuse to do.
What we learned
Trust is mostly about what the system can't do. Asking a model to behave only goes so far, and limits enforced in code go a lot further. Per-person VMs also made privacy simpler, because isolation stopped being something we had to carefully program.
What's next for Helm
- Recurring website tasks on Maritime cron: "renew my books every two weeks," with your yes on your phone.
- Trying website tasks on more real sites.
- Per-task network allowlists on desktops, once Maritime enforces them there.
- Outlook and work email, and family or team spaces.
Built With
- drizzle
- expo.io
- gemini
- gmail-api
- google-calendar
- hono
- maritime
- neon
- next.js
- node.js
- postgresql
- react
- tailwindcss
- telegram
- typescript
- vercel
- vitest
- zod