Downloading invoices is an odd way to spend an evening. You sign into a supplier’s portal, find the right month and save a PDF, then repeat the process somewhere else. There is work that benefits from our full attention. I struggle to put this in that category.
This is one of the reasons I am interested in AI beyond writing software. An assistant that helps with the accumulated administration of everyday life has an appeal that a benchmark score cannot explain. Some of the benefits are quite modest individually. Together, they could give us time for things we actually want to do.
There are costs, of course. This series has spent plenty of time on the engineering needed to work with agents. Here I want to look at the everyday bargain: where the help is useful, where we end up paying for it twice, and what might change without us noticing.
Choosing what deserves our attention
Summarisation is one of the uses of AI I find most convincing. We have long joked about a new JavaScript framework appearing before we have learned the previous one. AI news seems determined to make that joke obsolete through sheer volume.
Keeping up with a technical field involves a lot of reading that ends with the discovery that we did not need to read the thing. We might follow several links about a release only to find that they repeat the same announcement. Meanwhile, the compatibility note that actually affects our project is buried in the original documentation. Finding it takes time we could have spent understanding the change.
An agent can help sort this material before it reaches us. Give it the actual sources and some context about our work, and it can group related coverage, explain why an item might matter and keep the original links. Something relevant to a current project goes into a short digest. Useful background can go into a personal wiki, with its source and date, ready to be found when the subject becomes relevant.
That wiki needs some restraint. Saving every summary produces a larger reading backlog with better formatting. I would keep material because it answers a question or connects to work I care about, and keep the author’s claims separate from the agent’s interpretation. A remembered summary of a summary is a poor foundation for a technical decision.
We should also be careful about declaring hallucinations solved. Vectara’s summarisation benchmark still reports factual inconsistencies across current models, including when they receive the source document. Its rates depend on a particular dataset and automated evaluator; they are not a universal probability that our next summary will be wrong. They do give us a reason to retain the source and check consequential details.
The same filtering is useful outside work. Email and event notifications arrive through different applications, each convinced that it deserves an interruption. An assistant with rules about what matters could collect the routine material for later and surface a message that needs a timely response. Hermes documents a daily briefing workflow combining scheduled research, summaries and delivery to a messaging app. That provides the machinery; deciding what earns a place in the briefing is still our job.
There is a small pleasure in receiving the relevant information without fighting through advertising, notification prompts and recommendations designed to keep us on a website. But I would want to inspect what the filter left out occasionally. Otherwise, a mistaken idea of my interests could quietly become the limit of what I see.
Getting the chores out of the way
The current crop of personal agents makes this more practical. OpenClaw’s community showcase includes collecting accounting PDFs from email and organising grocery shopping, alongside integrations with Home Assistant. These are community examples, with their own setup and limitations, rather than evidence that every installation can immediately run a household.
Consider preparing a shopping list from a meal plan and checking it against what is already in the kitchen. Given that information, the agent can combine the quantities and remove what we already have. We review the result before ordering, with the preparation already done. A draft reply to a routine request offers much the same convenience: we have something to check and adjust, instead of having to assemble it while other things wait.
None of this requires us to turn our lives into a productivity competition. I don’t need to optimise dinner so I can fit in another meeting. The attraction is having fewer chores competing with an evening off. A modest saving is worth having even if it never appears in a business case.
There are benefits which matter for reasons beyond time, too. Be My AI provides image-based assistance for blind and low-vision people, letting users ask questions about what they have photographed. The service also retains access to human volunteers. Being able to get an explanation of something otherwise inaccessible is a substantial benefit, even when the task looks ordinary to someone who can already do it unaided.
Someone still has to maintain the setup. Accounts need connecting, integrations change, and the results need checking. If gathering this month’s invoices requires another evening repairing the assistant, we should include that evening in the cost.
Making room for more important work
Parallel agents offer another useful change. In software, a small documentation correction can progress while we work through a difficult design decision. We return to a proposed change and its checks, review it, and move on.
Research can work similarly. Independent questions can be investigated at the same time, with their sources ready when we need to compare the answers. Anthropic’s account of its multi-agent research system reports improvements on its internal evaluations using parallel investigation, at the cost of substantial additional token consumption. The authors also describe why work with tightly coupled dependencies is a poor fit.
I find this a more useful ambition than writing ten times as much code. Much of the small work still needs doing, but it does not all need to occupy the part of the day when we are best able to concentrate. An agent can prepare it while we spend that time elsewhere.
The arrangement stops helping when every worker needs frequent intervention. If a documentation change depends on the design decision I am still making, starting it early may just create rework. And if several agents all finish together, their outputs become a queue for me. A sensible limit on concurrent work, and a defined point at which to review it, matter more than the number of sessions I can open.
Unfortunately, getting an impressive first result tells us little about what it will cost to keep using it.
Paying for the same work twice
Consider an agent building a small application. The initial version works. We ask for an additional filter, and now the export is broken. The repair restores the export but changes how dates are interpreted. Each request is reasonable in isolation; the sequence leaves us spending an afternoon recovering behaviour we already had.
People describe this as getting ninety per cent of the way there. A working demonstration tells us very little about the work remaining once requirements start interacting. This is especially difficult for someone without the technical experience to identify the underlying problem. They can describe what broke, but may have no way to judge whether the proposed fix makes the system less fragile.
There is a related failure across sessions. Anthropic’s work on long-running agent harnesses describes agents leaving incomplete, poorly documented changes for later sessions to reconstruct. It also describes features marked complete without adequate testing. An agent coming back to repair the application can spend time establishing facts that a previous session already knew.
The harness, meaning the tools and controls around the model, can reduce this waste. Working behaviour needs checks that survive the next request. A change should have a recoverable starting point, and the agent needs to know what must remain true while it makes the modification. Where browser behaviour matters, passing a few unit tests is insufficient evidence.
These controls reduce the chance of a regression, but they cannot eliminate it. Tests can miss a requirement. The requirement itself may be ambiguous. When the same area keeps breaking, I would stop asking for another patch and examine the design and the checks around it.
The cost includes more than the tokens consumed by the repairs. Someone has to notice the regression, explain it and inspect the next attempt. That person may be the user, or a colleague who now has to understand an unfamiliar pile of generated code. The first result is only part of the bill.
An agent can be busy and stuck
Rework is visible when something breaks. A loop can be harder to notice because the agent continues producing signs of activity. It runs a test, edits a file, runs the test again, then reverses part of the edit. Or it keeps searching with slightly different wording after it has already found enough information to answer the question.
In Anthropic’s experiment building a C compiler with parallel agents, Nicholas Carlini describes agents spending hours running tests without making progress unless the harness helped them account for time. The example concerns a particular model and experimental setup, but the operational problem is easy to recognise: continued execution does not establish continued progress.
Unattended operation needs a stopping rule. I would set a budget for the task and require a pause when repeated attempts fail to produce new evidence. The surrounding software should enforce the limit, rather than relying on the model to remember it. A useful progress report says what changed and what remains blocked. Another announcement that the agent is investigating is of little help.
If a task takes unexpectedly long, interrupting it is reasonable. Ask for the current state, what it has tried, and what would be different about another attempt. We can then decide whether to narrow the task, provide missing information or stop it altogether.
Optimising a step inside the wrong workflow
Interrupting an agent also gives us a chance to reconsider the task itself. If we keep asking it to do something that ordinary software could handle more cheaply, getting it unstuck only fixes part of the problem.
Take the daily technology digest. We could ask an agent to visit the same websites each morning, look through their pages and decide what is new. It may do a good job. But if those sites provide RSS feeds, an ordinary application can retrieve new entries, remove duplicates and store the content before a model sees any of it.
The model then has a smaller, more appropriate job: assess relevance and summarise the selected material. A feed reader does not need a language model to discover that an item has already been processed. It still has operating and maintenance costs, but it does not consume model tokens for each routine fetch.
This division is supported by the tools themselves. Hermes’s scheduler documentation describes checks that run before a scheduled agent and can skip the model call when nothing has changed. That is a useful design choice for a recurring job.
The distinction matters more as the workload grows. Repeated browsing includes page navigation and retries, often followed by resending content the system has seen before. A small inefficiency that looked harmless in a test run becomes part of every execution. A stable parser or API integration may justify its setup cost quickly; for an unfamiliar site used once, letting an agent browse may be cheaper overall.
There is a broader version of the same mistake. Suppose an agent copies data between two spreadsheets because that is how the process has always worked. We have made the copying faster, but perhaps the second spreadsheet exists only because an old integration was missing. Removing the duplicate record could save more work than improving the copy.
It takes domain knowledge to see that possibility. Someone unfamiliar with the process may not know which steps are necessary, and an agent following a narrow request has little reason to challenge the whole arrangement. I would review the path from the original need to the final result before investing heavily in automating a middle step.
An agent can also help write the ordinary software that removes its own recurring job. That seems a perfectly good outcome to me.
Keeping the ability to judge the result
Recognising that a workflow has unnecessary steps takes knowledge of the work itself. I don’t expect to gain much of that by copying the same data between spreadsheets, but working through a problem with an unfamiliar library is a different matter. The effort we delegate may include practice we still need.
Anthropic’s study of AI assistance and coding skills tested 52 developers learning an unfamiliar Python library. The AI-assisted group did worse on a subsequent comprehension quiz, while its average speed improvement was not statistically significant. Within that group, asking conceptual questions was associated with better understanding than delegating the work outright. The study measured immediate learning on a particular task; it does not establish that AI inevitably causes long-term skill loss.
It does give us a reason to distinguish finishing from learning. If I need to understand a library well enough to maintain a system, the time spent diagnosing an error may be useful. Asking the agent to remove every obstacle could deprive me of practice I will need when its answer is wrong.
A digest can help me decide which paper to read, just as a book summary can help me choose a book or recall its argument. But if I want to learn the subject, the examples and the time spent working through them are part of the value. I would work through those examples myself, using the assistant to question or explain my reasoning. Reviewing a finished answer is a different exercise from producing one.
That distinction matters whenever our justification for automation is that a human will check the result. We need to preserve the expertise that makes the check meaningful.
Slowly borrowing someone else’s voice
When the work is writing, spotting errors is only part of judging the result. A sentence can be correct and clear without being one I would choose to write. Discussions about AI prose often settle instead on recognisable markers: an em dash, a favourite word, a suspiciously tidy conclusion. People used all of these before chatbots, and removing them from generated text proves very little.
As we read more generated prose, could its patterns start to feel like the natural way to write? We might then reproduce them in a text we composed ourselves. There would be no pasted paragraph to remove, and no single editorial decision at which we gave our voice away.
For non-native English speakers like myself, there is another route. We use writing tools to correct mistakes and make our meaning clearer. That help is valuable. But the boundary between fixing grammar and replacing a way of expressing ourselves is not always obvious. LanguageTool, for example, offers sentence rephrasing, including changes intended to make writing more fluent or formal. The edit can go well beyond correcting an incorrect tense.
A suggested sentence may be smoother, and repeated acceptance may gradually change what we consider good writing. An unusual turn of phrase can disappear without being wrong. Eventually, we may start removing it before a tool even suggests doing so.
There is evidence of people picking up vocabulary from models. In the July 2026 revision of their preprint on AI and spoken language, Hiromu Yakura and colleagues report shifts towards vocabulary favoured by ChatGPT in podcast speech. They also describe an experiment in which participants adopted words from a chatbot in subsequent speech.
Terra Blevins’s preprint on linguistic convergence adds a useful qualification. In the conversations studied, humans adapted to the model’s language at rates broadly comparable to adaptation between people.
These studies don’t establish a lasting change to someone’s writing; Yakura’s experimental follow-up was short. My concern is what happens when our habit of adapting to other people’s language meets repeated exposure to the same few model families.
The difficulty is that voice should be allowed to change. Reading other people has always influenced how we write, and keeping every awkward sentence would be a strange defence of authenticity. What I want is to retain some choice about the direction of that change.
For this blog, that means comparing revisions with older writing, rather than accepting the latest polished draft as the reference. It also means asking whether an edit fixes a real problem or merely makes the sentence more conventional. A style guide helps, but if the same model reviews the text and judges whether it sounds like me, I still need to read the result critically.
Actually keeping the time we save
There is a final trap which can occur even when the tools work well: we use the freed capacity to take on more work.
In Ranganathan and Ye’s eight-month observational study at one company, AI users broadened their workloads and worked longer hours.
For me, that makes the purpose of the automation worth deciding in advance. If I automate the collection of invoices to get an evening back, a working system should let me leave the task alone. Spending the evening adding features to the assistant may be an enjoyable hobby, but I should recognise that I have chosen a different use for the time.
The same applies to information. A digest that helps me choose one worthwhile article has done its job. I don’t need to reward it by doubling the number of feeds until reading the digest becomes another chore.
I remain positive about getting this kind of help, provided we pay attention to what changes with repeated use. And if the benefit is simply an evening with fewer obligations, that is enough.