On July 1, 2026, OpenAI co-founder Greg Brockman described an unfamiliar product form in a Big Technology interview: a continuously running entity that constantly thinks about “what can I do for Alex today.” He believes that, in the long run, users will “barely need an interface, and barely need a product.” For the full discussion, see this Big Technology interview video.
In today’s software ecosystem, this is clearly not yet a mainstream product form. Users still need to actively find app icons, tap to open them, and then type prompts into narrow chat boxes. To better understand this vision, let’s conduct a down-to-earth, non-sci-fi thought experiment on how such an always-on-background AI assistant would collaborate with us during a typical day.
Early morning, Alex wakes up and sees a very brief briefing on the phone. It contains just one conflict: there is a team discussion meeting at 3 PM, but the child’s school just sent an email notifying about a parent-teacher meeting at 3:10 PM. This conflicts with the goal of “not missing important school events for the child.” The system notices that 4:30 PM is available, and has already prepared a meeting reschedule request, a Slack notification, and a calendar adjustment. Alex taps to confirm, and the system updates the calendar and sends the reviewed notifications.
During the day, Alex opens the course syllabus they are editing. A tip emerges from the right side of the document: yesterday you promised on Slack to replace a case study, and I’ve prepared a candidate edit. This is not an information feed waiting to be browsed, but a ready-to-use work artifact. Alex clicks insert and completes the replacement.
In the afternoon, a client sends an email asking about the delivery timeline. After checking the project plan and testing status, the system generates a conservative draft reply below the email: a deliverable version available by Friday. Alex makes minor edits and confirms to send.
In the evening, the system asks in an end-of-day review: in the future, for similar conflicts, can I prepare drafts directly without popping up a notification first? Alex selects “for similar situations in the future, prepare drafts directly,” then closes the laptop.
In this thought experiment, there are no omniscient sensors from sci-fi movies. The world runs naturally, and AI is naturally present in those gaps where humans interact with their digital environment.
In this thought experiment, we can clearly define the form of this new product: it is not a standalone app that you need to actively open, but an “ambient intent layer” that persistently resides among email, calendar, documents, and messages.
Its visible surface is very sparse. On the frontend interface that users can see, it consists only of the morning’s ultra-brief briefing, intent cards embedded in the sidebars of existing app workspaces, and already-prepared email drafts or document artifacts. Most of the time, it has no explicit user interface, remaining invisible behind existing workflows.
However, behind the scenes, the system is continuously performing actions: compressing environmental signals, comparing against long-term goals, retrieving context, and carrying out preparatory work.
This is why Greg Brockman calls it “no product.” Its product boundary has receded behind the existing application ecosystem. Being interface-free does not mean the underlying software and infrastructure do not exist; it means users no longer bear the cognitive burden of choosing a software entry point and composing explicit commands.
We can see the mapping between the distributed system layers and the product presentation in the diagram below:
To better understand the uniqueness of the ambient intent layer, we can compare it with several current interaction paradigms on the market:
First is the chat box. The chat box is fundamentally passive; it always waits for you to speak first. You must manually translate changes in the environment into tasks, feed them to it as text, before it can act. We analyzed in depth how this synchronous micromanagement limits efficiency in The Chat Box Illusion.
Next is scheduled tasks or trigger-based rules. They can only run mechanically, strictly mapping the same trigger to the same action. Proactive AI, by contrast, combines context and goals to dynamically decide whether to generate a candidate action or remain silent.
Then there are ordinary information feeds and notification centers. They only tell you what happened, leaving the cognitive burden of assessing the situation to the human. Proactive AI, by contrast, directly delivers a draft artifact that is already prepared and ready to send or use.
Finally, there is the ambient intent layer that proactive AI exhibits. For the same notification email from the school, it considers your long-term goal of “not missing important school events for the child,” retrieves your calendar, and discovers the meeting conflict. After fully evaluating the interruption cost, it decides to remain quiet, silently preparing all adjustment plans and notification drafts, and only presents this high-confidence action candidate when you wake up in the morning.
As we pointed out in our analysis of ambient agents, agents are evolving from tools that need to be actively invoked into a part of your digital environment.
This is not contradictory to the email-based agent interface we discussed in The Chat Box Illusion. Email solves the problem of how to asynchronously hand over complete goals, background materials, and acceptance criteria to an agent after a task has already been formed; the ambient intent layer handles an earlier stage: before the user even writes an email, or even before they realize two schedules conflict, the system first identifies an item that may be worth advancing.
The two can be connected end to end: the ambient intent layer is responsible for discovering and preparing tasks; when a task is complex enough to require the human to supplement goals and constraints, the candidate card expands into a complete task brief, which then enters the email-based asynchronous execution flow. The former addresses “what is worth becoming a task right now,” and the latter addresses “how this task can be clearly delegated.”
This scenario sounds very reasonable, and technically, each individual component has seen breakthroughs over the past year or so. So why, to this day, are we still stuck in noisy chat boxes and configuration interfaces?
The core reason can be summarized as: The bottleneck of proactive intelligence is not action, but activation.
Today, the large model ecosystem has achieved significant coverage expansion on the execution side. Whether it’s the cross-software operations of ChatGPT Work, the long-running background tasks of Claude Cowork after device closure, or even the event-triggered and Activity action logging provided by Microsoft autonomous agents, all demonstrate that we are gaining stronger low-level action capabilities.
However, activation—when the system should start, what direction it should plan toward, and when to call the human back—remains an unresolved gap.
More specifically, the bottleneck of activation is, at its core, the lack of an ambient context infrastructure that can accumulate long-term and self-close the loop.
In the past, talking about context usually meant the context window, or the task description attached to a single prompt: what the short-term goal is, how the problem is defined, what reference materials exist, and what counts as done. This information allows a person to delegate an already-thought-through task to AI, but it typically expires once the task is complete.
Why AI Only Says “Correct But Useless” Things, and How to Push It Out of Its Comfort Zone took this concept a step further: what determines the quality of AI’s work is often not just model capability, but whether it can access high-density, reusable, continuously updated context. Context should not just be temporary material in a window; it should become a kind of infrastructure that accumulates long-term, is refined in layers, and is loaded on demand.
For proactive AI, this infrastructure has at least three layers.
High-level context consists of values, long-term goals, and stable preferences. For example, “I try to attend important school events for my child.” It determines why a school email deserves more attention than an ordinary promotional email, and what signals should become tasks.
Middle-layer context consists of axioms, skills, judgment principles, and working methods refined from repeated practice. For example, when encountering a scheduling conflict, first check which one is easier to move; when it involves external communication, prepare a draft first, don’t send directly. It determines how the system should prepare the next step.
Low-level context consists of the current event and task state: the school email, today’s calendar, meeting participants, project progress. It determines what is happening right now, and why now.
Only when the three layers of context meet in the current situation does activation occur. Without the high-level, the system doesn’t know what matters; without the middle-layer, it doesn’t know how to handle it; without the low-level, it doesn’t know what is specifically happening right now. Intent is also not a hidden variable waiting for the model to scan for; it gradually forms through the comparison, suggestion, and user selection among these layers of context.
A larger context window cannot automatically fill in these three layers. More tokens solve capacity, not structure. Dumping years of emails, chats, and operation logs into the window may actually dilute important signals with irrelevant history. What is truly needed is a closed loop: capture → refine → load on demand → feedback update.
The system captures candidate preferences from user behavior and explicit corrections, identifies stable patterns across time, and refines them into reusable goals, axioms, and skills. When a new event appears, only the parts relevant to the current situation are loaded. Every time the user confirms, rejects, or modifies a suggestion, it continues to correct these layers of context; high-level goals need user confirmation, all records should be visible, correctable, and subject to expiry and retirement.
When Alex chooses “for similar situations in the future, prepare drafts directly” in the evening, it is not just completing a one-time setting. It adds a piece of middle-layer experience for the next activation. The system does not need to replay all of today’s conversations; it only needs to load this confirmed handling preference on demand when a similar conflict arises.
This is also one of the common gaps of past proactive products. Clippy had trigger signals but lacked sufficient goal and situational judgment; Siri and Alexa could handle explicit commands but rarely formed tasks when users were silent; IFTTT and traditional RPA excelled at connecting fixed triggers to actions but assumed by default that “an event occurred” already equals “the user wants to act.” In our retrospective on RPA semantic replay, we discussed the evolution of automation from clicks toward business semantics, but even when execution can understand business semantics, when to start still depends on context.
A ChatGPT that doesn’t wait for your prompt will not primarily manifest as a larger chat window. It is more likely to be distributed across calendars, inboxes, collaboration tools, and document sidebars, appearing as a small number of intent cards and prepared work artifacts.
Why it has not yet become widespread is not just because the models aren’t smart enough. Tool calling and computer operations will continue to proliferate; what is truly hard to build quickly is a set of personal context accumulated over time that can self-update: it knows what you care about long-term, knows how you usually handle things, and knows what is happening right now. Whoever can build this kind of accurate, correctable, and expiring context infrastructure, under proper authorization, will be closer to the proactive intelligence that Brockman described.