An Assistant Should Be Easy to Leave
I use closed models all the time. They are useful enough that pretending otherwise would be silly. They help with work, business, family life, and the small pile of things that would otherwise stay open in my head for too long.
The assistant I actually want might run on my own network. It might run in a managed service. The important part is that it remains mine in the ways that matter.
I want to decide what it remembers, what it can touch, where its logs live, and when it is allowed to call something outside my house or business. If I use a hosted assistant, I should be able to export its data and history in a usable form, move to another provider, or run it myself later. A service needs a reasonable data-retention and decay policy. It does not need to become the permanent landlord of the system that increasingly understands me.
That changes the question for me. Hosting can be a real service. Plenty of people should not have to operate servers just to use an assistant they trust. The problem starts when convenience quietly becomes captivity: when a pricing change, an account decision, a policy update, or the disappearance of a product can sever someone from the thing that knows their calendar, their work, their preferences, and the small decisions they have handed off to it.
I do not think broad models are a mistake. A general model is often the right place to begin. It is useful for unfamiliar work, broad exploration, translation, drafting, and plenty of things where a person can cheaply look over its shoulder. I use both open and closed models every day. This is not a purity test, and it is not an argument that every task needs a custom model.
Still, I keep seeing one product pattern treated as the destination: a larger general model, controlled by a provider, accessed on the provider's terms. In many closed-model arrangements, the provider controls the weights, the price, the evaluation, the safety narrative, and the conditions of access. That is a convenient way to deliver a powerful tool. It also makes the provider the place every important question eventually has to go.
A model can speak fluently about code, medicine, contracts, and finance. That does not settle whether I should let it make decisions inside any of those systems. Once work has real consequences, I care less about a broad benchmark score and more about mundane questions: What information did it use? What is it allowed to do? How is this particular job tested? What happens when it is unsure? Who has the final say? NIST's AI risk framework treats trustworthiness as something that depends on the system and its context of use, not a score a model gets to wear on its chest.[1]
There is also an epistemic problem that gets waved away too easily. When a vendor is the primary source for the model, the evaluation, the danger story, and the claims about AGI or catastrophic capability, outsiders have limited ways to check the work. Closed weights cannot be inspected by the public. Proprietary evaluations may not be reproducible outside the company that ran them. A claim can be made in good faith and still be impossible for the public to meaningfully test.
I am not saying every frontier lab is lying. I am saying "trust us, this is powerful and dangerous" cannot be the lasting governance model for technology that may end up acting inside people's businesses, homes, schools, and governments.
The alternative I want is not a hobbyist project where every person spends their weekends maintaining a fragile pile of local models. It is a market where hosted services compete on reliability, convenience, and support without making the exit door disappear.
Imagine the assistant I described at the beginning. Its calendar access has a narrow permission. Its financial-review work has a defined source of truth and an exception path that reaches a person. Its research work keeps the evidence it used, so I can inspect why it answered the way it did. If one component stops working for me, I can replace it without giving up the rest of the system. A broad model might still power some of it. A smaller or more constrained component might power another part. The point is that the boundaries are visible, and the user is not trapped behind them.
Sometimes that boundary will be a tuned model. Sometimes it will be a general model inside a constrained interface. Sometimes a general model will be cheaper, simpler, and good enough. There is no prize for multiplying agents when one well-supervised tool will do. But when separate work really does need separate access, evidence, and escalation, I want those things to survive the handoff instead of disappearing into one long conversation.
There is a small version of this in how we run work at Nacho Labs. Research, drafting, editorial review, verification, and coordination are separate jobs with shared artifacts and explicit handoffs. When a claim is wrong, we can trace the source that entered the draft, see what a reviewer challenged, and identify who can advance or stop the work. That does not prove a multi-agent workflow beats one agent. It does make the work easier to inspect when it fails.
TypeSafe's Jev caught my attention for the same reason. The company is proposing a narrow, typed decision interface for software work rather than another general free-form text generator.[2] I do not know whether its performance claims will survive independent use. A company launch is not an audit, and type safety can prevent schema errors without making a decision correct. Still, the choice to give up some flexibility in exchange for a bounded interface feels like a direction worth taking seriously.
I do not think intelligence becomes more legitimate just because it becomes broader. A system can be impressive and still be the wrong shape for a role where the data boundary, tool permission, evaluation, and failure consequence need to be visible.
Open weights can create more room for decentralization, but they do not create good evaluation, safe permissions, human judgment, or public accountability on their own. They can be misused, poorly maintained, or leave power concentrated elsewhere. They can also give people, communities, institutions, and smaller companies a way to run, inspect, adapt, and govern systems without relying on the original provider for every use.
I do not want closed models to disappear. I want hosted assistants to earn trust by being useful, clear about what they retain, and easy to leave when they stop serving the person who trusted them.
The assistant I want should help me, but it should also answer to me. If it makes a recommendation I disagree with, I want to know which part of the system made it, what it saw, and what I can change. Whether I run it myself or pay someone else to operate it, I should not have to give up my data or my continuity just to get help.
Sources
[1] NIST, *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*
[2] TypeSafe AI, *Introducing System One Models & Jev* (company-authored launch)