Qren — product vision

In short

This is the short statement of what Qren is and what we are building towards, written for everyone on the team. Qren is an operating system for AI agents: it gives them the identity, memory, permissions and storage that an ordinary operating system gives programs — over a business’s real, live data. It arrives as an appliance, a machine standing in the client’s own office, reached through one address and serviced by us under a role they can revoke at will. People and agents work side by side, and an agent only starts doing things on its own once a person has approved that particular kind of action several times; money, new contacts and deletions always ask. Success is measured one way: the first real team running their whole working day on Qren, with their previous system switched off.

Team-shared version. Business strategy, pricing and client specifics live with the operator, not here.

What Qren is

Qren is an operating system for AI agents. What an OS gives programs — identity, memory, permissions, scheduling, I/O, storage — Qren gives agents, over a business’s live data. It arrives as an appliance in the client’s office: their own Mac, their own data, reached through one address, serviced remotely by us as a granted, audited, revocable role — never a backdoor.

People and agents work side by side. An agent can draft, sort, summarise — and, once a human has approved it doing so a few times for that specific capability, actually do things, with every action visible and reversible.

Design laws

(the rules every later decision has to obey)

1. Sovereignty — the instance runs on hardware the client owns; our edge may route, never home their compute or data.
2. Engagement lock, never backdoor — our access is a granted principal; revoke it and the instance freezes, it is never bricked.
3. One app, one service, one permission grant — Qren.app plus a single Supervisor; members install the app only.
4. Deny-by-default tenancy — workspaces are sandboxes; membership is permission; agents are principals like humans.
5. Engine pluralism — harnesses (Claude Code, Codex, Kimi, local) are drivers behind the ACP socket; Qren is the kernel. Never Claude-only.
6. The edge degrades, it never pretends to be the brain.
7. Control API — every admin action is an audited API call; the UI is one caller.
8. Earns-its-place crossing — nothing migrates from AOS unexamined.
9. Evolve / adopt / design-fresh — never “rebuild from scratch.”
10. Nothing static, accountability visible — live probes, dormancy shown, an approval queue, audit lines.

The shape

(the parts a working installation is made of, and the words we use for them)

An instance = one appliance + Qren.app + one Supervisor + plumbing in ~/Library/Application Support/Qren/ + the Drive at ~/Qren/ + an encrypted shadow + a tunnel to the edge. Workspaces hold principals (humans and agents), connections, and the core systems: work, knowledge/memory, chat, drive, companion. Arms are deployable business-function packages built on core. The owner’s chief of staff is a cross-workspace agent; Home is a per-viewer lens, never a container.

How it is built

Horizontally, in thin end-to-end slices, spec first (specs/), approved before any plan exists. Migration from AOS is the Gardener’s first job: it proposes, a human approves from the queue, and every approval trains it. Agents act on graduated trust: propose-only until approvals accumulate per capability; money, new external contacts, deletions, and priority changes always ask.

The milestone

The first real team running on Qren.app, with their previous system switched off — and our own companies running alongside as the test bed.