The v/h philosophy
A clear purpose.
A useful job.
Less to manage.
The thinking behind a new kind of everyday consumer utility.
A useful purpose
I want to build a new consumer utility: a physical product that uses a local agent to do useful work, while remaining simple to own and use. Its purpose should be clear to someone who has no interest in artificial intelligence. They should understand what it does for them and why they would want it in their life.
The ambition is to create something that deserves a place among the things people depend on every day. That requires more than an impressive demonstration. The product has to serve a recurring need, fit an existing routine, and deliver a result people can trust. The technology inside should make that possible without becoming another thing the owner has to manage.
I keep returning to the standard set by ordinary utilities. Their purpose is understandable, and their controls relate directly to the task. We judge them by whether they do their job. Familiar objects provide a useful standard for the experience I want to create, even when the capability itself is new.
When I say that everyone should have it, I mean that the need should extend well beyond technology enthusiasts or a particular profession. A product can be easy for anyone to operate while remaining useful to very few people. Ease of use and breadth of need are separate requirements, and this product has to satisfy both.
That ambition does not require a device that attempts to do everything. A clearly defined job can be relevant to a very large number of people. The work is to find a need that is common enough, frequent enough, and poorly served enough to justify a new object. Its value should be apparent in an ordinary day, without an explanation of how impressive its internal technology is.
This starts with paying attention to what people already do. People develop workarounds for tasks they repeat, and they may stop noticing the effort those tasks require. I want to understand that effort before deciding what to build. A habit is evidence to investigate, however, and broad demand still has to be demonstrated through observation and use.
The agent under the hood
The agent has a specific role in this philosophy. I envision a local model running inside the device, with software that gives it access to the device's inputs, tools, controls, and mechanisms. This supporting software is often called an agent harness. It allows the model to do something with its decisions, including operating the device within a defined task.
The agent could interpret what is happening, choose an appropriate action, and use the device's tools to carry it out. It could then check the result and adjust when conditions change. That ability should help the product complete work that would otherwise require the user to make repeated decisions or operate a complicated sequence of controls.
This is what I mean by putting the agent under the hood. The product contains an agent that performs useful work, while the owner interacts with the product through an understandable set of actions. Someone should be able to start a task without writing a prompt, choosing a model, or deciding which software tool to invoke. Those decisions belong inside the product where they can be handled reliably.
An agent also has to earn its place. Adding one to an object does not establish that the object is better. The improvement has to appear in the result, the effort required, or the range of ordinary conditions the product can handle. If a simpler mechanism already performs the job well, that job may offer little reason to use an agent. I am looking for a useful capability where the agent makes a substantial difference.
The product search therefore has two requirements at once: a broadly shared need and a meaningful role for the agent. Starting with only the technology encourages features without a clear purpose. Starting with a familiar object without understanding its limitations can produce an unnecessary addition. The new utility has to justify both its existence and its internal design.
A physical device gives this work a defined place in daily life. Its shape and controls can make the next action clear, and its presence can make it available at the moment it is needed. A person can approach it with a particular purpose and leave when that purpose has been fulfilled.
This also lets the experience remain separate from the other demands of a phone. Opening a phone to complete a small task can bring notifications and unrelated choices into that task. A dedicated utility can keep the interaction focused on the result. It earns the space it occupies by making that result easier to obtain.
The result does not have to be a mechanical change to a physical object. A consumer utility may capture or process information and produce a useful digital output. Its physical form still needs to improve the experience. Being able to hold something is only valuable if the device is more convenient to use, easier to understand, or better suited to the task because of it.
What it means to own it
Local operation is central to the kind of ownership I want to offer. The computing required for the promised job should be inside the device. A person should be able to power it on and use it without creating an account, installing a companion app, pairing it with a phone, or maintaining an internet connection. The core function should work without a cloud fallback or an ongoing subscription.
These choices impose practical limits. The computation has to fit the device's price, power use, size, and performance requirements. A useful product has to be designed within those limits. A prototype that depends on an external service for its essential work would leave an important part of this philosophy unproven.
Local operation can also reduce the need to send personal information elsewhere, although protecting that information still requires careful engineering. More broadly, it gives the product a clear relationship with its owner. The customer buys an object with a useful capability, and that capability should remain available as part of owning the object.
I want the company to be able to build a family of products with that same relationship. Someone might buy a second product because the first one was dependable and useful. Each product should earn that decision through its own value. Owning one should not create a requirement to buy the rest or join a software service to keep using it.
Dependability is part of the product's usefulness. A successful demonstration under carefully prepared conditions says little about how an object will behave during an ordinary week. People will use it in different environments and with different levels of attention. The product has to account for normal variation in how people live.
The owner also needs to understand the outcome. The device should make it clear when the task is complete and when something requires attention. If it cannot complete the job, it should explain the problem in terms relevant to the person using it. The customer should not have to diagnose an agent's internal decisions to understand what happened.
Putting the agent under the hood therefore leaves the product responsible for communicating clearly. The internal software can remain unfamiliar to the owner, while the device's purpose, state, and limits remain understandable. Simplicity should make people more confident about what they are using.
A familiar feeling
I want that simplicity to feel warm and familiar. A new device can have readable labels, comfortable materials, and controls whose purpose is apparent. It can be designed to belong among the objects people already live with. Someone should feel comfortable using it without needing to become the technically capable person in their household.
Familiarity can coexist with invention. I am interested in creating a new everyday capability, and I want its operation to be easy to understand. The novelty should appear in what people can now accomplish and how little effort it requires. A complicated interface is not evidence that a product is technologically advanced.
This ambition also creates obligations around cost and access. A product intended for broad use needs an attainable price, manageable upkeep, and an experience that works across different levels of technical confidence. These are questions to resolve through development and testing. Calling something a utility does not establish that people can afford it or will continue using it.
The business should be accountable to the same standard. I would want to know whether people use the product regularly, whether it finishes the job, and whether they trust it without repeatedly checking its work. Continued usefulness is a better measure of this ambition than the amount of time someone spends interacting with the device.
The first product has to earn its place
The first product remains a problem to solve. A clear philosophy can guide that search, but it cannot replace the work of finding a shared need and building something that meets it. A promising idea has to survive ordinary use at a price and level of reliability that make ownership worthwhile.
I want to build something a person understands quickly and comes to depend on through repeated use. The agent inside should make that experience possible. The product should become a familiar part of life because it does a useful job well.
v/h is at the beginning. These are the principles guiding our first product.
Back to v/h