Most attempts to describe what AI will do for individuals fall into one of two shapes. The first is automation: the machine does the task, and the person is removed from it. The second is assistance: the machine answers questions, and the person carries on much as before, marginally better informed.
Neither describes what we are building, so this essay is an attempt to name the third thing precisely enough that someone can disagree with it.
A working definition
AI-assisted living is the use of governed AI systems to provide continuous, permissioned support across the areas where a person's natural limits constrain what they can accomplish — with the explicit design goal that the person's own capability increases over time.
Three parts of that definition matter.
Governed. The system operates under stated constraints: what it may access, what it may do without asking, what it must escalate. Governance is not a compliance layer added at the end. It is the thing that makes continuous access to someone's life defensible in the first place.
Continuous. Not a session. A relationship that persists across months, accumulating context and, critically, accumulating a record of what actually happened as a result of its own recommendations.
Capability-increasing. The person should end up more able, not more reliant. This is the hardest commitment to keep and the easiest to abandon quietly, because dependency is commercially convenient and produces excellent engagement metrics.
What we want to add
Organisation can help, but consider a decision made without an important constraint in view. A well-arranged task list would not necessarily supply that missing context. We want to investigate the gap between keeping work organised and helping a person judge what to do.
Question-answering alone does not provide the continuity we want. The question for our design is whether approved context, earlier decisions and their outcomes can be carried forward reliably — and whether a person can inspect and correct that context.
Automation treats the problem as the human. Remove the person from the loop and the loop runs faster. For narrow, well-specified, repeatable tasks this is correct. For decisions that involve judgement, values, or incomplete information, it is a category error.
The distinguishing test
Here is the test I find most useful. Ask of any system: if the person stopped using it tomorrow, would they be better or worse at the thing it was helping with than before they started?
That test does not make automation wrong. Some tasks are worth delegating completely. But when a system claims to develop human capability, easier task completion is not enough evidence. We would need to show what the person has learned and can carry into another situation.
That is a demanding standard. It rules out designs that would otherwise be attractive. A system that makes a decision for you produces a smoother experience than one that argues its reasoning and hands the decision back. It is also the one that leaves you where it found you.
What this commits us to
Defining the category this way creates obligations that are inconvenient.
- The system must be able to explain itself, because reasoning you cannot inspect is reasoning you cannot learn from.
- It must state uncertainty, because a person calibrating their reliance needs to know when not to rely.
- It must be willing to disagree with the user, because a system that only agrees is a mirror, not support.
- It must be measurable against capability rather than engagement, and we have to be prepared for the measurement to be unflattering.
We do not yet know whether a system built to these constraints can be commercially viable at scale, or whether capability gains of this kind can be measured cleanly enough to be credible. Those are open questions, and this site labels them as such.
But the category is worth naming even while it is unproven. You cannot argue about whether something works until you have said clearly what it is supposed to do.