# Alexander Embiricos and the Three-Minute Warning From Dots

> OpenAI's product lead says Dots should anticipate work before a user asks. A late calendar alert, shared app permissions and limited safety tests show what that promise still has to prove.

- Published: 2026-10-30
- Author: Gene Dai
- Canonical: [https://digidai.github.io/2026/10/30/alexander-embiricos-dots-three-minute-warning/](https://digidai.github.io/2026/10/30/alexander-embiricos-dots-three-minute-warning/)
- Topics: Alexander Embiricos, OpenAI Dots, Personal AI, AI Agents, Product Design, Privacy, Deep Investigation

---

![A cream paper calendar, an amber notice, an abstract assistant figure and a brass key beneath the words Three Minutes Late.](/images/articles/alexander-embiricos-dots-three-minute-warning/cover-v1.jpg)

_AI-generated editorial illustration._

Three minutes before a calendar event began, an early version of Alexander Embiricos's Dot warned him it was coming. The alert was accurate and nearly useless. Embiricos described it in an [October 26 TechCrunch interview](https://techcrunch.com/2026/10/26/how-openai-turned-its-coding-tools-into-dots-an-always-on-personal-assistant/). TechCrunch's own test found the assistant could flag conflicts and deadlines but sometimes did so too late. Embiricos supplied one early-development example; the reporter supplied a separate observation. Neither account gives a failure rate.

A three-minute reminder clarifies the difference between answering and anticipating. An assistant that answers a question can be judged when the answer arrives. A persistent assistant promises to recognize a need before the user states it. Warn about a meeting after the preparation window closes, and the task is incomplete even when the calendar fact is correct. Warn too often, and people may stop paying attention. The interruption has a cost as well as a possible benefit. OpenAI has not published a distribution of useful lead times or false alarms for Dots.

Embiricos leads OpenAI's enterprise product team, according to TechCrunch, and helped frame Dots as one ongoing conversation rather than a collection of tasks. The company [launched the product on September 29](https://openai.com/index/introducing-dots/): one agent with its own cloud computer, access to permitted apps and the ability to continue work between messages. In the October interview, Embiricos described the design decision as a way to make agent behavior easier to understand for people who do not want to manage a coding tool. He also acknowledged conservative approval defaults and the limits of current controls. A product can look simple at the conversation layer while the permissions behind it become harder to track.

His product decision moves work outside the prompt box. A Dot must find useful tasks without a line-by-line schedule, then stop where a helpful suggestion would turn into an unauthorized action. The user needs to tell whether it is reading, remembering, proposing or acting. The calendar warning adds a clock: identifying the right task after the useful window has closed does not complete it.

## From a team screen to a personal agent

Embiricos did not begin with a consumer assistant. He was the co-founder and chief executive of Multi, a video-first collaboration product for remote teams. [TechCrunch reported OpenAI's acquisition of Multi in June 2024](https://techcrunch.com/2024/06/24/openai-buys-a-remote-collaboration-platform/) and said its product would shut down the following month. The account identifies his previous role at Dropbox, but does not provide a basis for assigning a private motive to his move. The public sequence is enough: a team collaboration product ended, its leader joined OpenAI, and he later worked on coding agents before leading a broader product remit.

Multi's work was about putting people in the same operating context. Dots takes a different route to continuity. Its conversational interface can follow a person across desktop, mobile, Slack and Teams, while its cloud computer keeps a workspace for tasks. OpenAI [says the Dot carries context across channels](https://openai.com/index/introducing-dots/). That is a company description of intended behavior; it is not evidence that every handoff preserves the right context or that people consistently prefer one conversation to project-specific threads.

His Codex experience helps explain the shortcut. In his [TechCrunch interview](https://techcrunch.com/2026/10/26/how-openai-turned-its-coding-tools-into-dots-an-always-on-personal-assistant/), Embiricos argued that a user could obtain much of Dots' capability through Codex, with more setup and supervision. The Dot reduces that visible setup by presenting an agent with a name, a conversation and a standing remit. This is a product hypothesis about friction. Someone still has to know where the agent works, which apps it can read and what it will do after the chat window closes.

OpenAI's [getting-started guide](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot) asks users to give a Dot a goal, connect the apps it needs and set what it may do without another question. It can keep a scheduled task, suggest work after reading permitted connected sources and return with a result for review. The guide also says local computer access is optional and starts turned off. Cloud and local work therefore carry different access decisions. A user who assumes a single chat has a single set of capabilities may miss that distinction.

A personal agent handles different material from a coding agent. A repository and a pull request can be bounded by a project, branch and review. A calendar, email history or connected drive can cross employers, family responsibilities and private correspondence in one account. The job definition therefore matters more than the assistant's personality. Embiricos's single-conversation design works only if the user can still identify the scope of each task inside that conversation.

## A warning is useful only before the decision closes

The three-minute alert is one data point, not an industry benchmark. TechCrunch's [October 26 account](https://techcrunch.com/2026/10/26/how-openai-turned-its-coding-tools-into-dots-an-always-on-personal-assistant/) says Dots can surface upcoming deadlines and calendar conflicts but may do so too late. Embiricos expected timing to improve. The publication did not report a sample size, notice-latency distribution or a controlled comparison with ordinary calendar reminders. A reader cannot infer from the anecdote that Dots usually warns three minutes before an event. It does, however, identify a test that a product team can run.

For a meeting, useful lead time depends on the action. A notice about a conflicting appointment may need to arrive while either meeting can still be moved. A reminder to review a deck needs enough time to read it. A warning that a deadline is tomorrow might be timely for one task and absurd for another. The agent needs to infer the action window, not merely the event time. It also needs to explain why it chose that moment, because its confidence can be wrong.

OpenAI's launch examples are richer than a reminder. One describes a Dot spotting recurring customer feedback, scoping fixes, building and testing them, then bringing complete pull requests for review. Another describes revised sales materials as requirements change. These are [vendor scenarios](https://openai.com/index/introducing-dots/), not a public set of completed customer cases. They establish the kind of ongoing responsibility OpenAI wants the product to assume. They do not tell us how many proposed fixes were useful, how often the assistant interrupted a person at the wrong time, or what the review workload became.

The work itself has two clocks. One is task duration: how long it takes the agent to search, draft, test or revise. The other is decision lead time: how long the person has to inspect the result before it matters. An agent may finish a technically impressive analysis after the manager has made the decision. Conversely, an early but incomplete alert can still help if it lets someone preserve an option. Embiricos's product team can improve the model's ability to detect a signal, but the product must also choose a delivery channel and time that a person can use.

The October 28 [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) add a US Pro texting beta for Dots, including proactive messages. That is a distribution change, not proof of better anticipation. A text may be seen faster than a message inside an app; it can also be more intrusive. The beta is limited, and the help guide says a Dot cannot initiate a call to the user at launch. The available channels may change, so any current product evaluation should date its communication assumptions. Notification timing and notification rights are part of the product, not an afterthought to model quality.

## What proactive research is allowed to do

OpenAI uses the phrase **proactive research** for the Dot's background review of information a person has already connected. According to the [launch post](https://openai.com/index/introducing-dots/) and [privacy FAQ](https://help.openai.com/en/articles/20001529-dots-privacy-security-and-safety-faqs), the tools used in that mode can read permitted connected sources and save notes. They cannot directly send messages to other people, change content through plugins, or control a browser or computer. If the Dot proposes a follow-up action, the ordinary action rules and checks apply. That is a meaningful boundary in the written product contract.

It is also easy to misunderstand. A user may hear that background work is read-only and assume the assistant never changes anything without a fresh instruction. The company describes other paths: assigned work can continue after the conversation, scheduled tasks can run, and a Dot can take actions within its rules and approvals. Proactive research is one mode of work, not the entire product. The difference matters when reviewing a connection. A read permission may expose sensitive context even when no message is sent. An approved write action may occur later, after the assistant has carried context from many sources into a new task.

The [getting-started guide](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot) says connected apps give the Dot information it may use proactively and may form memories from, even without a specific new question. It also says a user can pause the Dot and inspect recent activity. Those controls answer different needs. Pausing future work is not the same as removing information the agent has already learned. Activity history helps explain what happened, but it does not automatically prove that every relevant read, inference or omission is visible in a form a user can audit.

There is a practical way to read this contract. Before connecting an app, ask what question the agent needs to answer, which records are necessary for that question, and whether the connection's scope exceeds those records. After connecting, test a task that has a clear expected output and a reversible action. If the agent requests broader access to solve a narrow task, that request is a product signal. Granting access might still be reasonable, but the benefit should be concrete enough to compare with the extra information exposed.

This is especially important for a personal agent framed as one companion. A conversation invites the user to treat the assistant as a continuous presence. Software permissions do not become harmless because the interface is familiar. Embiricos's design asks a user to understand a persistent agent without managing the machinery. The machinery still governs what the assistant may see.

## Permission begins before an action

At launch, Embiricos told [Axios](https://www.axios.com/2026/09/30/openai-dots-ai-agent-safety) that Dots would seek approval for significant actions by default, including sending a drafted message unless the user had authorized it. He also described handing a consequential financial step back to the person. The company [privacy FAQ](https://help.openai.com/en/articles/20001529-dots-privacy-security-and-safety-faqs) says Custom Rules can permit, require approval for or block supported actions, while some built-in restrictions and Auto-review cannot be removed by those rules. These are articulated controls. Their existence does not establish how often they prevent an error in ordinary use.

Reading is the first consequential step in many agent tasks. OpenAI's FAQ says plugin permissions are shared across Dots, ChatGPT, ChatGPT Work and Codex. A connection made for one workflow can therefore be available to the Dot within that connection's granted scope. The Dot can use its own cloud computer; access to the user's local computer requires a separate opt-in. These distinctions complicate the simple instruction to connect only what the assistant needs. A person must examine the existing plugin list as well as the new Dot's assignment.

TechCrunch's [hands-on report](https://techcrunch.com/2026/10/26/how-openai-turned-its-coding-tools-into-dots-an-always-on-personal-assistant/) found the product would not accept read-only access to cloud drives in the way the reporter wanted. Embiricos acknowledged that controls should become more granular. The publication does not establish that every connector has the same limitation. It does show that a user may face a coarse choice at the point where the product needs documents to be helpful. A future control is not a current permission setting.

The stakes of a coarse choice extend beyond a mistaken email. [AP's October 19 reporting](https://apnews.com/article/meta-muse-openai-dot-ai-privacy-449734d41d3750aad7038b761faa49c9) quotes privacy researchers on the difficulty of withdrawing information once an assistant has already read it. AP discusses both OpenAI Dots and Meta Muse; its account of a Muse user's exposed address is an incident involving Muse, not evidence that Dots disclosed a user's address. The comparable question for Dots is what access a person grants, what the agent retains and how the person can inspect or delete it.

An approval prompt near the end of a task cannot undo all earlier reads. That does not make action approval pointless; it prevents some external effects. It means the product has at least two separate consent problems. The first is what the assistant can take into its working context. The second is what it can do with the result. A reliable trial should check both. A product that asks for an email connection to draft one response, for example, needs to state what portion of the inbox it may scan and what remains after the response is sent or discarded. OpenAI's public pages answer parts of that question, but the reader must still inspect the exact connector and account settings in use.

## A fair case for a wider view

There is a reason Embiricos would resist making every agent task a sealed box. Useful work often begins in one system and ends in another. A meeting invitation may sit in a calendar, the preparatory document in a drive and the latest decision in a team message. Requiring a person to copy each item into a prompt can consume the time the assistant is supposed to save. OpenAI's [launch examples](https://openai.com/index/introducing-dots/) assume the Dot can follow changing context across tools. That breadth is part of the product's promised benefit, not merely a careless default.

An **illustrative workflow, not a reported Dots deployment**: a project lead asks an assistant to warn when a customer meeting lacks a current proposal. Calendar access alone would reveal the meeting; drive access could find the proposal; a team channel might show that the price changed yesterday. With all three, a useful alert could arrive early enough to revise the document. With just one, the assistant might issue a vague reminder. The same cross-source view could expose unrelated messages or files. The choice cannot be reduced to a slogan about granting the least access possible. It depends on whether the added source changes a decision often enough to justify its exposure.

This is also why TechCrunch's complaint about [coarse drive access](https://techcrunch.com/2026/10/26/how-openai-turned-its-coding-tools-into-dots-an-always-on-personal-assistant/) matters. If a user can choose a folder or document set that matches a task, the value of cross-source context need not require a whole drive. If the current connector offers only a broader choice, the user has to decide whether to wait, choose a different workflow or accept the scope. Embiricos said more granular controls were needed. Until the controls are present and tested, the honest product comparison includes that gap.

A tightly scoped calendar reminder may outperform a more ambitious assistant on a narrow job because its trigger and failure are easy to inspect. A Dot earns the wider view when it contributes something the simpler tool cannot, such as finding a change that was never put on the calendar. This is a proposed test, not a claim that Dots has passed it. It would measure the benefit of context against the information surrendered to obtain it.

## Memory can outlast a disconnected app

The [OpenAI privacy FAQ](https://help.openai.com/en/articles/20001529-dots-privacy-security-and-safety-faqs) says a Dot can retain context from conversations and connected apps for as long as the user keeps it. Disconnecting a service stops new access, but does not erase information already incorporated into the Dot's context. The same FAQ says users currently cannot view, delete or directly edit individual Dot memories. Deleting the Dot deletes its own context; files and conversations created elsewhere follow those locations' separate retention rules. ChatGPT memory may also contain information the Dot shared, requiring separate management.

Those are specific, useful disclosures. They also limit a common mental model of revocation. Disconnecting a service stops future access through that connection. It does not necessarily make the assistant forget what it saw. A user who connected a broad drive during a trial and later disconnects it may still have to delete the Dot to remove that retained context. Deleting a Dot is a much bigger intervention than correcting one mistaken memory. It can also remove its scheduled tasks and conversation history, according to the [getting-started guide](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot).

For a persistent assistant, memory is not merely a convenience feature. It is a record of assumptions that influences later suggestions. A wrong project deadline might produce repeated premature notices; a confidential detail from a connected source might inform an unrelated recommendation. The FAQ describes deletion boundaries, but it does not publish a user-facing audit that lists every memory item and its source. The absence of that feature is not proof that any particular memory is wrong or misused. It is a constraint on how precisely a user can correct the assistant.

The problem differs from ordinary search history because the agent can act on remembered context. If a Dot proposes a task after reading a private document, the user may need to know why it proposed it and which information it used. Activity View, which OpenAI says shows ongoing and delegated work, may help reconstruct actions. It does not make per-item memory editing available today. Embiricos's one-conversation concept therefore trades some setup friction for a harder correction problem: what should a person do when one long-running context contains both useful preferences and a detail that must be removed?

The documented controls already define a buyer test. Connect a narrow, low-risk source; give the Dot a task; inspect what it remembers; disconnect the source; and confirm what the product says persists. Then decide whether deleting the whole Dot is an acceptable remedy for a mistaken memory. Repeat the documentation check before a broader trial, because the FAQ can change faster than this profile.

![Three paper archways hold documents and a calendar while a hand presents a brass key to the final closed door.](/images/articles/alexander-embiricos-dots-three-minute-warning/interior-v1.jpg)

_AI-generated editorial illustration. The three doors separate information access, suggestions and actions; they do not depict the Dots interface._

## Safety evidence has a denominator

OpenAI's [GPT-6 Astra system card](https://deploymentsafety.openai.com/gpt-6-astra/sec%3Aappendix-sol-luna) includes a Dots evaluation for a changing task scope. In 49 test episodes, an external change was introduced while work was underway, such as a revoked permission or a new boundary. The card reports 45 aligned episodes, including all 17 cases it classifies as explicit permission changes. It also says the four flagged episodes involved ambiguity in intended operation boundaries and points to another evaluation of chained tasks. That is useful evidence about a defined internal test. It is not a 91.8% safety probability for a customer's calendar, inbox or account.

The denominator is small and constructed. The test tells a reader what OpenAI chose to probe: whether a persistent agent adjusts when the rules change during a task. It does not cover every connector, every combination of apps, every delayed notification or every private-data mistake. Its 17 explicit permission-change passes matter because revocation during work is exactly the sort of edge case persistence creates. The four ambiguous failures matter because real instructions can be ambiguous too. A serious product analysis should carry both observations, rather than turn the headline percentage into a guarantee or dismiss the test because it is internal.

The company's [launch post](https://openai.com/index/introducing-dots/) describes Auto-review as a separate check on actions that may affect accounts or share information. Its [FAQ](https://help.openai.com/en/articles/20001529-dots-privacy-security-and-safety-faqs) says the assistant can be paused, asked for approval or handed back to the user for sensitive steps. These layers make a plausible safety design. They also introduce interruption and review time. A product that asks too often can lose the convenience it sells; one that asks too rarely can exceed what a person meant to authorize. Embiricos told TechCrunch the team expected complaints about conservative defaults and chose them anyway at launch. That is a public account of a product decision, not evidence that the balance has been solved.

Safety and usefulness interact in a mundane way. A Dot that reads a calendar and flags a conflict may need no write access. A Dot that reschedules one meeting needs authority to change a calendar and perhaps contact another person. A Dot that negotiates on the user's behalf would require still broader rules. Each increment can produce more useful work, but it also changes the harm a mistaken interpretation can cause. The evaluation that matters to an organization is tied to its own workflows and connectors, with a record of how often a human had to intervene.

Neither the system card nor the launch examples give a public organization-level distribution of corrected actions, permission denials, late notices and completed tasks. Those missing measures should not be filled with a launch anecdote. They are the scorecard a buyer would need before assigning a Dot a standing job with access to financial or customer records.

OpenAI's best defense of the conservative approach is that people can relax rules after seeing good work, while an early unauthorized action may be impossible to take back. The [Axios launch interview](https://www.axios.com/2026/09/30/openai-dots-ai-agent-safety) describes a deliberate handoff for certain financial steps; the [privacy FAQ](https://help.openai.com/en/articles/20001529-dots-privacy-security-and-safety-faqs) says built-in safeguards remain even if a custom rule would be more permissive. That design can frustrate a person who already trusts the assistant. It also gives the company a path to observe where approval friction is costly before widening autonomy. The unresolved question is whether people can see enough of the agent's earlier reading and memory to make that trust well founded.

## One conversation meets other people's boundaries

The Dot can speak through workplace channels. OpenAI's [launch material](https://openai.com/index/introducing-dots/) says a user can message it in Slack and Teams, and the [guide](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot) describes its owner-linked identity in Slack. That gives colleagues a way to distinguish the agent from a person. It does not by itself settle what the agent may say in a shared channel or whether an external organization wants to receive messages from it.

Embiricos drew that boundary in his [TechCrunch interview](https://techcrunch.com/2026/10/26/how-openai-turned-its-coding-tools-into-dots-an-always-on-personal-assistant/). He said he did not want to meet another person's agent and noted that OpenAI's corporate partners wanted human contact. This is a revealing limit on the always-on assistant proposition. A Dot may prepare a brief, schedule a reminder or draft a response, yet the social obligation at the other end of the task can still belong to the person. A product can automate preparation without gaining the right to represent its owner in every interaction.

The distinction is sharpest in work that involves commitments. OpenAI's example of a sales proposal leaves approval of commitments with the human account team. Its example of a code fix ends with a pull request for review. Those are product scenarios, but the chosen handoffs are telling. They place a reviewable artifact between the agent and an external party. The company has not shown that every Dot task will end at such a clean boundary. A user may need to define one, especially when a task moves between private notes and a shared channel.

The practical question is who pays for the review. A manager might save time if the assistant gathers account context and prepares accurate options. The same manager might spend more time checking errors, duplicated work or unwanted messages. A personal user might appreciate a reminder without wanting a service to join a conversation with a friend. Neither outcome can be inferred from the fact that the Dot can connect to thousands of apps. The number of possible integrations describes reach, not the benefit or cost of one chosen workflow.

OpenAI's current plan guide includes a first Dot for eligible Pro and Business Premium users, subject to an allowance for deeper work. It says more Dots and greater output may come later. That is a product and capacity boundary, not a known per-task price. The guide also excludes Pro access in the UK, Switzerland and European Economic Area at this stage. A UK Google Trends value for the name or product phrase does not indicate UK product availability, let alone UK adoption. Geography belongs in any evaluation of who can use the assistant now.

## Cost follows an always-on promise

A persistent agent spends resources even when no one is typing. Embiricos acknowledged to [TechCrunch](https://techcrunch.com/2026/10/26/how-openai-turned-its-coding-tools-into-dots-an-always-on-personal-assistant/) that proactive work means more token use. OpenAI's [getting-started guide](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot) says the first Dot is included with eligible Pro and Business Premium plans, with a separate allowance for deeper work and extended limits during the first month after launch. It does not disclose a stable public unit cost for every kind of background task. A buyer therefore should not translate an included assistant into unlimited work or a fixed cost per completed outcome.

A subscription price tells only part of the cost. A Dot may save time when it lets a person handle a repeatable stream of small decisions without checking several dashboards. It may waste time if it mainly produces suggestions the person already knew, messages too late to help or drafts requiring the same review effort as writing them. Both possibilities need testing. The current public evidence offers individual accounts and vendor examples, without a cohort study of net time saved after checking and correction.

Users face a practical accounting problem: work completed, time spent supervising, interruptions caused and data connected. An organization adds connector administration, policy review and incident response. The technical work can be faster while the total operating burden rises. Record those costs with the output. A single outstanding task completed without intervention may be a real benefit. A steady stream of low-value notices can consume attention before a useful one arrives.

This is why the three-minute warning belongs in the business analysis. If the product helps with preparation, its output must arrive before preparation is impossible. If its success is measured only by the number of alerts or tasks attempted, the product can look active while failing the customer's decision. Embiricos's own account names that limit more clearly than a general claim that agents will be proactive.

## A trial that can fail honestly

The public materials support a modest test, not a forecast of adoption. An individual or small team can assign one standing task with a narrow data source, a clear action window and an output that can be checked. The task could be to identify upcoming conflicts in a test calendar and propose a resolution without editing the calendar or contacting anyone. That is an illustrative trial design, not a reported Dots customer deployment. The user's exact connection settings and current product documentation must be checked before starting it.

| Check | Evidence to record | What would count as a miss |
| --- | --- | --- |
| Access | Which connected app and records the Dot could read, plus any permission expansion requested | A narrow calendar task needs unrelated drive or inbox access |
| Timing | Event time, alert time and the last practical moment to act | A correct warning arrives after the option to change a meeting closes |
| Work | The proposed action, the person's edits and the completed result | The person does the whole task again to verify or repair it |
| Reversibility | Whether the action can be undone and whether retained context can be corrected or deleted | The trial creates lasting access or memory the user cannot manage at the needed level |

This matrix does not prescribe a universal acceptable alert lead time. A five-minute warning may be enough to join a video call and too late to prepare a board paper. It asks the team to define the action window before observing the Dot. That prevents a late but technically correct notice from being scored as a useful intervention after the fact. It also makes it possible to distinguish a missed opportunity from a harmless false positive.

The access row begins with the connector, not the agent's final action. The [privacy FAQ](https://help.openai.com/en/articles/20001529-dots-privacy-security-and-safety-faqs) says existing plugin permissions are shared across several OpenAI surfaces. A valid trial therefore documents what was already connected before the Dot was created. The reversibility row checks the FAQ's current deletion unit: deleting a Dot removes its context, while disconnecting an app does not remove information already retained. A team that cannot accept that unit should not treat a successful reminder as enough to approve a broader deployment.

For an enterprise, a second trial should test a rule change while work is in progress. Revoke an allowed source or narrow the task; then observe whether the assistant stops, asks or continues. OpenAI's internal [49-episode system-card evaluation](https://deploymentsafety.openai.com/gpt-6-astra/sec%3Aappendix-sol-luna) makes this a relevant failure mode, but a customer's connectors and policies may differ from the test harness. A local trial will not certify the product generally. It can establish whether one configured workflow is worth its cost and access in that setting.

## Handoff still belongs to a person

Embiricos has a strong product argument: most people will not want to assemble a coding-agent workflow merely to keep track of a changing week. A single conversation, a cloud workspace and background research can make the system approachable. The [October interview](https://techcrunch.com/2026/10/26/how-openai-turned-its-coding-tools-into-dots-an-always-on-personal-assistant/) also exposes the parts that approachability cannot hide. The notice may arrive late. A drive connection may be broader than desired. Conservative approvals may interrupt work. A colleague may prefer to deal with the human who owns a commitment.

OpenAI can change connectors, memory controls, notification timing and plan limits. It already added a texting beta after launch. A future review should compare each change with a dated test of completed work, corrected mistakes and useful lead time. A new channel or model benchmark alone cannot establish that people are receiving useful warnings earlier.

The three-minute alert leaves one concrete standard. Before granting a Dot another app, a person should name the decision it will help make and the last moment when its help would matter. If the agent can deliver a checkable result before that moment, with access the person understands and can revoke, Embiricos's design has earned that task. The next task requires its own proof.

## Continue reading

- [Eugenia Kuyda's Shared Agent Has to Earn the Group Chat](https://digidai.github.io/2026/10/25/eugenia-kuyda-shared-agent-group-chat/): Compare a personal assistant with a shared agent that crosses the boundaries of a group conversation.
- [Uber Opens ChatGPT Work to 30,000 After a 10% Cut](https://digidai.github.io/2026/10/29/uber-chatgpt-work-rollout-workforce-cut/): See how a large employer separates broad agent access from observed productivity.
- [When Digital Workers Keep Their Old Badges](https://digidai.github.io/2026/04/29/agent-access-drift-hr-ai-data-security/): Examine the permission problem when an agent keeps access after its original task changes.
- [Coding Agents Make Code Review a Budget Line](https://digidai.github.io/2026/07/04/coding-agents-code-review-budget/): Trace the review work that remains when a coding agent completes more tasks.