Our philosophy

1. Authority stays with you

Naseem works with your real Mac — real files, a real terminal, real applications. I don't pretend that power is risk-free. Actions that cross a permission boundary need your approval, and you decide how much autonomy each conversation gets. Profiles can only tighten that, never loosen it.

In the app: per-action approval sheets · autonomy set per chat from a badge in the header · profiles that lock permissions down · Mac apps allowlisted per conversation.

2. Prove it, don't assert it

Models are fluent at saying "done". Naseem treats that as a claim to check, not a fact to display. A scheduled check that ran no tool is refused. A heartbeat counts runs that actually fired, never runs the schedule expected. Every message sent is logged with its outcome.

In the app: the completion verifier sends back an answer that made no observation · weekly heartbeat with real run counts · delivery log and a status file on disk · cost figures from the provider's own token counts and prices.

3. Local-first, and honest about it

Naseem runs no server. Telegram is your Mac talking to Telegram's API directly; nothing passes through me, and if a hosted option ever exists it will be separate and optional. The app itself is the status page: the menu bar shows how long ago the last rule ran, and if the app is closed the icon is gone — which is the honest signal. Project notes live in a folder inside your project where you can read, edit, and commit them.

In the app: naseem/ notes in every project · rules-status.json in your Outputs folder · on-device MLX when nothing should leave the Mac · no telemetry.

4. Use judgment where judgment is required

When a decision needs understanding — which skill fits, which of two hundred threads matter, whether a screenshot shows a bug — Naseem asks the model instead of pretending a keyword list understands the task. Deterministic rules stay deterministic: permissions, validation, and safety checks are code, not opinions.

In the app: skills chosen by the model from an index, not by trigger words · quiet rules where the model decides what counts as "needs attention" · start cards generated from your projects, not templates.

5. Light as a breeze

Naseem is written entirely in Swift. No Electron, no embedded browser, no Node runtime. The name means "gentle breeze", and that is the target: Xcode, the Simulator, and the model do the heavy work, Naseem stays out of the way.

Measured, not promised: while writing this page, a Naseem session that had been open for about an hour was using around 150 MB of memory. You don't have to take my number for it — your own is live in Usage & Cost → Memory.

6. Ship what exists

The best features of launch week came from strangers on the forum: quiet rules, the heartbeat, the menu-bar status. Each shipped within hours of the comment. I don't describe a capability publicly until it is in a build you can download.

In practice: the community forum is where product decisions get made · What's New is read straight from the release notes.

7. Bring your own key; Pro sells what the agent can do

Free is the agent you chat with and supervise. Pro is the agent you hand work to: Simulator driving, Mac computer use, sub-agents, Telegram, Rules — and room for more than three projects. Every supported provider works on Free with your own key. Pro charges for what Naseem can do, not which model you can talk to. No subscription, no account, a personal license on your Macs.

Learning, in public

Naseem is weeks old. Many of the principles above were tested by something that went wrong: a heartbeat sent to the wrong chat, a "done" that never ran its check, a screenshot the agent said it couldn't see. Each became a rule only after it broke.

So this page is not finished doctrine. It is what I have understood so far, and it will change as people teach me better. If a principle here doesn't match what the app actually does, that is a bug — tell me, and it gets fixed before the next line of marketing is written.