Why We Run Our AI Agent on Your Mac Instead of a Cloud Computer

A lot of personal AI agents now come with their own computer: a virtual machine in the cloud with a browser, a file system and a model driving it. It's a clean design. The agent gets a sandbox it fully controls, and nothing it does can touch your machine.

The catch shows up on the first real task. Your files are on your laptop. Your logins live in your browser. Your mail, calendar and the odd desktop app your team uses are all local. So you upload documents, sign in to your accounts again on a remote machine, and download whatever it makes.

We build Nico, a personal agent for the Mac, and we went the other way: the agent works on the Mac you're already using. This post covers the design choices that fell out of that, and a few things we learned building it.

Two Agents Behind One Character

Nico shows up as a small character on your desktop. You hold the right ⌘ key, say what you need, and let go. Behind that there are two agents with very different jobs.

The front agent talks with you. It has to answer fast, follow speech that changes its mind halfway ("Thursday, no, Friday"), and stay available while work is running. It doesn't do long tasks itself. It works out what you mean, hands a task off, and decides when to tell you how it went.

The Worker does the work. It plans, reads files, works in your apps and browser, makes what you asked for, and checks its own results. Tasks can take minutes, get queued, pause, and resume after the app restarts.

Splitting them keeps voice latency independent of task length. You can ask for a report, then ask something unrelated while the report is still being written, and the front agent answers right away.

Built on pi, With Our Own Tools

The Worker runs on pi, an open-source agent harness. pi owns the loop that sends requests to the model, gets back tool calls and returns results. It also connects to model providers and subscription logins, saves sessions, and retries on errors.

Nico owns everything around that loop: every tool the Worker can call (including replacements for pi's built-in ones), the check before each step, confirmation cards, a log of outbound actions, the system prompt, and what happens when the context fills up.

That last one is a good example of why we split things this way. When the context is full, pi's default is to have the model write a summary that keeps the first 2,000 characters of each tool result. We ran a comparison: the Worker reads three long pages, each ending with a reference number, the context fills up, and then we ask for the three numbers.

• With the default summary, none of the three models we tried got a single number right. Two of them also recorded emails they had already answered as still unanswered.
• With our own compaction summary, all three got every number right.

Our summary also attaches the outbound actions already taken, marked as done and not to be repeated. An agent that forgets it already sent an email will cheerfully send it again.

Every Step Gets a Risk Level

Running on your real Mac means the agent can reach real things, so every step is classified before it runs: do it directly, send it to review, ask the user, or refuse.

• Review checks the step against what the task was authorized to do. Typing into a page or tidying files in a folder you approved goes straight through. Other steps go to an automatic review, and if review says no, the reason goes back to the Worker instead of stopping the task.
• Asking the user is reserved for things that shouldn't be automated. Sending an email from Mail shows a card with the account, recipients, subject, full text and attachments, and it waits for a click on Send. Payments, account authorization and credentials always go back to you.
• Steps with an unknown outcome (say the app quit mid-send) are checked read-only first, for example by looking in the Sent folder, before anything is retried.

Some actions get a floor regardless of what the review thinks: sending, submitting, permanent deletion, sharing and privacy changes are always treated as high risk.

Local Means Your Logins Just Work

Because the Worker runs on your Mac:

• Files are read where they are, and results are saved locally.
• Websites see your usual network and your existing sessions. The Worker uses its own browser on your Mac, or your Chrome through the Nico extension.
• Mail, Calendar, Reminders, Notes, Finder, Preview and other apps are within reach. Desktop apps are driven through cua-driver, and Nico decides which tools and system permissions it gets.
• Memory is stored on your Mac, and you can see, change or delete it.

Bring Your Own Model

The Worker always runs on your own model account: ChatGPT, Claude, Gemini, GitHub Copilot, DeepSeek, Qwen, Kimi, Mistral, OpenRouter, or any OpenAI- or Anthropic-compatible endpoint. Credentials go in the macOS Keychain, and requests go straight from your Mac to the provider you picked. Nico's servers never see what the Worker reads or writes.

If you've already got a coding plan or API key, there's no second AI subscription just to run tasks.

Try It

Nico is free for Apple silicon Macs on macOS 15.4 or later. The Free plan runs tasks on your own model and replies in text. Plus ($15/month) adds voice replies, and new accounts get a 7-day Plus trial with no card required.

Get Nico at nico.app

If you're building agents yourself, we'd love to hear how you handle compaction and outbound actions. Drop a comment.