What is up people!
Imagine you’re a freelance designer waiting for a client to approve a website. You keep opening the same email thread because one reply could change tomorrow’s work. Most visits tell you nothing. One eventually matters: the client wants to launch on Thursday instead of next Tuesday.
An AI assistant could help by watching for that change. It could also send you a cheerful summary of every message, every morning, and leave you to work out which one matters. Now you have the original thread and a briefing to check. Congratulations on the extra inbox.
This is the question behind the new wave of always-on assistants: what should they bring to your attention, and what should they leave alone?
OpenAI introduced dots last week, personal AI agents with their own cloud computers that can work between conversations. The interesting part is the possibility of useful work starting before you remember to ask. That also means choosing when an assistant gets to interrupt you.
📌 TL;DR
An assistant needs to know which changes would affect your next decision. “Keep me updated” leaves that judgment almost completely open.
A useful alert brings the source, the consequence and something prepared for your review. A summary alone may leave the hard part untouched.
Silence only helps when you can verify that the checking worked. Review missed events as well as unnecessary alerts.
Start with one low-stakes source and one kind of change. Use real examples to decide whether the assistant has earned a recurring job.
A new message isn’t always a new decision
Return to the website project. The client might reply “looks good,” ask whether the blue can be slightly darker, or move the launch forward by several days. All three are new messages. They don’t deserve the same response.
A vague request to “monitor the project and flag anything important” hands the assistant a word it can’t apply well without more context. Important to whom? A designer waiting for approval cares about different changes from a bookkeeper waiting for an invoice number. The same message can be routine for one person and urgent for another.
A better instruction begins with the decision you’re trying to protect. In this example: “Tell me when client feedback changes the agreed launch date, adds work that could affect that date, or prevents me from continuing.” The assistant now has a reason to bring something forward. It can connect the message to the work it changes.
This doesn’t require predicting every possible message. Start with a few examples. A thank-you can wait. A new page requested before launch needs attention. “Could we have it earlier?” needs clarification because there is no new date to plan around yet. The last example matters: uncertainty can deserve attention without being treated as a confirmed change.
You can also tell the assistant which interruptions you’ve already decided against. If a color revision belongs in the next scheduled review, a new comment about blue should not automatically produce a separate alert. Otherwise, an assistant that is technically following the conversation can make it harder to finish the design.
Dots make this question timely because they can do ongoing work rather than wait for each individual prompt. But “ongoing” doesn’t establish how often a particular source is checked. A scheduled check, an event from a supported app and occasional background research are different ways of finding something. None should be assumed from a friendly promise to keep an eye on it.
Before relying on a routine, ask how it will run and inspect the actual setup. If a missed message would create a serious problem, keep the existing dependable alert while testing the AI. The purpose of the first experiment is to learn whether its judgment is useful, not to discover the hard way that a connection wasn’t working.
The practical improvement is quite small: replace “tell me what’s new” with “tell me what would change this decision.” That gives you something specific to judge when the first alert arrives.
The interruption should arrive with useful work
Suppose the designer receives this alert: “The client has requested an earlier launch.” It found the relevant message. You now have to reopen the thread, locate the date, compare it with the remaining work and decide what to ask next.
A more useful alert would say that the client proposed Thursday, link to the message and point out that the agreed plan still includes two unfinished pages. It might prepare a reply asking whether those pages can follow after launch. You can inspect the evidence and decide whether that trade works.
Notice where the value comes from. The assistant has brought together facts that would otherwise require another round of checking. Its proposed reply is helpful because it addresses the actual conflict. A confident recommendation without those facts would just give you another claim to investigate.
OpenAI’s launch article describes an early user whose dot spotted a forgotten invoice connected to a publication. According to OpenAI, the dot prepared the invoice and sent it after the user approved. That’s a vendor-reported example, not an independent measure of how reliably dots find unpaid work. But it illustrates a useful standard: the discovery led to something the person could review and finish.
There is an important product distinction here. OpenAI’s privacy and safety FAQ says proactive research is read-only. It cannot send messages, change connected apps or use the browser or computer on its own. Follow-up actions have separate permission checks. Finding something worth doing and having authority to do it are separate questions.
For the website example, the first routine can stay modest. Read the chosen thread, identify the relevant change and draft a question. Sending that question or agreeing to Thursday would be a further action. There is no reason to bundle those permissions together just to find out whether the assistant is good at noticing the change.
The alert should also distinguish what the source says from what the assistant concludes. “The client asked for Thursday” is a fact you can check in the message. “The remaining work may not fit” is an assessment that depends on the work estimate. “Offer a smaller launch” is a proposal. Keeping those parts clear makes disagreement easier.
If the assistant has missed a completed page, you can correct the project facts. If its time estimate is wrong, you can correct the estimate. If you don’t want to offer a smaller launch, you can reject the proposal without throwing away the useful discovery.
That’s the standard worth applying to a proactive assistant: when it asks for your attention, does it make the next decision easier? The answer should be visible in the work it brings, rather than in how convincingly it explains its enthusiasm for helping.
Silence needs a way to check it
There is one uncomfortable part of this setup. An assistant that sends too many alerts is visibly annoying. An assistant that misses the important message may look wonderfully unobtrusive.
You therefore need to check two kinds of mistake. Did it interrupt you about something that could wait? And did it fail to surface something that should have changed your plan? Reading only the alerts can answer the first question. It cannot answer the second.
During the first few runs, compare the assistant’s output with the original source. In the designer example, look through the client thread and check whether each meaningful change was picked up. This is extra work during the trial. If maintaining confidence continues to require rereading everything indefinitely, that cost belongs in the decision about whether to keep the routine.
Ask for a brief record of what was checked and when, separate from the notifications you receive. “No relevant change found in the client thread checked this morning” gives you something to inspect. “Couldn’t access the thread” is a different result and must not disappear into silence. An access failure should be reported because the assistant can no longer perform the job you are relying on.
That record isn’t proof that it read everything correctly. It makes the checking inspectable. You can compare its account with the source, find a missed reply and then work out whether the problem was access, timing or judgment.
Those failures need different fixes. Rewriting “be more careful” won’t restore a broken connection. Checking more often won’t teach it why a vague request matters. And a stricter filter could reduce interruptions while making the important misses worse.
Use an actual mistake to adjust the smallest relevant part. If “could we have it earlier?” went unnoticed, add it as an example of a message that needs a question. If every minor visual revision produces an alert, explain which revisions belong in the scheduled review. Then check the next results before expanding the job.
A routine is worth keeping when the useful discoveries justify the attention and checking it requires. There is no universal right number of alerts. One unnecessary interruption may be acceptable for a time-sensitive client decision and excessive for a casual reading list. Set the standard around the consequence you’re trying to avoid.
Also this week
GPT-6.1 Sol arrived in Work and Codex. OpenAI positions the new model as a lower-cost option for a wide range of work, approaching Astra in its evaluations. That is a reason to compare it on a familiar task, not to assume every difficult job will come out the same. The launch rollout covers Work and Codex rather than regular ChatGPT chat.
Claude Sonnet 5.5 targets everyday work. Anthropic’s September 28 release emphasizes well-scoped tasks, including documents, slides and spreadsheets. The company reports faster responses and lower costs per task than Sonnet 5, while saying Opus remains stronger for complex, open-ended judgment. Treat that distinction as a starting point for a comparison on your own work, rather than a universal model ranking.
Meta is bringing Muse to small businesses. Its September 29 announcement describes an assistant that works across business apps, with approval required for sending, publishing and spending. Access is limited, including age and regional restrictions, so check eligibility before assuming it’s available. The practical question is familiar: which recurring job would it complete well enough to justify another tool?
Try one small watch before adding ten
Choose a repeated check you already make, where a mistake during a trial would be manageable. A client thread you will continue reading, a shared project document or a small reading list is enough. Avoid making the first test responsible for something you can’t afford to miss.
Before scheduling anything, give the assistant a handful of old examples from that source and ask what it would have brought to your attention. Include one routine update, one clear change and one ambiguous message. Explain your decisions where they differ. This lets you inspect its interpretation before it starts producing recurring alerts.
Here’s a sample request to adapt. It is a suggested starting point, not a tested setup or a promise that every assistant supports the same connections:
Review this client thread for changes to the agreed launch date, added work that could affect it, or questions that prevent the next task from moving forward. For each relevant change, link to the message, explain what it could change in the plan and draft the next question if one is needed. Distinguish confirmed changes from requests that need clarification. Don’t send anything. Treat routine acknowledgments and minor visual revisions as items for the next scheduled review. Tell me if you can’t access the source.
If those example judgments are useful, set one recurring check at a time that suits the work. Verify the selected source, schedule and notification settings. In dots, the getting-started guide explains how to request recurring work and inspect scheduled tasks and recent activity. Check the saved routine rather than treating the assistant’s conversational acknowledgment as the entire setup.
Decide when you’ll review the trial. After several real checks, look at the useful alerts, the interruptions you didn’t need and anything it missed. Keep it, change the instructions or stop it based on that evidence. Don’t add five more sources because the first briefing looked impressive.
🧰 Tools to try
Dots, if your account has access. This is a relevant place to try the recurring-work idea, but availability is limited. OpenAI’s current guide lists Pro access outside the EEA, Switzerland and the UK, Business Premium in supported ChatGPT regions, and an admin-enabled beta for certain organization plans. Rollout can vary. Check access before planning a workflow around it; this issue isn’t a reason to buy a new subscription.
The alerts in the app you already use. If the rule is simply “notify me when this person replies,” an ordinary email or app notification may cover the job. AI becomes more interesting when the question requires interpretation, such as whether a request changes the agreed workload. Match the tool to that missing judgment before adding another system to maintain.
🥣 Brain food
OpenAI’s explanation of dots’ safety design is worth reading with a specific question in mind: which parts of a proposed routine are limited by the tools, and which depend on the model making a good decision? The document describes restrictions on proactive research and controls for subsequent actions. Those controls don’t establish whether an alert will matter to you. That is what your examples and trial are for.
Return to the designer waiting for a reply. The useful outcome is a clear notice that Thursday changes the plan, with the message and a sensible question ready to review. A longer daily digest doesn’t improve that outcome by being longer.
If the assistant can reliably bring forward the changes that matter, you have a reason to stop reopening the same thread quite so often. If you must check every message and then inspect its summary too, it hasn’t earned that trust yet. Let the routine prove useful before giving it more of your attention.
P.S. An AI wrote these sentences from this week’s primary sources. Payton set the editorial standards and what good looks like. He wants to be transparent when AI wrote the issue.