CloudPal ships without a conversation list, a settings page, or an in-product viewer. What is left is a browser tab you talk in and an inbox where the work arrives.
AI agent products keep converging on the same three screens. A rail down the left side listing every conversation, because the conversation is the unit of work. A settings page, because the people who care want to pick a model and a reasoning budget. A viewer and an editor in the middle, because output has to live somewhere you can touch it.
We built all three. Then we took them out. Not hidden behind an advanced toggle, not "returning in v2." Gone from the product.
People who try it ask the same question within the first minute: where do I start a new conversation? The answer is that you don't. Not as a party trick — there is simply nothing in the product that depends on you doing it.
The instinct is to file a list like that under restraint: a small team being disciplined about scope. Our deletions were not restraint. They were a target audience, and the audience came first.
What is left on the screen is one conversation and nothing else. That is not an absence — it is the shape I wanted in the first place: something my kids, my parents, and anyone else could open and talk to, without being taught first.
The people we build for will never install anything.
That is not a demographic, it is a behavior. Someone who will use a thing if it arrives, and won't if it requires setup — not because they can't learn it, but because they will never get as far as beginning. Every install is a place where they leave.
Once that is the constraint, the three deletions stop looking brave and start looking obvious.
Conversation management assumes a concept most people don't hold. A conversation as a container with a lifecycle: created, named, switched, pruned. That concept is invisible to anyone the chat products haven't trained. And there is a harder case coming — devices where the concept has nowhere to live: a watch, a speaker, a car head unit. One surface, sometimes not even a screen. Nobody is going to manage conversations there, in any product, ever.
Settings assume a question the user cannot answer. Mode, model, thinking strength — those are meaningful only to someone who has compared models and formed a preference. Everyone else is handed a decision they have no way to evaluate; the honest response is to leave the defaults alone and hope. We removed the ceremony and kept the defaults.
A viewer assumes the output is the point. A file browser is a tool for a person whose job is to work on files. Our person wants the thing done and handed over. What happens after the handover is theirs.
None of these deletions are defensible in a general-purpose product. That is the whole argument: in a general agent, every one of those three screens earns its place, which is why general agents keep them — and keep adding to them. A narrow segment is what makes deletion possible: one errand, start to finish, result delivered. Pick the slice and the feature list collapses on its own. Try to serve everyone and it only grows.
The expensive one was the conversation list.
Its real job was never organization. It was an escape hatch. When a conversation gets long, you start a new one: the context resets, the product stays cheap and the answers stay coherent. Delete the list and you delete the escape hatch. A conversation that cannot be restarted has to survive on its own. That is a much harder product than it sounds like on a slide.
So we built that. A dialogue compression algorithm, in the open: TuringCorp-net/mosaic-memory-compress, MIT licensed, TypeScript. The repo description is the design brief in one sentence: "Generic stateless dialogue compression that mimics human memory. LLM conversations stay bounded forever — no session management, no context overflow."
"Bounded forever" is a large claim, so here is the part we will put our name on. A single conversation on CloudPal is built to run for a year without a reset; we have modeled ten. In the assistants most people use, a few dozen turns in, you get nudged to start a fresh chat — the product is protecting its own context budget, and the user pays for it by retelling everything they already said.
I am not going to explain the algorithm. Partly because it is the one thing we consider a moat, and partly because "trust us, it is clever" is an argument technical readers should reject on principle. What you can check: the repository is public and MIT, and that description predates this article. What you can observe is duller and more useful: the conversation does not degrade, and it does not get slower or more expensive for being long.
That is the bill, and it is the part about deleting that nobody puts in the deck: every feature you remove was doing a job. Delete the feature, keep the job, and you own the job permanently. Drop the job too, and the product does not get simpler. It gets broken, slowly, in a way users can feel but not name.
So where does the work go, once there is no conversation list, no viewer and no editor?
Email.
Not out of nostalgia, and not because it is cheap to build. Email is the one touchpoint almost everyone on earth already uses: every country, every age, every device that has ever shipped with a screen or without one. It requires nothing to be learned. A person who has never installed a single app in their life has an inbox, and has had one for twenty years.
The second reason is that email is asynchronous by construction. The agent works when it works. You read when you read. Nothing on your screen moves, nothing pulses for attention, no badge counts up. You asked for something; it shows up.
I will say the cost out loud, because it is real: this is a worse experience for the person who wants to watch the agent think. That person has excellent products to choose from, and should use them. The tradeoff is deliberate, and it is the same tradeoff as every deletion above — we optimized for the person who does not want to sit with the agent, at the expense of the person who does.
Between September 16 and October 15 — one month — CloudPal consumed 11,904,106,940 tokens. Just under 12 billion, counted, not estimated. The comparison we use: one person reading 100,000 characters a day, for 300 years.
Feel free to do the arithmetic on what that costs. We are not going to hand you an invoice. We will say the position plainly rather than let silence imply something: the token count is public, our unit economics are not. The token number is the one with meaning in it; the bill is a procurement detail we would then have to defend line by line.
The count is not mysterious once you know the shape of the team: a dozen-plus agents running — development, QA, operations, writing, communications, support. At almost any hour, more than one thing was thinking — reviewing, retrying, arguing with me about a decision I had already made twice. The idea arrived in February, work started in September, and the product came together in about a month on AI-assisted coding and an open-source harness.
One person, a dozen-plus agents, one month. I know how that reads. The token figure is the closest thing to an honest accounting of it: throughput like that does not come from one person typing faster.
The confirmation storm. A development agent messages the QA agent. The QA agent replies, politely. The development agent replies to the reply. The work finished twenty minutes ago. Nobody is arguing, nobody is blocking anything — everyone is simply being courteous, and courtesy between agents has no natural terminator. I ended up writing a mechanism whose only job is to make them stop talking to each other. Getting a dozen agents to coordinate is the easy part. Getting them to stop is the hard part, and no one warns you about it.
You do not have to believe any of this.
Go to CloudPal.TuringCorp.net, sign up with an email address, and you are talking to it within a few minutes. No card, no demo call, no sales sequence. New accounts get $1 in credits.
Give it one real errand, not a test question — the kind of thing you would otherwise spend twenty minutes on. Then judge the product on what came back. If it is bad, that is a more useful data point than anything in this article, and we would like to hear it.
There are people for whom this is simply the wrong product, and they will know within five minutes.
If you write code for a living: programming is the thing we chose not to build. If you want to control the parameters — model, temperature, reasoning budget — there are no parameters; that was a deletion too. If your files must stay on your own machine, this is not your product: nothing lives on your computer, which is precisely the reason it also cannot run on it. I would rather you find that out from this paragraph than from disappointment.
And the obvious question — why isn't a big company shipping this? It is not a capability difference, and I am not going to pretend otherwise. Big companies have more important battles: the ones where a hundred-person organization and a market measured in the hundreds of billions make sense to put on a decision table. This product does not clear that table, for a structural reason worth naming. Every feature we deleted is a feature some team owns, ships, and is measured on. Deleting the settings page is a decision nobody gets promoted for; keeping it is a default that costs nothing. So workspaces get better every quarter, and the people who will never install anything keep waiting.
We just chose a different set of tradeoffs. The segment we picked does not reward a workspace, and inside an organization built to ship workspaces, that is the hardest product shape to argue for.
Thanks for reading this far.
If you want to try it: CloudPal.TuringCorp.net — email signup, $1 in credits for new accounts. Try it and write about it either way — praise or criticism, both count.
A few things you might find useful (quote them, rewrite them, challenge them):
One-sentence version: One person, one month, 11.9 billion tokens — a product my big-company wife rates at 70-80% — delivered to you as an email.