The first version of CloudPal had an install step. It was a small one, the kind you write in a week and stop thinking about. Deleting it took three weeks and changed more of the design than anything else we've done.
This is the write-up of what that step was actually holding up, because "nothing to install" sounds like a packaging decision and turns out to be an architecture one.
The machine is usually not yours
The reason to delete it was embarrassingly ordinary. The people who need a document produced are frequently not sitting at their own computer. They're on a borrowed laptop, a work machine they don't administer, a hotel business centre, a partner's desk. And the task in front of them has a deadline attached to it, which is exactly the situation where you don't want to be making installation decisions.
If you have ever hesitated in front of someone else's machine, you know the shape of the hesitation. It isn't really about disk space. It's that an install is a request for a piece of a computer that isn't yours, and every part of that request comes with a promise attached: a background process you now own, a permission you can't audit, an uninstall you'll have to remember on a day you'd rather not think about this at all.
We could have made the installer quieter. Instead we asked what it was for, and the honest answer was: it was for our convenience, not the user's. So we took it out, and then spent the next three weeks finding out what had quietly grown around it.
Once there's no local process, the tab can't own anything
Here's the first thing that falls over. With an install, something keeps running on the machine after you close the window, and the mental model is comfortable: the work is local, the window is a view onto it. Remove the install and the browser tab becomes the only thing on the user's side — and a tab is a terrible owner of anything. It gets closed. It gets suspended when a laptop lid shuts. It gets duplicated. It reloads when it feels like it.
So the run cannot live in the tab. That's not a preference, it's a constraint you either accept early or retrofit painfully. What follows from it is a short list of design decisions that stop being optional:
- The server has to be the only authority on what has happened. Not "the server syncs with the client". The client reports nothing it can't prove, and the record of a run comes from the side that was actually running it.
- Every request has to be safe to send twice. A tab that gets refreshed mid-flight will re-send things, and a person who isn't sure whether it worked will press the button again. If a retried request can produce a second copy of the output, you've built a product that punishes impatience, which is a large percentage of your users.
- Reconnection is a first-class state, not an error. The gap between "closed the laptop" and "opened it on the train" is not a failure mode to be apologised for. It's the normal path, and the interface owes the person a truthful account of what happened while they were gone.
The uncomfortable part is that all three of those are cheap to say and expensive to hold. The tempting shortcut is to let the client cache the state and reconcile later, which works beautifully until two devices disagree, and then the merge logic becomes the product.
An artifact can't live at a path
The second thing that breaks is naming. On a machine, a document is a path: ~/Documents/brief-final-v2.docx. The path is the identity. It's also a lie that only holds while you stay on the same computer.
Once the machine isn't in the loop, "where is it" cannot mean a folder. It has to mean something that survives a different device, a different browser, a cleared cache, a new job. In practice it has to be the account — which drags in the questions that path-based systems never had to answer, and that nobody enjoys:
- What happens to a document when someone edits it on a machine they'll never see again?
- If two people open the same thing and both change a paragraph, whose version is "the" version?
- When someone asks for the same thing next month, is that a new document, or a revision of the old one? Both are defensible. Only one can be the default.
Our answer is deliberately boring: the thing you get is a document that lives in your account, with its own history, and it looks the same from any browser. Boring is the goal. An artifact that behaves differently depending on which machine you're holding is a support burden disguised as a feature.
The permission dialog you never see
Removing the installer removes the moment where the operating system asks the user to trust us. That's a real convenience, and it comes with an obligation that took us a while to state plainly.
An install is also a permission grant. The app gets to touch the drive, read the folder it's pointed at, run in the background. We gave that up. So we don't have a foothold on the machine, and we must not behave as if we do — not in the copy, not in the product's implied promises, and not in the feature list we'd like to have.
That's the reason CloudPal generates documents rather than tidying up the files you already have. It's not modesty, and it isn't a temporary state of affairs waiting on a roadmap. Reading someone's existing files requires precisely the local foothold we just deleted. Saying "no" to that feature is what makes "nothing to install" an actual claim instead of a slogan.
You also deleted the settings dialog
An install usually comes with somewhere to put configuration: a preferences pane, a project folder, a config file, a field for an API key. Take the install away and all of that goes with it. It sounds like a simplification. It is really a constraint.
Because if there is no configuration surface, then everything the person needs to tell us has to fit in the sentence they type. That is a much harder bar than it looks. Asking someone to describe what they want is a fine interface for a person who already knows; it is a poor one for the far more common case, where they know what the finished thing should look like and have no vocabulary for the steps in between. With a settings pane you hand them a form and let the form do the thinking. Without one, the product has to do the thinking — and it has to be willing to ask, briefly, once or twice, inside the same conversation rather than in a wizard nobody finishes.
So we ended up with an internal rule that is more useful than it sounds: any feature that can only be configured by adding a field to a form is a feature we haven't finished. It either fits in the conversation or it doesn't ship yet. This is why the first thing CloudPal gives you is a result rather than a setup screen. Not for the demo's sake — because we ran out of places to hide the configuration.
What we gave up
It would be dishonest to present this as a clean win. Three things got worse, and they're worth naming because a developer reading this will think of them anyway.
Local speed. Work that could have used a fast local machine and an existing local corpus now has to be produced on our machines from what was said in the conversation. That is a real ceiling.
Offline. No install, no local runtime, no work on a plane with no wifi. The connection is the product.
Private context. If your material lives somewhere you can't paste, this is the wrong tool for that job today. We'd rather say that than imply otherwise and disappoint someone at the end of a deadline.
Those are the costs. What you buy for them is that the thing works on the machine you happen to be in front of, and that leaving is free — close the tab and there is nothing of ours left on that computer, because there was never anything there.
A test that takes five minutes
This is easy to check, which is why I like it. Use a computer that isn't yours, or a browser profile you don't care about. Open CloudPal, sign in, ask for something real, and then close the window before it's finished. Come back later on a different machine and see whether the thing you asked for is where you left it and says what actually happened.
If that works, you've learned something more useful than any feature list: the work wasn't happening in the window, and the result doesn't belong to the computer.
What we do about it
CloudPal runs long tasks on our machines, on a schedule if you want one, and hands back a finished document — nothing to install, nothing asked of your computer, nothing read from files you already have. You say what you want and when you want it, in a sentence, and the output is a document you can forward rather than an answer you have to reassemble.
It's in limited preview. New accounts get a dollar of credit, which is enough to run something real, and the number of new accounts per day is capped.
If you want to judge it as an engineer, the question I'd put to it isn't whether it's clever. It's this: close the tab mid-run, then go find out whether it can tell you what it did while you weren't looking. An agent that only exists while you're watching is a chat window with extra steps.
CloudPal.TuringCorp.net — create an Agent Pass, sign in, and say what you want done.
Earlier in this series: what breaks when an agent has to keep an appointment.
Top comments (0)