What Notion 3.8 Means for Keeping Agent Context and Procedures Current

Do you find yourself explaining your company’s operations from scratch every time you switch agents?

On October 13, 2026, Notion published its release notes, “Notion 3.8: Context for your agents.” The company describes the update as connecting data, tools, and skills so that you are free to choose which agent or model to use.

In this article, “context” means the information an agent refers to in order to do its work: business assumptions, definitions of terms, decision criteria, past decisions, and so on. A “skill” is a reusable set of instructions bundled with supporting files.

Once multiple agents can draw on the same business knowledge and procedures, a company needs to be able to confirm which content is authoritative and which version is actually being used.

Drawing on this update and related documentation, this article brings together four aspects of ongoing management: assigning owners and review deadlines, distributing updates, retiring procedures, and reviewing connections. It does not compare or recommend specific products or provide setup instructions.

What the Notion 3.8 release notes and related documentation say

The following reflects the documentation as of October 21, 2026.

According to the release notes, connecting an agent that supports MCP (a connection standard that lets AI use external information and functions) to Notion allows it to read workspace context and update documents and task trackers. With Notion MCP, the agent reads and updates information within the permissions granted to the user who connected it.

Notion positions this as giving agents a shared place to look things up, so that you can “switch agents without starting from scratch.”

For administrators, the release notes describe MCP admin controls. Admins can see who connected each AI tool, check when it was last used, and revoke a specific person’s access without affecting other connections.

On skills, the company positions Notion as the place to create, share, and keep skills up to date. The Skills API, which also appears in these release notes, was already introduced in Notion’s blog post “A skills library for every agent,” dated September 17, 2026.

According to the developer documentation “Agent Skills API,” the API retrieves skills stored in Notion as files that agents can use. The core instructions of each skill are written as a Notion page, and supporting files can be attached. The official sample “notion-skills-github-sync” shows a setup in which a recurring script syncs skills from Notion to GitHub, and that repository then serves as the source of skills for each agent.

In other words, editing in Notion, propagation to GitHub, and propagation to each agent are separate stages.

The same release also includes upgraded version history that tracks changes made by people and agents, and column permissions that let database owners control which people and agents can view or edit each property.

Availability and discrepancies in the documentation

Availability conditions differ by feature.

According to Notion’s developer documentation on Notion MCP, restricting which MCP clients members can connect requires the Enterprise plan. Using the Skills API requires a connection token or similar credential with the capability to read content, plus access to the skills in question. The overview we reviewed did not specify which subscription plans include access to the Skills API.

On per-user connection management, the 3.8 release notes and the Admin API documentation differ from the FAQ in the Help Center’s “Notion MCP” article. We could not confirm why the documents differ, so check which admin interfaces and APIs are available with your plan and in your workspace.

Establishing a source of truth and assigning ownership

At MIF, we emphasize identifying the source of truth for business knowledge and procedures and assigning responsibility for maintaining it. We believe the quality of AI responses and task outcomes depends in part on how well a company manages the knowledge its agents use.

To build a setup in which work can continue even when models change, the starting point is not locking business knowledge and procedures inside conversations with a particular agent.

The goal is not to consolidate everything into a single storage location. In a setup like the one described above — distributing from Notion to GitHub, with each agent reading from there — content lives in more than one place. Our view is that, even when content is distributed to several places, you should be able to identify the source of each copy and the version currently in use.

Assign content owners and set review deadlines, then configure the available product features to support those responsibilities and schedules. According to Notion’s help article “Wikis & verified pages,” you can assign owners to a page and set how long its content is treated as verified, and the owner is notified when that period expires. In a wiki, the person who creates a page becomes its initial owner, and this can be changed later. Verifying individual pages that are not part of a wiki is described as available on the Business and Enterprise plans.

These features do not decide the right owners or deadlines for you. Review the available features alongside your business rules, and specify what the review should cover.

The latest content versus approved content

Another distinction worth making is between the latest content and the content approved for use in operations.

For example, a procedure finalized today may be intended to take effect next month rather than immediately.

For procedures used in important workflows, define who may edit them and what reviews are required before agents can use the changes. Record the effective date and the workflows covered, then check that the versions distributed to and used by agents match those requirements.

Also, the fact that agents can refer to shared files does not mean a different agent will produce the same results after a switch. When changing agents or models, confirm not only that the necessary procedures are being referenced but also that the results are what you expected. In practice, it helps to treat the sharing mechanism and operational testing as separate things.

Three ways knowledge and procedures fall out of step with operations

The first is content that is not updated when the work changes. If you do not decide who proposes a correction to a procedure when the work changes, and who reviews and applies it, what is written will drift away from actual operations. If outdated procedures remain, multiple agents that refer to them may carry out work using the procedure as it was before the change.

The second is destinations falling out of step with updates. In a setup like the Skills API sample, each agent refers to the skills as they were when distributed. The API provides a value (version_id) for checking whether something has changed since it was last retrieved. A sync process can compare this value, but it does not indicate whether the content is valid, whether it has been approved, or whether each agent has loaded it. Check the versions distributed against the versions actually in use.

Check the sync schedule and what happens if synchronization fails or content is removed from the distribution list. Also check how edits made directly to copies at each destination are handled. We recommend checking which version each agent is actually using, not just whether synchronization succeeded.

The third is retired content that is still treated as current guidance. Rather than lumping everything together as “expiry,” we separate three things: a content review deadline passing, retiring an outdated procedure from use in operations, and revoking access for a connection.

The help documentation states that the owner is notified when the period for treating a page as verified expires. It does not, however, say that this expiry alone automatically stops agents from viewing or using the page. According to the help article “Delete & restore content,” archived pages can still be opened through links, so archiving is not the same as blocking access either.

Keeping retired procedures as a record is not a problem in itself. If you keep them, distinguish them from what is currently in effect, and decide how to remove them from what agents reference and what gets distributed. Beyond Notion itself, confirm that retirement or replacement has also been reflected in copies already distributed to GitHub and elsewhere.

When someone leaves or changes roles, confirm who takes over the procedures and exceptions that person managed, and whether those remain in effect.

Using version history to support reviews

According to the release notes, the upgraded version history shows highlighted edits across pages and databases, detailed database changes, and who made each change, and lets you restore earlier versions. The help documentation also explains that you can preview what will be affected before restoring an earlier version.

Version history helps show who changed what. Use it to review updated content before distributing it to agents or allowing them to use it, and to investigate problems afterward. History alone, however, does not establish that the content is still appropriate for current operations.

We recommend linking version history to the reasons for each change, the relevant review and approval records, and the workflows the change applies to.

Restoring an earlier version in Notion is separate from updating distributed copies or undoing completed actions. After a restoration, check which version is present at each destination.

Review who connected each tool and what it can do

The items the release notes highlight — “who connected which AI tool,” “when it was last used,” and “whether you can revoke just one person’s connection” — are, in our view, the parts most directly tied to operations. You do, however, need to confirm which connections the list covers and what revocation actually does.

According to the Admin API documentation, the connection list covers OAuth connections that members use to connect MCP clients to Notion, and it does not include workspace-owned internal connections. It is important not to treat this list as an inventory of every data access path.

The Admin API documentation explains that revoking a connection removes that member’s authorization for the relevant MCP client. The member can reconnect if workspace policy allows it. When someone leaves or changes roles, confirm not only that the connection is removed but also the conditions under which they could reconnect, and the access they need for their new work. Do not decide a connection is unnecessary only because it has not been used recently; check its purpose and planned future use as well.

Preventing further access to Notion and deciding what to do with files already retrieved to GitHub or elsewhere are also separate questions. We did not find any statement in the documentation we reviewed that revoking an MCP connection deletes files that have already been distributed.

In addition, Notion MCP reads and writes with the permissions of the user who connected it. So rather than identifying a connection only as “Agent A,” confirm which user or credential it connects with, and what it can read and what it can change.

Notion’s official “Security best practices” also cautions that a connected client may send content retrieved from Notion to systems outside Notion. In addition to checking what the tool can access in Notion, review how it handles the information it retrieves.

A management checklist for shared knowledge and procedures

The table below sets out MIF’s suggested management items. It is not a list of Notion settings; adapt it to your operations, applicable rules, and risks.

Item	Questions to answer	Relevant settings, records, and processes
Location and source of truth	Where is the authoritative version of each document or procedure? Which workflows does it cover?	Knowledge and skill repositories; records identifying the source of truth
Update responsibilities	Who maintains the content, and who approves changes? If one person holds both roles, are the responsibilities documented separately?	Page owner settings; responsibility assignments
Review triggers	What events trigger a review? When is the next review due?	Review deadlines and notifications; internal procedures
Distribution and versions in use	Where has the content been distributed? Which version was sent, when was it synced, and did the sync succeed? How was the version in use at each destination confirmed?	Sync logs; records of distribution destinations and versions
Retirement and retention	When should the content be retired? How will it be removed from active use and distribution? How will distributed copies be replaced, and what will be retained as historical records?	Archive and access settings; updates to distributed copies
Access and permitted actions	Which user account or credentials does the connection use? What can it read or change?	Permissions at the source; column permissions; controls in connected tools
Connection inventory and review	Who has connected which tools? When should each connection be reviewed, based on last use, purpose, and planned use? Under what conditions may users reconnect?	Admin connection list; restrictions on permitted clients; internal procedures
Change review	What must be checked before agents use an important update? Who reviews changes made by agents?	Version history; approval procedures

Record the assigned owners and configure the relevant settings and notifications to support the agreed requirements. Then check that the setup works as intended.

Summary

At MIF, we emphasize identifying which content is authoritative, who maintains it, and which version is approved for agents to use.

As part of ongoing reviews, check that updates have reached their intended destinations, retired procedures are no longer in active use, and connection permissions still match current operational needs.

Use product features to support the assigned responsibilities and review deadlines, and configure them to reflect your company’s requirements. When switching agents or models, check that the new setup can access the required information, follow the intended procedures, and produce the expected results.

We believe the quality of AI responses and task outcomes depends not only on model performance but also on the accuracy of the knowledge agents use and how well that knowledge is maintained.

Sources and scope

This article is based on information as of October 21, 2026. Its main references are Notion’s release notes “Notion 3.8: Context for your agents” (October 13, 2026); Notion’s blog post “A skills library for every agent” (September 17, 2026); Notion’s developer documentation “Agent Skills API,” “Notion MCP,” and “Security best practices”; the Admin API pages for listing and revoking connections; and the Help Center articles “Wikis & verified pages,” “Notion MCP,” and “Delete & restore content.”

Descriptions of product features and availability are based on Notion’s published materials. MIF has not independently tested these features or evaluated how switching agents affects outcomes. The breakdown of situations where knowledge and procedures fall out of step with operations, the items in the management checklist, and the operational recommendations are MIF’s views and analysis.

Features, availability, and terms of use may change. Before using these features, check Notion’s current official documentation.