Vora

Vora sells digital sovereignty: your data and your AI live on hardware you own. Its first product, Aegis, is a self-hosted AI server and operating system. The founders say cryptographers built it on a secure kernel, so prompt injection is structurally impossible, which leaves room for an AI more personal and private than a hosted one. I worked with them directly as a contract designer, and this prototype is my answer to what that product's chat workspace should be.

Vora's brand promises calm, but the product is not small: your files, your conversations, your memory, and agents doing real work for you. Calm interfaces usually get there by hiding things, and the two things this one can't hide are data leaving and agents acting.

That split into two problems. Security: self-hosting is the whole pitch, so the interface can't make the case during onboarding and then look like any other chat app afterward, most of all when data is about to move. Structure: Vora isn't a list of dated, throwaway sessions but one persistent agent with topic chats and channels around it, and people need to see that hierarchy or they lose track of where things live.

So details stay folded until they matter, and consent is something you do in the interface rather than a setting you forget about.

Before any screens, I had to decide what you'd be talking to. A conventional chat, like Claude, felt like using a chatbot rather than working with a teammate. Several named agents, each with a specialty, meant remembering which one to ask for what. A single named agent gave people one teammate to build a rapport with and nobody to choose between, so that's what I built.

It costs something: nothing is tuned for a single job, and you can't route work by picking a name. For one person's private assistant that's the right trade, though in a shared workspace, where agents take distinct roles next to people, I'd expect it to flip.

The early wireframes had another choice in them: two modes, an offline Guardian and an online Explorer. We moved that decision into the architecture, so users never make it.

My first pass abstracted security away. The protection was there, but you couldn't see it, and for a product whose whole pitch is where your data lives, that's the one story that has to come through. So the second version puts a checkpoint wherever data would leave the device, showing what goes and what stays.

Self-hosting only means something at the moment data leaves the box. Every assistant eventually sends something out, an email or a web search, and in most apps you never see it happen. For Vora that moment is the whole test, so the prototype stops there and shows you.

When an agent wants to send something off the device, a card shows where it's going, the exact payload, and a "Stays on your device / Leaves your device" split, with three choices: Deny, Send once, or Always allow. Sensitive values become redaction chips you can tap, so you can pull a revenue figure out of an email right before it goes. For email the draft is the payload and you edit it in the card, so what you approved is what gets sent.

Once you decide, the labels change tense: "Stays" becomes "Stayed," "What's being sent" becomes "What was sent." The present tense only describes what the agent intended, and I wanted the record to describe what happened. Nothing touches the web before you consent, and an unsure agent asks one clarifying question instead of guessing.

A lot of what people type into chatbots is really a choice from a list, and typing it is slow on both ends: you write a sentence, the model parses it back into a choice, and any ambiguity costs another round trip. So the prototype puts decisions in the transcript as cards: button groups, editable email drafts, time-slot pickers, product cards with thumbnails.

Speed is the obvious reason. Trust is the one I cared about more. If a preference is buried in a sentence you typed, the model inferred it; if you tapped it, you chose it, and the card stays in the transcript as a record of what was asked and what you picked.

Multi-step questions stack in one container, each answered step collapsing to a checkmark and a one-line summary, and pending decisions collect in a To Do pane. The hard part was keeping it optional. Force people through a wizard and chat becomes a phone tree, so anything a card asks can also be answered by typing, or skipped outright.

Chatbot bubbles set the exchange up as you versus an interface, and every session is disposable. Vora is an assistant you're supposed to live with, so I borrowed from Slack-style team chat instead: avatar gutters, sender headers, hover toolbars. It reads as two colleagues in a shared space, and most people already know it from their jobs. At the center is one persistent chat with your named assistant, with topic chats and channels around it, scoped and disposable.

Threads are where this pays off. Any message can open a thread in a resizable side pane, so a tangent or a sub-agent's work runs next to the main conversation instead of flooding it, and an artifact opened from a thread opens beside it rather than replacing it.

Any message can also fork into a new chat or channel: a model picks the relevant range of turns and titles it, and a "Forked from" link scrolls back to the source. The primary chat is where the relationship lives; channels are where specific work gets organized.

Chatbots with memory rarely tell you where a memory came from. In Vora every memory shows which chat it came from, when, and how often it's been used, and you can edit, delete, sort, filter, or group them. When the assistant saves something mid-conversation, a small system-log toast ("memory · <fact>") tells you right then. Incognito chats cover the other direction: an eye-off toggle, no row in the sidebar, and when you leave, the chat is gone.

This started in Figma, but the work wasn't coming out polished enough and our engineer's time was going to the security and agent architecture. So I took over the front end in code, steering the animations and refining the UI myself, which kept the design moving while engineering stayed on the hard parts underneath.

I built it in vanilla JavaScript, CSS, and HTML, with Claude Code doing most of the typing, and deployed it on Vercel. I skipped a framework on purpose: Vora's engineers could open it, read it, and run it in a browser without installing anything of mine. They built the product separately, so the prototype was my handoff, a running reference in place of static comps.

Testing meant walkthroughs with the founders, my own daily use, and tuning against a live model. The live model mattered most, because the checkpoint and the decision cards only work if they hold up against real, unpredictable output. QA was writing down every response that came back in the wrong shape and changing the interface or the prompt until it stopped.