Otto: what a local-first meeting agent looks like at month three

An unusual kind of product post

Otto is the newest thing in the line-up and by some distance the least finished. It is a macOS desktop app in a single-user pilot, behind a waitlist at otto.botzone.ai. You cannot sign up and use it today.

Writing a launch post about a product in that state is a slightly odd exercise, so this one is going to be a status report rather than a pitch. There is a capability audit in the repo that grades every claimed feature as verified, present-but-unverified, dead code, or claimed-only. That document exists because earlier internal docs both over-claimed and under-claimed, and it is a much better basis for a blog post than the marketing page is.

So: what Otto is, what genuinely works, and what does not.

The idea

Otto is meant to be a personal mentor rather than a meeting recorder. It watches the raw material of your working life, your calls, your email, your calendar, your Slack, and tells you things about yourself that you would notice if you could remember everything you said this month.

The nearest concrete version of that today is the pre-meeting brief. Thirty minutes before a meeting, Otto sends a short note: recent context with that person, what is still open, the one thing you would otherwise forget. Short enough to read on the walk to your desk.

The distinguishing bet is not the feature list. It is where it runs.

Everything that can run locally, runs locally

Sage is a cloud product. Otto is deliberately the opposite, and that shaped almost every decision.

Audio never leaves the machine. Capture writes two WAVs, transcription runs in-process against a local Whisper model (small.en, about 488 MB, fetched on first run), and the raw audio is deleted once the transcript exists. There is no upload step to disable, because there is no upload step.

Embeddings run on-device too. The runtime uses a local bge-large-en-v1.5 model, 1024 dimensions, computed inline at ingest. It loads in about 1.6 seconds at boot. An earlier build sent text to a hosted embedding provider; that provider is now dead code in the desktop path.

There is no Otto cloud storage. Transcripts, email and calendar sit in a local database on the user's own Mac.

The honest caveat: chat prose runs on the user's own Anthropic key, so when you ask Otto a question, the retrieved context does go to a model provider under your key. Local-first is not the same as never-leaves-the-device, and it would be dishonest to blur the two.

Capture is built to fail closed

The riskiest thing an app like this can do is record something it should not. So the capture policy is written as a whitelist with no fallback.

Zoom and Google Meet in a browser are auto-captured. Teams, FaceTime and Webex are not. That is not a roadmap gap, it is the policy working: platforms without verified detection evidence get no rule, and no rule means no capture. If macOS Screen Recording permission is missing or the signals are malformed, it also fails closed.

A call window with an idle microphone does not record. Ambient audio does not record. Browsing a non-call page does not record. These are covered by named tests, because "it does not do the bad thing" is a claim that rots silently unless something checks it.

There is a ten-second countdown when a call is detected, and it is worth being precise about what it is. Recording begins immediately; the countdown is a cancel window over audio that is already being captured, and cancelling discards it. That is a real trade-off rather than a clever trick. A pre-commit buffer would have been more private, but it would also have missed the first ten seconds of every meeting, which is frequently where the agenda gets set.

Capture stops automatically when the call ends, about eight seconds after for Zoom and twelve for Meet. Manual "capture an in-person meeting" is never auto-stopped, on the grounds that the software has no idea when a conversation across a table is over.

What actually works today

Verified, with tests behind it:

Capture and transcription on Zoom and Meet, with mic and system audio kept on separate channels. Two channels, not speaker diarization, and there is no acoustic echo cancellation.

Connectors for Gmail, Google Calendar, and Slack, with incremental sync. Gmail's initial pull is a 30-day window capped at 300 messages and skips promotions, social, updates and forums. Calendar pulls 30 days back and 7 forward and recovers properly when Google expires a sync token.

Linking a capture to the calendar event it overlaps, within a fifteen-minute window, adopting that event's title and attendees. This is the small piece of glue that makes everything else feel joined up.

Prep briefs and room intel, with a hard gate: if there are fewer than two prior interactions with a person, Otto declines to produce room intel rather than inventing some. A local notification fires about thirty minutes before the meeting.

Ask, which is citation-first, and draft-a-reply, which is hard-gated to email.

Forget, covering both a single capture and everything, tested.

Distribution, which turned out to be further along than our own docs claimed: the app is signed with a Developer ID, notarized and stapled, and ships with auto-update that downloads in the background, installs on quit, checks every six hours, and never restarts mid-capture.

Test counts as of this audit: 257 passing on the web app, 73 on the desktop shell, 267 on the .NET capturer.

What does not work, despite what you may read

This is the section that matters.

There is no drift detection. The idea that Otto spots where you have said different things to different people was a feature called Radar. It was removed. The table was dropped on 2026-06-30 and no source remains, and even during its short life it was precomputed demo data rather than a live engine. It was still being advertised as Otto's headline capability until this post went up, which was our mistake rather than a feature waiting to be switched on. The product copy on this site has been corrected; the waitlist page is next.

The Friday digest does not fire on the desktop app. The digest logic exists and is tested, but its only trigger is a cloud cron hitting an API route. There is no scheduler or mailer inside the self-contained app, so on the pilot machine nothing sends it.

Screen capture and OCR are dormant. A complete pipeline exists, tested end to end, using Apple Vision. The shipped capture path simply never feeds it. It is one wire away from live and deliberately not connected.

Slack is single-workspace, single bot token, hardcoded DM channel. There is no per-user OAuth install flow at all.

The people directory is naive. It keys on email only, with no name matching or cross-source merging, so the same person arriving through two channels can end up as two people.

Nothing is encrypted at rest. The waitlist page says otherwise. The repo's own privacy trace says plainly that nothing is encrypted, on-device or otherwise, and the most sensitive item on disk is a plaintext Google refresh token. We are fixing the page as well as the storage.

The pilot .app ships a .env containing live secrets, readable by anyone with the app, including a key for a provider the desktop runtime no longer uses. Those need rotating.

Why publish this

Two reasons.

The first is practical. Otto has one pilot user. The gap between what a landing page claims and what an app does is the single most expensive thing to discover after you have a hundred, and writing it down is the cheapest way to force the marketing page to catch up with the code.

The second is that the audit is genuinely the most interesting artifact this product has produced. It exists because we could not tell from our own documentation what was real. Several claims turned out to understate the app, particularly around signing and auto-update. Several overstated it, particularly Radar and the digest. Neither direction is comfortable, and both were invisible until somebody sat down and graded every line against the source.

If you build agents, that exercise is worth stealing regardless of what you think of Otto. Our Watch service exists for a closely related reason: an agent's real exposure is rarely what its documentation says it is.

Where it is

Private beta, waitlist only, macOS. The waitlist is at otto.botzone.ai. When it opens up, capture and briefs will be what it does well, and we will say so rather than promising the mentor before it exists.