The account we published this week opens with a roommate walking past the desk, looking at the tabs, and asking: "Still reading?" The answer was yes. The truth was that not a single line of the paper had been written that afternoon.
What had been written was a request. One sentence, typed into a box: give me a literature review on this topic, about this long. That is the entire input. Everything interesting about building a product for that request happens in the gap between a sentence and a document, and the gap is much wider than it looks from the outside.
This is a write-up of three things we had to get right because of that gap: what we read before we write anything, the one question worth asking, and why the second read of the result has to be the same document as the first.
A sentence is an intent, not a spec
Engineers like to receive requirements. A sentence from a person is not a requirement, and treating it as one is how you produce something technically compliant and useless.
"Literature review on X, around 8 pages" contains a topic and a length. It does not contain the thing that decides whether the output is worth anything: which direction to lean. A methods-first review and a state-of-practice review on the same topic share maybe a third of their content, and the person asking usually knows which one they need, in the way you know which key fits a lock without being able to describe the lock.
So the request is a direction, not a scope. That distinction is the whole design. If you take the sentence as a scope, you will guess the direction, and you will be wrong about a third of the time. If you take it as a direction, the question "which way should this lean?" is answerable in ten seconds by the person who typed it, and unanswerable by us.
There is a temptation to solve this by making the box bigger. Fields for topic, audience, length, citation style, tone. That works for the subset of users who already know how to decompose their own request, which is a minority of the people who need a document produced. For everyone else it converts a one-second thought into a form they abandon.
The rule we ended up with is narrower than it sounds: the only thing we may ask is something the person can answer in a sentence. Not a taxonomy. Not a dropdown. Two options and a reason to pick one.
We search before we write, and that ordering is not cosmetic
The instinct is to start generating immediately, because generating is the part that looks like work. We don't. The first thing that happens after a request is a search of public material on the topic.
Two reasons, one of them obvious and one of them not.
The obvious one is grounding. A review that was written from memory is a summary of what a model absorbed at some point in the past, presented with the confidence of something checked. For a document the reader is going to hand in, that difference matters: the citations have to exist, and the state of a field has to be the state of the field.
The less obvious one is that search is how the system finds out how little it knows about the request. A topic that looks clean in one sentence usually splits into sub-areas with their own vocabulary. You discover that by reading, not by planning. The reading is what makes the clarifying question a real question instead of a generic "can you tell me more?".
That ordering has a cost, which is honesty time: the user waits. The waiting is visible, and there is a strong pull to hide it behind a fake progress indicator that means nothing. We ended up preferring a truthful account of the stage the run is in over an animated bar, because a person who knows the run is reading can decide to go do something else, and a person watching a bar cannot.
One question, before the work, inside the conversation
The question we ask is a fork, not a clarification request. "Which way do you want this to lean - the research methods side, or where things stand in practice?" Two options, both concrete, both derived from what the search just found. The person picks one in a few seconds, and a surprising number of them say something like "the second one, and actually my question was too broad" - which is the most useful thing that can happen in the whole interaction.
That is the moment the product is doing its job: not writing, but narrowing. The person arrived with a request that was too wide to answer well and left with one that is narrow enough to answer.
We ask once. Not because a second question would be harmful, but because the second question is usually the first question wearing a different hat, and every additional turn is a place where the person closes the tab. One question early, while they are still engaged, beats three questions spread across a conversation they've lost interest in.
The cost of getting this wrong is asymmetric. Ask nothing and you produce a confident document aimed in the wrong direction; the person reads two pages, realizes it, and has to start over. Ask once and you occasionally ask something they find obvious - which they forgive in one line.
The second read has to be the same document
Here is a requirement that surprises people who haven't shipped a document product: the artifact has to be stable. If the person reads it at 23:40 and opens it again at 08:10, they must get the same bytes. Not a regenerated version. Not "an improved copy". The same thing, with the same structure, unchanged.
This is harder than it sounds once the generator is non-deterministic, which it is. The lazy implementation regenerates on every fetch, and then every read is a new roll of the dice: the section order drifts, a paragraph that was there is gone, the citation list shortens by one. A person who is about to hand this in reads that as the tool being unreliable, and they are right.
So the run has to end in a fixed artifact that later reads point at, not re-derive. Which drags in the boring parts: an identity for the artifact that isn't a file path, a record of which version is current, and a rule that a re-read never silently produces a different document. When something does change it has to be a new version, visibly a new version, not an edit in place that the reader can't see.
The same logic applies to the name. The user typed the topic offhand; the file name they get back is tidied into something normal, because the file is going to sit in a folder next to other files, possibly for a long time, and the name is the only part of it they'll see at a glance. Naming is not decoration. It is the interface to a document you find three weeks later.
Reading a lot is not the same as having something to use
The failure mode this product exists for is not a shortage of material. It is material that never becomes a judgment: dozens of tabs, notes that are mostly excerpts, a rule like "eight papers today" that produces eight papers and no opinion.
Volume is the easy part to automate, and automating it makes the problem worse, not better. If you hand someone forty summaries, you have moved the sorting problem from their browser to their inbox. What actually helps is a document with a spine: where the field stands now, the main directions it splits into, what's still open, and where each claim came from. A shape that lets a reader point at a section and say "this one is my argument."
That is why the output is a document and not a chat answer. A chat answer scrolls away; a document has an address, a structure you can navigate, and an existence independent of the conversation that made it. The person in the story read it twice, changed the wording in three places, and filed it. That's what a finished artifact looks like: something you edit, not something you re-prompt.
What this doesn't do
Worth being explicit, because the story makes it look more magical than it is.
It does not read your files. It never asks for a folder, and this isn't a temporary limitation on a roadmap - it's the same design boundary as having nothing to install. What goes in is what you said, plus what's publicly readable. If your material lives somewhere you can't paste, this is the wrong tool for that job today.
It does not do the reading that makes you able to defend the argument. It can tell you where the field stands and hand you something structured to work from. It cannot give you the judgment that comes from having followed an argument yourself, and a person who hands in a document they haven't read is going to have a bad conversation with their supervisor.
It is not always right. A review built on public material can miss the paper that everyone in the subfield knows about, and it can be confident about a claim that's contested. The sources are listed so this is checkable, which is the only honest way to ship something like this.
A five-minute test
Ask for something real, and make the request as vague as your actual thought is - one sentence, no pre-decomposition. Then watch the first minute. Does it start writing immediately, or does it go read something first? Does it come back with a fork you can answer in a sentence, or with a form?
Then close the tab, wait until tomorrow, and open the result again. Same structure? Same sections in the same order? Same sources? If the document you read last night is the document you read this morning, the run ended in an artifact rather than in a conversation. That's the property worth testing, and it's the one most tools in this category fail.
Where it sits
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 in a sentence; it reads, asks the one question that matters, and produces something you can edit and file.
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, I'd skip the feature list and test the two properties above: it should ask before it writes, and the document should not change under you between two reads. An agent that re-rolls its own output every time you look at it is a demo, not a tool.
CloudPal.TuringCorp.net - create an Agent Pass, sign in, and say what you want done.
Earlier in this series: we deleted the install step and found out it was holding the whole design together and what breaks when an agent has to keep an appointment.
Top comments (0)