Can a useful answer become a dependable outcome? LifeVal invites a closer look at everyday AI assistance.
Imagine a parent asking an AI assistant to help register a child for school. The request sounds simple until the details arrive: check the right district, find the deadline, identify the documents, make sure the address is correct, and work out whether a form should be submitted now or reviewed first.
A good answer would be useful. A reliable process that gets the family to the right outcome would be more useful still. The distance between those two things is where OpenAI’s LifeVal becomes interesting.
OpenAI announced LifeVal, an everyday-task evaluation, on November 2, 2026. It draws on time-use research and what OpenAI calls a demographically representative survey of 3,995 respondents. OpenAI says it used LifeVal internally over the past year. The tasks cover caregiving, household administration and government services. It does not introduce a separate consumer feature.
The idea is straightforward and useful: evaluate AI against the work people actually want help with. The harder question is how much a displayed score tells us about completing that work consistently, with the right permissions and a result the person can rely on.
Start with how people spend their time
AI evaluations often focus on problems that are easy to package: a question with an answer, a coding challenge with tests, or a document to summarize. Everyday administration has a messier shape. A task can begin with a search, move to a form, pause for a family decision, and end days later when someone confirms that the form was accepted.
Time-use research provides one way to find activities worth examining. The American Time Use Survey measures how people in the United States spend their time and participate in activities. The Multinational Time Use Study harmonizes diaries from surveys across countries; it includes ATUS data, so their totals should not be treated as entirely separate pools.
These sources help identify the shape of daily life. They do not, by themselves, establish which activities people want an AI system to do, whether a task can be delegated safely, or whether assistance makes someone better off. Those are separate questions.
Consider an hour spent preparing dinner. One person might welcome a grocery list and recipe adjustments but enjoy cooking. Another might want help accommodating allergies, comparing costs, and placing an order. A third might have limited internet access and need a printable plan. The activity is the same broad category; the useful assistance and acceptable level of autonomy differ.
Time saved also misses urgency. A five-minute deadline check can matter more than an hour spent on an enjoyable activity. And some care work has value in the relationship itself. A benchmark grounded in everyday activities is a good starting point; translating that starting point into useful evaluation requires decisions about whose needs count, what the assistant is allowed to do, and what a good outcome looks like.
How to read a task score
Selected OpenAI results, labelled best recorded GPT-6 Astra scores:
| Task, abbreviated | Displayed score |
|---|---|
| Toddler sensory-class booking | 100% |
| Pre-trip vehicle inspection booking | 100% |
| Budgeted halal grocery order and spreadsheet | 100% |
OpenAI’s page leaves the scoring denominator, run count and best-result selection unclear.
A strong example is worth looking at. But a percentage needs a denominator and a scoring rule before a reader can interpret it precisely. It might reflect completed trials, satisfied grading criteria, or another measure. A selected example is not an overall benchmark result.
An attainable peak does not tell us what a typical attempt achieves. Nor does it establish how the system would perform on a different class, a different repair shop, or a grocery site with a missing item. We should not fill those gaps with a made-up average or assume a particular number of retries.
For a person deciding whether to delegate, several results would be useful together: the share of attempts that finish correctly, the range across runs, how often a person must intervene, and the kinds of errors that remain. A test could also report partial progress. That can show where a system improved while keeping the final outcome visible.
A simple illustration shows why the distinction matters. Suppose, purely hypothetically, that a workflow has ten steps, each succeeds independently 95% of the time, and every step must succeed. The chance of all ten succeeding is about 60%: 0.95 raised to the tenth power. This is not a LifeVal result. Real errors can be correlated, and an assistant may detect and recover from them. The example simply shows why a series of individually reliable actions needs a separate end-to-end measurement.
What counts as finishing the job?
Our hypothetical school registration makes the issue concrete. “Help me register” can describe several different endpoints. The following are our proposed distinctions, not categories OpenAI has disclosed for LifeVal.
| Stage | Example | Evidence worth checking |
|---|---|---|
| Advice | Explain the registration requirements | Current rules for the correct district |
| Preparation | Make a document and deadline checklist | Required items and dates match official guidance |
| Ready for review | Fill in a draft and assemble attachments | The child’s details and catchment are correct |
| Authorized submission | Submit after the parent approves | Submitted values and confirmation receipt |
| Follow-through | Respond to a request for missing records | Application status and next steps |
Not every task should end in a submission. A parent might prefer a checklist and want to enter personal details themselves. A capable assistant should be able to stop at the requested point, explain what remains, and ask for a decision when it lacks information.
The distinction also helps explain partial scores. Finding the correct school, locating the deadline, and assembling documents are valuable progress. They are not the same outcome as submitting the right application. Conversely, an assistant that correctly stops because two schools require a parent’s choice may have handled the task well even though no form was filed.
This emphasis on observable outcomes has a history in agent research. WebArena introduced self-hostable websites for evaluating whether agents complete functional web tasks. More recently, the OSWorld 2.0 paper describes longer workflows scored against fine-grained final-state checkpoints, with partial scores and binary completion reported separately. These are different evaluations, so their scores should not be compared directly with LifeVal’s examples. Their relevance is methodological: a reader can learn something different from a record of progress than from a final yes-or-no result.
Even a detailed progress score needs context. Nine correct steps followed by a payment to the wrong recipient is not a nearly satisfactory payment. The importance of an error depends on its consequences, whether it can be reversed, and whether the user notices in time. A useful report would show both progress and consequential mistakes.
The assistant is more than the model
An everyday task runs through an environment. A portal may change its layout, a login can expire, inventory can disappear, or a site may require a verification step. A connector might make a task much more dependable by giving an assistant a structured way to access information; a missing permission might make completion impossible.
That means a result belongs to a whole setup: the model, instructions, available tools, account state, task environment, time allowed, and permitted human help. A model name alone cannot tell the entire story.
This is also why an evaluation should say what kind of help a person gave. There is nothing inherently wrong with an assistant asking a parent to choose a school or confirm an address. It may be exactly the right action. But a reader needs to know whether a reported outcome required one quick approval, repeated troubleshooting, or a person taking over half the task.
The same applies to failures outside the assistant’s direct control. If a booking site is unavailable or a user’s credentials have expired, the system may be unable to finish despite sensible behavior. A useful report can show these operational blockers separately, while still counting the effect they have on the person trying to get something done.
Boundaries are part of useful work
Successful delegation depends on what the assistant does along the way. If a grocery item is unavailable, for example, an assistant should not assume that any substitute is acceptable. It could show options, flag the change in price, and ask the user to choose. If delivery pushes the total beyond the stated budget, stopping and explaining the problem can be the right outcome.
Similarly, someone seeking public benefits might want help finding official forms, organizing supporting documents, and tracking a deadline. Preparing a submission is different from deciding that the person qualifies or asserting facts the assistant cannot verify. The person needs to see the information that will be submitted and retain the decisions that belong to them.
These are criteria we would want to see tested; they are not claims about a particular LifeVal grading rule. Good evaluation would make the authorized objective and constraints explicit, then examine whether the assistant respected both. Depending on the task, that could include the budget, who can see personal data, when approval is required, and which actions must never happen without it.
The security side matters too. OpenAI’s historical ChatGPT agent system card discusses prompt injection: instructions encountered in outside material may try to redirect an agent or cause information to be disclosed. That document concerns a different, earlier system and does not establish LifeVal’s setup. It does illustrate why a test of useful action should consider the material an assistant encounters and the authority it gives that material.
Did the assistant actually reduce the work?
A completed task can still leave a person worse off if it took longer to supervise than to do themselves, generated an error that required cleanup, or exposed information unnecessarily. We would measure net help as a practical complement to task scores.
Start with the time a comparable task would normally take. Then account for the time spent explaining it to the assistant, checking its work, answering questions, correcting errors, and handling anything left unfinished. That calculation is a proposed way to think about value, not a LifeVal statistic.
Time is only one part of the result. A useful field study would also examine the quality of the outcome, financial costs, accessibility, privacy, and any harm caused by errors. It should compare like with like: a carefully checked human submission against an assistant-supported submission checked to a similar standard, for example. The comparison should also recognize that some people may value reduced cognitive load or improved access even when the clock savings are modest.
Follow-through deserves attention. A booking confirmation may be followed by a cancellation; an application may trigger a request for another document; an order may arrive with substitutions. A system that announces success at the first receipt could leave the person with unresolved work. Depending on the user’s wishes and permissions, a useful assistant might record the confirmation, surface later changes, and make clear when its responsibility ends.
What better reporting could tell us
LifeVal points toward a valuable class of evaluation. To interpret future results, we would like to see enough detail for readers and researchers to answer a few practical questions:
- What was tested? The number and variety of tasks, the populations and settings represented, and whether examples reflect the full range of difficulty.
- What did success require? The endpoint, grading rules, partial credit, and treatment of consequential errors.
- How repeatable was it? Results across attempts, including ordinary performance and difficult cases, with the meaning of any best-recorded result explained.
- What could the system use? Tools, credentials, environment, time limits, retries, and human intervention.
- How were boundaries assessed? Permission, privacy, spending limits, unsafe shortcuts, and the treatment of a justified stop or request for clarification.
- Did it generalize? Results on held-out tasks and, where feasible, independent replication rather than evaluation only on familiar examples.
- Did people benefit? Quality, net time, accessibility, costs, follow-up, and adverse outcomes in realistic use.
There are genuine design tradeoffs here. A stable, controlled website makes it easier to repeat a test; a live site introduces changing stock, outages, and other friction people actually encounter. Both can be useful when their results are reported separately. Publishing representative tasks, grading guidance, and environment details can improve scrutiny while protecting personal information and sensitive systems.
The survey behind task selection also deserves context. Sample size is useful information, but recruitment, geography, question wording, accessibility, and weighting help explain whose preferences the sample represents. Even a representative survey of people does not automatically produce a benchmark that represents every household’s needs.
A better brief for an everyday assistant
You do not need access to LifeVal to apply the underlying lesson. When using an assistant that has the appropriate capabilities, give it a clear objective and define the boundary around it. For example:
Help me prepare for school registration in my district. Find the official requirements and deadline, make a checklist, and identify anything you cannot confirm. Do not submit a form or share my child’s documents. Show me the sources and the next decision I need to make.
For a shopping task, add a maximum total including delivery, acceptable substitutions, and whether an order may be placed or only prepared. For an appointment, specify location, dates, accessibility needs, and the point at which you want to approve a booking. Ask for a receipt or a link to the relevant official page when that evidence exists.
Those instructions will not guarantee a correct result. They make the intended result and the stopping point easier to check. They also give the assistant room to do useful preparatory work without guessing at a decision the user has not made.
LifeVal’s most compelling direction is the move toward evaluating that kind of practical help. The next useful evidence would show performance across varied tasks, the attention required, and whether the person ends with the outcome they actually wanted.
Reporting note: This article is based on published sources checked November 2, 2026. Kingy.ai did not run LifeVal or independently reproduce its results.
Featured image: OpenAI’s LifeVal announcement artwork. Image: OpenAI.
The Kingy Brief
Get the free AI price sheet.
26 AI plans and models on one page, from official pricing pages, updated every month. Free when you join The Kingy Brief: AI changes, original tests and one practical thing to try, Fridays at 09:00 Vancouver time.
Free · Double opt-in · Unsubscribe anytime
Sign up for The Kingy Brief on Beehiiv.
Signup help and newsletter schedule
Signup form provided by Beehiiv. After submitting, check your inbox for "Confirm your subscription to The Kingy Brief" and open its confirmation link. Your price sheet download is on the page that opens. Check Spam or Promotions if you cannot find it.
Fridays at 09:00 Vancouver time: source-checked AI changes, original tests and one practical thing to try. We skip a week when there is not enough verified material. Free. Unsubscribe anytime.