Private, with clear boundaries.Roxy is a private AI assistant with permanent memory, on a dedicated deployment per user rather than a shared endpoint. We built it from nothing: the mark, the site, the product design, the backend, and the conversational work that makes Roxy feel like a person rather than a prompt box. Currently in closed beta with an open waitlist.
Roxy is a private AI assistant with permanent memory, on a dedicated deployment per user rather than a shared endpoint. We built it from nothing: the mark, the site, the product design, the backend, and the conversational work that makes Roxy feel like a person rather than a prompt box. Currently in closed beta with an open waitlist.
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.
The mark and the visual system, then applied across the product and the site.
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.
What Roxy is and does: the memory model, the capability surface, the tiering, and the decisions about what it deliberately will not do.
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.
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.
Tiering from individual through business, the pricing model, and the commercial shape of a product sold on privacy rather than seats.
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.
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.
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.
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 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.
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.
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.
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.
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/
“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.
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.
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.
Tell us the job you would hand over if you trusted a machine with it. In one 30-minute call we will tell you whether it should, what it would take — and if it should not, we will say so.
What we built, what stage it is at, and a link to the live thing wherever there is one.
yourOS is an operating system with an AI at its heart. You talk to it like a person, out loud or typed. It makes your calls, plans your days and works on your projects with a crew of agents, on your own private server. Our own product, built from the first commit; the waitlist is open.
Website, backend and app assets for Sonora, a free AI sound-therapy app on iOS and Android published by Cognitive AI.
Brand, website, prototype, apps on five platforms, the AI backend and the algorithm-intelligence pipeline for Podswap, a social growth engine that runs without a human in the loop.
In closed beta: Roxy, a private AI assistant with permanent memory running on infrastructure the user owns. Brand, site, product, backend and conversational design.
Live at coherence.com: brand identity generated with AI agents we directed, the motion system and website for the group behind Sonora, AboutAI, WakeUp and MudShadows. Agent work remains in build.
Live at domainbooth.com for DomainBooth, a premium domain brokerage: a new animated mark, every page redesigned and rebuilt with designed mobile layouts, and a custom CMS for its sales record, featured names, press and enquiries.
Apps, platforms and campaigns for these teams, long before the AI work. Every one is written up on the work page — what we did, and where our part ended.
