目錄
In August 2026, an interesting product request appeared on r/Notion: users wanted Notion to provide an AI search component that could be placed directly inside a Page, so Workspace search would not have to start from the global entry point every time. This is not the first time a similar request has appeared. Users have previously asked for an official Search Bar that could be embedded inside Pages. Now that Notion AI can answer Workspace questions and search across Connected Apps, the request has naturally moved one step further: if Enterprise Search can already be limited to a specific Page, Teamspace, or Source, why not let users save that scope directly inside a project page so the search entry point stays attached to the working context?
On the same day, another r/Notion post complained that generative AI still lacks a stable long-term knowledge layer, including the difficulty of continuously reusing established knowledge, fully connecting Private Knowledge, rebuilding Context repeatedly, and finding information from earlier conversations again after some time has passed. The same content was also posted by the author to r/ChatGPT, so the more accurate description is that one user brought the same set of concerns to different AI communities rather than two separate Notion users independently reporting the same case. Taken together, these discussions are not really about whether “the model remembers enough.” The deeper issue is who manages Context. For productivity tools, AI does not necessarily need to remember everything forever. If it can reliably know which set of information it should search whenever work begins, many so-called “memory problems” can first be addressed at the Retrieval layer.
What Can Notion Enterprise Search Already Do?
Search Scope Can Already Be Narrowed to a Specific Page or Teamspace
Notion Enterprise Search is currently available on Business and Enterprise plans, with its main entry point in Home. It can search the Notion Workspace, connected Slack, Google Drive, Microsoft Teams, Jira, and other sources, with optional Web Search. When an answer uses information from the Workspace or Connected Apps, Notion provides sources so users can return to the original material for verification. Search is also no longer limited to the entire Workspace at once. Users can add a specific Page or Person as Context, specify a Page, Teamspace, or Person, and adjust Sources to include only the Workspace, a particular Connected App, or a narrower Workspace area such as a specific Page or Teamspace.
Enterprise Search can currently switch between OpenAI GPT, Anthropic Claude, and Google Gemini models, although the available data sources are not necessarily identical across models, so the model name alone does not guarantee the same search capabilities. This means the community is not really missing the ability to narrow search scope. What is missing is a way to save an already configured scope as a permanent interface on a specific Page. Today, each time users enter Enterprise Search, they still need to specify Context or Scope again. If a long-running project only needs Project Briefs, Decision Logs, Meeting Notes, and related documents, it is natural to want that configuration to remain directly on the project homepage.
Notion Already Has AI Block, but It Is Not an Interactive Search Box
AI Block Can Already Be Embedded in a Page and Assigned Context
When discussing “embeddable AI search,” it is easy to overlook the fact that Notion already provides /AI Block. An AI Block can be inserted directly into a Page. It can process the current Page, but users can also configure a Prompt, specify Context from the Workspace or Connected Apps, and choose Search Sources. Once configured, pressing Generate produces a result based on the current data, and users can Generate again later when the information needs to be refreshed.
For example, a project homepage could contain an AI Block permanently instructed to review the requirements document, Decision Log, and Meeting Notes and summarize unresolved decisions, progress risks, and next steps. If every project has similar needs, the AI Block can also be placed inside a Database Template so every new Project Page automatically includes the same Prompt and Context design. This already comes close to the idea of “AI following the Page,” but it is still different from what the community is actually requesting. AI Block is closer to “fixed question＋fixed data sources＋manual regeneration,” rather than an Enterprise Search Widget where every viewer can enter different questions directly on the Page, continue with follow-up questions, and use a Search Scope that has already been predefined.
In other words, Notion has already completed roughly half of this request: fixed Context is possible. What is still missing is a Query Interface that allows free-form questions within that predefined Context.
Why Is It More Convenient for Search Scope to Follow the Page Instead of Starting Globally Every Time?
Scope Affects Retrieval Quality, but Smaller Is Not Always Better
In a Retrieval-Augmented Generation architecture, answer quality depends not only on model capability but also on which information the Retrieval stage brings back. Suppose a company Workspace contains five years of Project Pages and the same project name has been reused several times. Asking “What is the delivery date for this project?” across the entire dataset could bring older specifications, historical projects, or similarly named documents into the candidate results. If the search interface is already located on the current project page and its default Context already points to the correct Project, the chance of irrelevant content being retrieved naturally becomes lower.
But that does not mean a smaller search scope always produces a more accurate answer. The real answer may exist in a company-wide policy, another Teamspace, or even a Slack decision. If Scope is locked too narrowly, necessary evidence may be excluded as well. A more useful way to think about Scope is as part of Intent: when asking “What did this client confirm last time?”, the client page is a natural starting point. But when asking “What is the company’s current standard pricing policy?”, the search should not be restricted to a single project.
So the real value of Page-based AI Search is not permanently shrinking the search scope as much as possible. It is allowing the most frequently used Context to be configured in advance so users do not have to tell the system what they are currently working on before every question.
“Permanent Memory” Does Not Have to Mean the Model Remembers Everything; It Can Also Be Handled by the Knowledge Layer
Storage, Retrieval, and Memory Are Actually Three Different Problems
The August 20 discussion grouped together several concerns, including AI lacking Permanent Storage, difficulty connecting naturally to Private Knowledge, remembering something and later forgetting it, incomplete Cross-chat Memory, and the repeated work required to establish Context, save Chats, and find information again. These frustrations are understandable, but from a system-design perspective they combine three different problems: Storage, Retrieval, and Memory.
Storage answers whether the information has been saved at all. Retrieval determines whether the right information can be found again when needed. Memory refers to whether the model retains previous interactions and preferences across conversations. Notion’s strengths are primarily in the first two layers: Pages, Databases, Files, and Connected Apps already function as Knowledge Storage, Enterprise Search handles Retrieval, and the model sits on top and uses the retrieved Context to construct an answer. This architecture does not require the model to “remember that meeting from last year forever.” It only requires that the meeting still exists and can be retrieved correctly when it becomes relevant today.
An AI Search Widget permanently attached to a project page would improve this same layer. It would not give the model permanent memory; it would keep the Retrieval entry point where the work actually happens.
Permissions Are a Real Issue for Embeddable AI Search, but They Cannot Be Used to Explain Why Notion Has Not Built It Yet
Enterprise Search Already Filters Results Based on the Current Viewer’s Permissions
If an AI Search Block is created by someone who can access documents A, B, and C, while another viewer can only access B, there is a real design question: should the search result be based on the creator’s permissions or the viewer’s permissions? However, this cannot be used to jump directly to the conclusion that “Notion has not built Embedded Search because permissions are too complicated.”
Existing Enterprise Search already provides Permission-aware Retrieval. Search results are filtered according to the current user’s Access Rights in Notion and Connected Apps, and content the user cannot normally access does not suddenly become visible simply because they use Enterprise Search. If Notion eventually introduces an interactive Page Search Widget, the most reasonable design would similarly execute each Query using the current Viewer’s permissions. The same Widget producing different results for different users is normal behavior for permission-aware search.
The existing AI Block requires more caution. Once an AI Block generates text, that text becomes Page Content. If the creator uses sensitive sources they are authorized to access to generate a summary and then shares the Page with someone who does not have permission to those original sources, the generated text itself does not automatically disappear because the underlying documents have different permissions. In a company environment, generated content inside fixed AI Blocks therefore still needs to be reviewed like ordinary Page Content. The existence of permissions on the source documents does not mean the generated text automatically inherits the same restrictions.
Cost May Affect Product Design, but Embedding Search in a Page Does Not Mean AI Has to Run Every Time the Page Loads
Another easy assumption is that if fifty project pages each contain an AI Search Widget, every Page Load would automatically trigger a model call and therefore generate substantial cost. But that is not an inherent requirement of Embedded Search. A search box can simply wait until the user actually enters a question before executing, just like Enterprise Search does today.
Existing AI Block already demonstrates this. It does not recompute every time the Page is opened; it updates only when the user presses Generate. So “embedded in a page＝uses AI allowance every time the Page loads” should not be treated as a given. If Notion eventually introduces an interactive Search Block, Cache design, Usage Allowance, Concurrency, and Query History for different Viewers may all require additional product decisions, but Notion has not publicly stated that these are the reasons the feature does not yet exist. There is no need to invent an explanation on the company’s behalf.
Does AI Search Automatically Get Worse as the Workspace Gets Larger?
The Problem Is Usually Not the Amount of Data, but Uncertainty About Which Version Is Current and Authoritative
Several r/Notion discussions from the same week about “building more and more systems” can help illustrate this issue, but they should not be turned into the claim that “more Pages automatically make AI less accurate.” One user who had used Notion for six years said that Writing, Tasks, Inventories, and Finances were almost entirely stored there and that they had once enjoyed continuously building new Structures, but later began reconsidering their relationship with Notion. However, that discussion also involved Privacy, Local-first software, and concerns about the direction of Generative AI products, so it cannot simply be summarized as “the system became too large and therefore stopped working.”
Another Habit Tracker post was more straightforward. The poster spent a weekend building a Tracker and stopped opening it after only 11 days, but commenters also said they had maintained their own Trackers for two years or even five years. One person abandoning a Tracker therefore cannot prove that Habit Tracking is inherently unsustainable. A more reasonable conclusion is that whether a structure remains useful over time still depends on actual needs and maintenance cost.
The connection to AI Search also does not need to be framed as “more data means more noise.” A large Knowledge Base can work extremely well. The real difficulty appears when several versions of the same information exist at the same time without clear Status, Owner, Date, or Source of Truth. In that situation, both humans and Retrieval Systems have a harder time identifying which version should currently be treated as authoritative.
Why Are Small Notion Databases Often Easier to Understand?
The Common Trait Is Not That Smaller Is Always Better, but That the Purpose Is Easy to Explain
This week, a first-year university student shared that they had originally used Excel to collect TikTok Creator Accounts for a small research project, then moved the data into Notion and found it easier to organize and retrieve. Commenters pointed out that a Database can certainly become very complex, but there is no reason to build every possible feature before the need actually appears. A vehicle-maintenance Tracker provides another example with a clearly defined scope. Based on community feedback, the creator added fields such as “mileage since last Tire Rotation,” while the entire system remained focused on vehicle-management needs such as Service Log, Insurance, Warranty, Fuel, Reminders, and TCO instead of expanding into a Dashboard for managing every aspect of life.
Another user used Notion to organize information about a family member’s cancer treatment, including Appointments, Medical Reports, Treatment Progress, and questions to ask doctors. They also mentioned that they had previously fallen into the trap of making Notion excessively complicated, while the clarity of this particular need made it easier to understand which information genuinely had to be retained. These examples are better used to support the idea that every Database should be able to explain its purpose quickly, rather than the claim that “Databases must always be small.” The clearer the purpose, the easier it becomes both for people to retrieve information themselves and for AI to understand where it should search.
What Can You Do Today Without an Interactive AI Search Widget?
For Temporary Questions, Use Enterprise Search and Narrow the Scope
If you only need to ask a temporary question such as “What was the final delivery date confirmed for this project?”, the most direct approach is still to use Enterprise Search and point the Scope at the current Project Page or Teamspace before starting the Query. Notion already supports this level of search granularity, so there is no need to search the complete Workspace, every Connected App, and the Web every time. This is also clearer than simply writing “please only look at Project A” inside the Prompt, because Scope itself is part of the Search Interface.
For Repeated Questions, Use AI Block
If the question is almost the same every week—for example, summarizing unresolved project Decisions, finding Action Items without an Owner, or consolidating conclusions from recent client Meetings—you do not necessarily need to wait for a new Search Widget. You can already place an AI Block inside a Project Template, point its Context at the relevant Pages or Connected Sources, and write the Prompt in advance, then press Generate whenever an update is needed. This is closer to genuine Embedded AI than maintaining a separate list of Prompts because the Prompt, Context, and Output all stay on the same Page where the work happens.
Create a Clear Context Entry Point on the Project Homepage Without Moving All the Data onto One Page
A Project Page can contain a permanent Project Context section bringing together the currently valid Brief, Decision Log, Deliverables, Meeting Notes, and main Database Views. The goal is not to copy all of the data again, but to make it explicit which sources the Project should currently reference. This makes it easier not only for AI but also for people to find the real Source of Truth, while Enterprise Search and AI Block can both use the same Page as the starting point for Context.
Mark the Status of Old Data Instead of Deleting It Based on How Long It Has Been Unopened
A Page that has not been opened for three months is not necessarily obsolete. Decision Records, legal documents, research material, and historical projects may be accessed infrequently but remain valuable when needed. Deleting information simply because it has not been used recently is therefore not a general solution for improving AI Search.
A safer approach is to use states such as Current, Archived, and Superseded, clearly indicate which newer document replaced an older version, move material into Archive when appropriate, and use descriptive Page Titles so both people and AI can tell from the name what the content is about. For Retrieval, knowing “what document is this, is it still valid, and which version is authoritative?” is usually more important than reducing the Workspace to a very small number of Pages.
What Embeddable AI Search Is Really Missing Is a Free-Form Query Interface That Can Save Its Scope
Notion already has three pieces of the puzzle. Enterprise Search can search the Workspace, Connected Apps, and the Web while narrowing Scope to a specific Page or Teamspace. AI Block can live directly inside a Page, preserve a Prompt, use specified Context, and update when Generate is pressed. Notion Agent can then go further by creating and modifying content inside Workspace Context.
What is still missing from the official product documentation is a direct combination of the first two: an Enterprise Search Block that can be embedded inside a Project Page, comes with a predefined Scope, but still allows each user to enter different questions freely and continue with follow-ups. This is why the community request is reasonable even though it initially sounds like “just add another search box.” The request is not for another model or another Ask AI button. It is for Context to remain attached to the Page so users do not need to redefine what they are working on before every question.
Until Notion officially introduces such a component, repeated questions can go into AI Block, temporary questions can continue through Enterprise Search, and the Workspace itself can make Current, Archived, Owner, Date, and Source of Truth explicit. Whether a model will permanently remember something discussed six months ago is difficult to control. But where today’s question should look for its answer can at least be defined in advance.
FAQ
There is currently no officially documented component equivalent to Enterprise Search that can be embedded directly inside a Page and allow every user to freely enter different questions within a fixed Scope. However, Notion already provides AI Block, which can live directly on a Page, preserve a Prompt, Context, and Search Sources, and update when the user presses Generate. So it would be inaccurate to say that Pages have no contextual AI at all. What is still missing is a free-form interactive search interface.
AI Block is better suited to fixed questions, such as repeatedly summarizing project risks, unresolved decisions, or meeting outcomes. The Prompt and Context can be configured in advance and regenerated later. Enterprise Search is better for ad hoc questions, allowing the user to ask something different each time and adjust Scope as needed. Put simply, AI Block is closer to a fixed template, while Enterprise Search is closer to free-form search.
Yes. Enterprise Search can already use a specific Page, Person, or Teamspace as Context and can adjust Sources to narrow the search to a particular part of the Workspace or a Connected App. So “limiting the search scope” is not the missing feature. What the community is asking for is the ability to save that Scope directly on a particular Page instead of configuring it again every time.
No. Narrowing Scope can reduce the chance of irrelevant documents entering Retrieval, such as data from a project with the same name three years ago. But if the information you need exists in a company-wide policy, another Teamspace, or Slack, narrowing the scope too aggressively can remove necessary evidence. The better approach is to make Scope match the question rather than simply making it as small as possible.
Not necessarily. The amount of data itself is not the main problem. Confusion is more likely when several versions of the same information exist without indicating which one is still valid or without clear Owner, Date, Status, or Source of Truth metadata. A large Knowledge Base can still be highly searchable when document status and version relationships are clear, and Retrieval can benefit from having more complete historical information.
It is not advisable to delete information based only on how long it has remained unopened. Historical decisions, research material, contracts, and old projects may be rarely accessed but still valuable when needed. A better approach is to mark older content as Archived or Superseded and clearly identify the currently valid version so both people and AI can distinguish historical records from the information that should be used today.