Generic in, generic out
Why outputs feel generic
Two assistants from competing providers, asked the same question, will produce strikingly similar work. The reason is not laziness; it is that they were trained on roughly the same public material and given roughly the same instructions. Without specific input, they default to the average of what they have seen. Most of the dissatisfaction described as the assistant being unhelpful is, on closer inspection, a complaint about averages. The remedy is not louder prompting. It is supplying the four kinds of input that move the work off the average.
The four layers of owned context
Four kinds of input do most of the work of de-averaging. The first is dialogue you took part in — recorded meetings, call notes, longer threads — because the best thinking tends to happen in conversation and is otherwise discarded. The second is the thinking you have absorbed from others — annotated books, white papers, internal frameworks — which gives the assistant a vocabulary closer to yours. The third is your own past output — documents, code, deliverables — because it shows the assistant what your good actually looks like. The fourth is your corrections, saved so they accumulate rather than evaporating after each session.
Where the four layers live, in practice
These layers need somewhere durable to live. A workspace that the assistant can read every time is the minimum. The two viable patterns are a hosted project — a named container inside a chat interface, with files and a brief — and a local folder on your own machine that the assistant can read directly. The first is easier to start and harder to extend; the second is harder to start and compounds further. Most working setups end up at the second eventually because the assistant's effectiveness rises with what it can see, and what it can see is bounded by what you can keep in one place.
An honest counter — when renting is correct
The owning-over-renting framing has limits worth being clear about. Renting is the right move at the frontier model layer, where capability improves faster than any one user can maintain a private alternative. Renting is also correct for occasional, low-stakes tasks where the cost of constructing a workspace exceeds the benefit. The right rule is layered rather than absolute: own what compounds — notes, prompts, skills, corpora, corrections — and rent what changes too quickly to keep up with. A productivity stack is mature when each layer is on the appropriate plan.
Open a fresh assistant session and ask it to draft a short note in your style. Without any prior context, does it sound like you? If not, what would you need to give it before it could?