Our work Prototype · closed beta Built end to end Waitlist open

Roxy — an assistant that does not forget you.

A private AI assistant with permanent memory, on a dedicated deployment per user rather than a shared endpoint. We built every part of it. Currently in closed beta.

THE LIVE SITE

Prototype · closed beta AI SaaS · Private assistants

The unOpen.AI homepage introducing Roxy, a private AI assistant that remembers who you are. — unopen.ai — homepage, 1440×900 unopen.ai →

Visit unopen.ai → What Roxy does → Pricing → llms.txt →

THE PROBLEM ROXY EXISTS FOR

Every conversation starts
from zero.

Standard assistants forget. You explain your business, your preferences and your constraints, get a good answer, close the tab — and the next morning you are a stranger again. The industry calls this a context window; users experience it as hiring someone new every day.

Roxy is built the other way round. Memory is the product, not a feature bolted on: a vector-backed long-term store that accumulates, plus retrieval that surfaces the right thing at the right moment rather than everything at once. It runs on a dedicated deployment per user; model calls go to the provider the user chooses under that provider's data terms, and we never use their data for training — because an assistant that knows everything about you is only acceptable if you hold the keys.

It also takes action — Google Workspace integration (in beta), mail, calendar, scripts — which is the line between an assistant and a chat window, and the line where the engineering gets serious.

AT A GLANCE

STAGE: Closed beta
MODEL: SaaS, tiered
DEPLOYMENT: Per-user private

THE CONSTRAINTS THAT SHAPED IT

Roxy is our own product, which means we paid for every one of these decisions ourselves. That is worth knowing when you read them: nobody was talked into this architecture, and nobody else absorbed the cost of getting it wrong.

Private has to mean something structural

An assistant advertised as private cannot run on a shared endpoint with a promise attached. So each user gets a dedicated deployment rather than a tenant row in someone else’s database. It is the expensive answer, and it is the only one where the claim survives someone actually checking it.

Memory is the product, not a feature

An assistant that forgets you between sessions is a search box with manners. Permanent memory means storage, retrieval and forgetting all have to be designed deliberately — including the ability to remove something and have it actually be gone, which is harder than storing it in the first place.

The model layer had to be replaceable

The underlying language models are third-party. A private assistant that stops existing when one provider changes its terms is not private in any useful sense, so the model sits behind an interface and can be swapped. That constraint costs abstraction work up front and buys the product a future.

It is a prototype and we say so

Roxy is in closed beta. Everything here describes a system that works and is being used by a small number of people, not a finished product with a support organisation behind it. Presenting it as more than that would be the easiest lie on this site to tell.

WHAT WE BUILT

Brand and identity

The mark and the visual system, then applied across the product and the site.

The website

Marketing site, feature and pricing pages, waitlist capture — Laravel and Vite, with an llms.txt so answer engines describe the product from source rather than inference.

The product itself

What Roxy is and does: the memory model, the capability surface, the tiering, and the decisions about what it deliberately will not do.

The backend

A dedicated deployment per user rather than a shared multi-tenant endpoint, with a vector-backed long-term memory. Model calls go to the provider the user chooses under that provider's data terms; we never use user data for training.

Making Roxy feel real

The hardest part and the least visible: persona, voice, memory recall that surfaces the right thing at the right moment, and pacing that reads as a person rather than a completion. This is context engineering wearing a personality.

The SaaS around it

Tiering from individual through business, the pricing model, and the commercial shape of a product sold on privacy rather than seats.

WHERE OUR WORK ENDS

The underlying language models are third-party — Roxy is the system around them: the memory, the private deployment, the action layer and the personality. Everything in that list is ours.

THE DECISIONS THAT MATTERED

What we chose, and what it cost

A deployment per user instead of multi-tenancy. The conventional answer is one application with tenant isolation enforced in code, and it is cheaper to run by a wide margin. We took the other road because the product’s central claim is privacy, and isolation you can point at beats isolation you have to be trusted about. The cost is operational: provisioning, upgrades and monitoring are all harder when there are many small deployments rather than one large one, and that is a real ongoing tax rather than a one-off.

The memory system is ours; the language model is not. Roxy’s behaviour comes from what it remembers and how that is retrieved, which is the part we built. The reasoning comes from third-party models behind a swappable interface. Being clear about that division is the difference between a product and a wrapper, and it is also what makes the provider question answerable rather than awkward.

A site that ships almost no JavaScript, and one thing we have not fixed. The measured figures below are the result of the same approach we take on client work. They also record that none of the images are in modern formats — that is our own site, our own backlog, and it seemed dishonest to publish a performance section that quietly omitted the number we came out worst on.

MAKING AN ASSISTANT FEEL REAL

The hard part is not the model.
It is what you hand it.

“Feels human” is not a prompt. It is a retrieval problem wearing a personality: knowing which three things out of ten thousand to surface for this message, carrying forward a decision made six weeks ago without dredging up the whole conversation, and recognising when the honest answer is that it does not know.

Most of the work is deciding what not to put in the context window. An assistant that recalls everything is as useless as one that recalls nothing — it just fails more expensively. The memory has to forget usefully, which is a design problem before it is an engineering one.

ONE MESSAGE THROUGH ROXY

Message

plus who is asking
Recall

vector + recency
Select

what earns the window
Reason

with the persona
Act

mail · calendar · scripts
Ask first

if consequential
Remember

write back to memory

Lower box = confirm before acting Marker = one message end to end

The write-back at the end is what makes tomorrow different from today — and the confirmation branch is what stops an assistant with mail access from being a liability.

The unOpen.AI features page, covering privacy, memory, voice and personality, and Roxy’s core capabilities. — unopen.ai/features — the capability surface unopen.ai →

The unOpen.AI pricing page showing the Roxy, Roxy Pro and Roxy Business Pro tiers. — unopen.ai/pricing — sold on privacy, not seats unopen.ai →

MEASURED

1.4 KB

JavaScript shipped

33.3 KB

CSS shipped

26.3 KB

HTML document

414 ms

Time to first byte

Images in modern formats

Measured on 28 August 2026. Taken from a cold request with Accept-Encoding pinned to gzip. Transfer sizes are compressed bytes over the wire, first-party assets only. A marketing site in beta is a small surface — these are here because we publish the same figures for every project, not because four pages is an achievement.

curl -sS -o /dev/null -H 'Accept-Encoding: gzip' -w 'TTFB %{time_starttransfer}s HTML %{size_download} bytes\n' https://unopen.ai/

THE STACK

Application

Laravel
Livewire
Flux UI
Vite

The assistant

Vector long-term memory
Tool and action layer
Per-user private deployment

Integrations

Google Workspace (beta)
Gmail
Calendar
Custom scripts

Chosen for this project. The model layer is deliberately swappable — a private assistant that dies with one provider is not private in any useful sense.

QUESTIONS

QUESTIONS — 4

A small group of invited users are running Roxy against their real work, and the waitlist is open to everyone else. It is not feature-complete and we are not pretending otherwise. We include it because current work says more about what a studio can do than a finished thing from two years ago.

A context window is what fits in one request; memory is what survives between them. Roxy writes back after each exchange and retrieves selectively on the next, so the useful thing from six weeks ago is available without carrying six weeks of transcript. The engineering problem is selection, not storage — deciding what earns a place in the window is where the quality lives.

A dedicated deployment per user rather than a shared multi-tenant endpoint, and we never use user data for training. Model calls go to a third-party provider under that provider's data terms, which we state rather than hide. The model layer is deliberately swappable, because a private assistant that dies when one provider changes terms is not private in any meaningful sense.

Yes, and this page is the argument for it: memory, retrieval, an action layer and a personality that holds together are the same problems in any assistant. What we would push back on is building one because assistants are fashionable — the question worth answering first is what it should remember and what it should be allowed to do.

Keep reading

Custom LLM Orchestration

30-minute technical call · no deck