The most useful AI is one you can tell everything.

Start with what an assistant needs in order to be worth having. Not a chat window you paste things into — an agent that already knows the client, has read the thread, has the pipeline in front of it, and remembers what was said in the meeting last Tuesday. Useful assistance requires context, and context means access to the most sensitive material in your professional and personal life.

Which raises the question the industry has mostly declined to answer: where is it safe to let that happen?

Every capable AI assistant available today requires cleartext access to your work, held under a policy promise, by a company whose revenue often depends on visibility into that data. The assistant is genuinely good. The arrangement is genuinely bad. And you can't fix it by adding privacy to the assistant, because the assistant was built on a platform that reads everything by design.

So we started at the other end. Build a workspace where the vendor structurally cannot read what's inside — messages, documents, files, client records, support cases — and then put the agents on top of that. The cryptography isn't overhead we tolerated on the way to the interesting part. It's the foundation that makes the interesting part defensible.

If you write a document in Notion, the document is encrypted at rest on Notion's servers. If you send a message in Slack, the message is encrypted at rest in Slack's database. Same for Google Docs, Dropbox, Microsoft Teams, and every other workspace tool you use. All of them encrypt your data.

All of them also hold the keys to that encryption.

That sentence is the part the marketing pages skip. Encryption with vendor-held keys protects you from a stranger stealing the database file. It does not protect you from a vendor employee, a vendor breach, a vendor sub-processor, an external party asking the vendor for your data, or a future business decision the vendor makes about what to do with your content. Every one of those scenarios resolves the same way: the keys exist, the vendor has them, and your data turns back into cleartext on someone else's screen.

We didn't notice this for a long time because workspace tools never told us. They said "encrypted in transit and at rest" and we filled in the rest with optimism.

There is a different way. It's the way a safe-deposit box works: the bank holds the box, but only you have the key. The vendor stores ciphertext. You — and only the people you grant access to — can ever turn that ciphertext back into a sentence.

This is called end-to-end encryption with user-held keys. It has a precise definition: the encryption keys are generated on your device, never transmitted to the server, never escrowed in a recovery service, never wrapped in a master key that the vendor controls. The server, no matter who is operating it on a given day, holds bytes that no key in its possession can unscramble.

End-to-end encryption was developed for private messaging. We built it for the rest of your work — and your personal life — documents, files, group rooms, and the inbox-bridged delivery that lets you reach people who don't have Koaich yet. Same threat model. Same trade-offs. Same property: even we can't read your data.

The reasonable objection: there are already good encrypted messengers. Why build documents, calls, a client pipeline, and customer support too? Focus is usually the right instinct, and a workspace that does six things is usually a workspace that does none of them well.

The answer is the agents. An assistant that drafts a client proposal needs the pipeline record, the message thread, and the meeting notes at the same time. Split those across four vendors and the agent can only ever see a quarter of the picture — or you hand a fifth vendor permission to read all four, which is exactly the arrangement we're trying to escape.

So the workspace isn't a bundle of features competing with six specialists. It's the context an agent runs on, kept in one place, under one boundary, with the keys in your hands. That's a thing a single-purpose tool structurally can't offer — and a thing the platforms with the context can't offer privately, because their features depend on reading it.

Here is the part most AI products leave out, and the part we think about most.

There are two ways to run an agent. It can run on your device, where nothing leaves — the model reads your content in the same place you do, and no server is involved at any point. Or it can run in the cloud, where a capable model does far more, and the content of that request necessarily leaves your device to reach it.

We run on-device where we can, and it is the default rather than the upsell. On-device models today are real but limited — they are smaller and less capable than the frontier, and we won't pretend otherwise. For work that exceeds them, Koaich can send a request to a cloud model instead. When that happens, the content of that request leaves the encrypted envelope. We don't describe that as private, encrypted end-to-end, or zero-knowledge, because it isn't. The exact terms are documented in §6.6 of /security, including what our model provider may and may not do with it.

What stays true either way: your storage is still sealed. A cloud agent reads a slice for one request — it never holds a standing key to your vault, your archive, or your history. Using it is a deliberate action on a specific surface, not something running in the background across everything you own. That is the opposite arrangement from an assistant with persistent authorized access to your entire workspace.

And the direction matters more than the snapshot. On-device models get better every year; the share of real work that never leaves your device grows with them. Assistants built on reading everything cannot move the other way — their capability is the access. We are on the side of that curve that improves. The exception shrinks; it does not have to be argued away.

This trust model has costs. The vendor — us — can't help you recover if you lose all your devices and don't save your recovery codes. We can't offer server-side "search across everything you've ever written," because the server can't read any of it; search runs on your device instead, and the index never leaves it. We can't provide a vendor-side audit log of what your team said, because that log would have to contain things we aren't allowed to read.

Each of those is a thing other workspace tools can do. Each of them is a thing we deliberately gave up.

We gave them up because the alternative — keeping the keys around so we could offer these features — would make the "we can't read your data" claim a polite lie. A vendor that can decrypt your data is a vendor that can be compromised, compelled, or quietly repurposed. The strongest possible privacy promise is the one the math enforces, not the one the policy describes.

It's for anyone who has ever paused before pasting client data into ChatGPT — and then closed the tab. That pause is the whole product. There is now a class of professional that the AI boom has structurally left behind: not because the models couldn't help them, but because the intake pipe is forbidden.

The lawyer whose privilege claim has to survive a discovery motion, and who therefore cannot paste a client matter into a general assistant. The therapist whose session notes belong outside any platform's reach. The accountant who shouldn't need a separate compliance posture to know a client's tax data is unreadable by a vendor support engineer. The founder who doesn't want the cap table on a shared drive a sub-processor might one day stumble through. These are exactly the people whose work AI could most obviously improve, and exactly the people who aren't allowed to hand it over.

An agent that works inside the confidentiality boundary is the only form of assistance they can actually accept.

It's also for everyone else. There is no "personal grade" cryptographic step-down in Koaich. Either we encrypt your data or we don't — and we do, the same way, for every user, on every surface.

We won't claim we're "unhackable." Every system has a threat model and ours is no exception — we've documented it publicly and we're commissioning an independent audit. What we will claim is that the threat model excludes us: an attacker who fully compromises our infrastructure still walks away with ciphertext.

We won't call our cryptography "bank-grade" or "military-grade." Those are marketing tropes that sophisticated buyers discount on sight. We use specific, named primitives — nacl.box for 1:1 messaging, a Sender-Key scheme for group messaging (per-group key wrapped per member, rotated on removal), MLS (RFC 9420) for collaborative vault documents, per-document symmetric keys wrapped to each recipient's device, Shamir's Secret Sharing for recovery, WebAuthn passkeys for web auth — and we'll happily walk through them with any security-conscious reviewer.

We won't add a password-recovery backdoor, because the existence of the backdoor would defeat the entire property we're selling. We don't operate AI training infrastructure ourselves. Our AI provider (Anthropic) doesn't train on customer API data — see §6.6 of /security for the full statement. We won't ship a vendor-side content audit log, even when an enterprise buyer asks for one, because building it would compromise the guarantee for every other customer.

And we won't describe the cloud AI path as private. It would be the easiest sentence on this page to write, every competitor writes some version of it, and it isn't true. A boundary you can see is worth more than a boundary we blur — if we're willing to name the one place your data leaves, you have some reason to believe us about the places it doesn't.

And we won't name competitors in the negative. Slack, Notion, Google Workspace, Microsoft 365 — they are good at what they do. They made a different trade-off than we did. We're not arguing they're bad. We're arguing that the trade-off they made should be a choice, and right now, for sensitive work, it isn't one.

The bet under Koaich is that agents are about to be handed the most sensitive material in people's professional and personal lives, and that the question of where that is safe to happen gets asked seriously — by regulated professionals first, because their obligations force the question early, and by everyone else soon after.

If that's right, the winning platform needs a property that can't be added later. A company whose features depend on reading your content cannot retrofit an architecture that prevents it — not because their engineers aren't good, but because the reading is the product. That's the whole reason we spent the hard years on the substrate before the agents. It's the one part you can't catch up on by deciding to.

That bet might be wrong. The product might be right for a smaller audience than we think, or need a few more iterations to land. But the property — privacy as a structural fact of the data, not a vendor pledge — is the kind of thing that compounds. Once you've worked inside a tool that can't read what you write, going back feels like leaving a door unlocked because the locksmith promised they wouldn't come in.

We made the trade-off. The math made the trade-off. The product is the consequence.