Notion 3.8 gives outside agents a route into workspace context

The release treats a workspace as shared context for several agents

On October 13, Notion released version 3.8 with a theme it called “context for your agents.” The announcement says an MCP-compatible agent can read workspace context and update documents and task trackers. Administrators can see which AI tools were connected, when each connection was last used, and revoke a person’s access without affecting other connections.

That pitch addresses a familiar inconvenience: an employee moves between a coding agent, a writing assistant, and an operations tool, but keeps copying the same project history into each one. Notion wants the workspace to act as a durable record that different agents can consult. The tradeoff is that the same context becomes reachable by software outside the workspace interface, so the choice of pages and write permissions matters.

Notion also describes connections for its own Agent and Custom Agents to more than 150 tools, with examples such as HubSpot, Stripe, and Cloudflare. This is a separate direction from letting an external agent connect to Notion: one lets Notion agents call outside services, while the other lets an agent in another product read or change Notion content.

MCP connects an agent to selected workspace access

The release says connected agents can update documents and task trackers, but it does not publish one universal access matrix for every MCP client, workspace, or tool. Notion gives administrators a way to inspect a connection and revoke it; teams still need to check the actual agent’s page access and supported write actions before enabling it. The column-permission feature below is one documented control for database properties, rather than proof that every page or field is automatically restricted.

With an MCP connection, a person works in an outside agent such as Claude and that agent pulls context from Notion. Notion’s separate “Claude agents in Notion” feature runs with the agent presented inside Notion and uses its own sharing, plan, and service terms. The help center explicitly describes these as different paths, so a team should check which one it is enabling before reviewing data handling or billing.

A practical connection review starts with the task. If an agent only needs project requirements, it should not receive unrelated HR or finance pages. If it can update a task tracker, the team should decide whether it can change status fields, owners, or due dates, and who checks those edits.

Column permissions can narrow a database, with plan limits

Notion 3.8 also adds database property access. Notion’s help guide says an owner can set which people or agents may view or change individual columns, such as keeping compensation hidden while a recruiting team sees names and roles. A property rule does not grant access to a page someone cannot already open; it narrows the data visible inside a database that the person or agent can otherwise reach.

There are important setup limits. The help page says property access is available on Business and Enterprise plans, requires full access to the database to configure, and can cover up to 20 properties. It also says some properties, including Title and certain system fields, cannot be restricted. Users with full database access are never limited by a column rule, and when a person matches multiple exceptions, Notion uses the least restrictive access.

Agents can receive their own property permissions, while Notion AI usually inherits the current user’s permissions. That difference means an admin should test the actual agent account rather than infer access from a human teammate’s view. A filtered database view may also fail if it sorts by a column the viewer cannot see. The new feature gives teams another boundary to configure; it does not remove the need to test the whole page and database-sharing setup.

The Skills API distributes procedures as files

Notion’s Skills API addresses reusable instructions rather than workspace facts. A skill can contain a main SKILL.md page plus supporting files, and the API exposes those materials in standard file-based formats so teams can use them in different agent environments. Notion says the API can sync skills into GitHub, where they can then be used by agents such as ChatGPT or Claude.

The developer documentation describes a concrete access condition: a connection token or personal access token needs the Read content capability, and the connection must be shared with the databases that contain the skills. Skills that have not been shared with that connection are omitted. The API can list, download, and upload skill directories, but the launch material does not imply that every workspace skill is automatically copied to every agent.

Notion’s product blog says teams can also create and edit skills in Notion using MCP tools. That creates a useful separation: the workspace stores the procedure, the API or a sync script carries its files to an agent, and the agent follows the version it has received. Teams should decide who can edit a skill, how changes reach each agent, and how they remove an outdated instruction from a destination.

A sync is still an integration someone must configure and maintain. Notion’s developer examples show scripts that enumerate available skills and copy the returned files into a destination repository. A skill edited in Notion will not necessarily appear in every agent immediately; the destination’s update schedule, access token, and publishing process determine when that agent receives the change.

Version history makes edits easier to inspect, not automatically safe

Version 3.8 improves Notion’s history view with highlighted edits, more detail for database changes, and attribution for actions by people and agents. The release notes say users can review what changed and restore a prior version. That is valuable when an agent updates a task or page, because a team can see what happened after the write instead of relying on a summary in chat.

A rollback is a recovery path, not a permission control. It cannot prevent a sensitive field from being exposed before someone restores an old version, and it may not reverse an external action triggered by a changed record. Teams should consider both before-and-after controls: narrow access where possible, ask for human review on consequential writes, and inspect the activity record after the agent works.

A first pilot should keep the agent’s job small

A useful first trial is a read-and-draft task using a limited project space. Ask the Claude agent beta to summarize a page and prepare an update without submitting it. Check whether it can access only the pages intended, whether sensitive database properties stay hidden, and whether its draft includes correct links and source details. Then try a single low-impact write and confirm that the page history attributes the edit.

For Skills, start with one non-sensitive procedure, install it into one agent environment, and compare the received files with the version in Notion. The goal is to verify the sync path and access boundaries before making a shared library part of routine work. Notion 3.8 makes the workspace more useful as shared context, but each team still has to decide which context and actions should travel outside it.