Notion AI updates, May 2026

The week, in order

May 1, May 4, May 5, three steps in one move

Treat the three dates as one feature shipped in three parts. Part one extends where the agent can reach. Part two starts charging. Part three adds the safety rails admins need before they will let an LLM with API access spend money on its own. That sequence is internally consistent and tells you what Notion is optimising for, the unit economics of a cloud agent that takes real action in third party services.

May 1, 2026

Custom Agents, in private Slack channels

The release note is short, the implication is not. Until May 1, a Custom Agent could see public Slack channels through the Slack connector but anything posted in a private channel was invisible to it. The May 1 release adds an opt in toggle at Settings, Notion AI, AI connectors, Enable access to private content, and the agent gains the same scopes a human Slack user with private channel access would have.

The mechanism is unchanged from any prior Slack integration on the platform. The agent calls conversations.history, conversations.replies, and chat.postMessage over HTTPS against api.slack.com. What changed is the OAuth scope set Notion now requests on behalf of your workspace. It never opens the Slack desktop app. It never moves a cursor in Slack. It cannot do anything Slack's Web API does not expose, which mostly does not matter because Slack's API is comprehensive, and absolutely matters when you generalise the pattern to apps that do not have an API at all.

May 4, 2026

The mobile home, and the first metered day

Two things landed on May 4. The visible one is a new home tab on the mobile app, surfacing home, chats, meetings, and inbox via swipe. Useful, low controversy. The structurally important one is that the Custom Agents free trial ended on May 3, and May 4 is the first day every Custom Agent run shows up on a meter against Notion Credits.

That is a policy change, not a feature. Workspace owners now buy credits, agents spend them, the credits dashboard reports spend per agent over time. The marketing site does not publish a fixed token to credit conversion, the dashboard simply shows that agent X consumed Y credits this week. For a workspace with one casual Custom Agent the meter is invisible. For a workspace with a dozen agents on AI Autofill against a busy database the meter is real money, which is the only reason the May 5 release exists.

May 5, 2026

Admin controls for Custom Agents

The May 5 post lists five distinct levers. Access controls that restrict who can create Custom Agents to named users or groups. Per-agent credit limits set by the agent's creator. Workspace-level credit limits that apply to every agent, new and existing, on Enterprise plans only. A credits dashboard that breaks down spend by agent with trends and recent activity, so admins can disable a misbehaving agent in place. An organisation level dashboard for multi-workspace admins. Plus three automatic safeguards: notifications as a workspace approaches its limit, a hard pause on every agent if credits run out, and an auto pause on individual agents that spend unusually fast with a notification to the creator.

The Notion post on this release also drops a number for context, more than one million Custom Agents have been created since the beta launch two months prior. That is the denominator the new controls exist to govern.

The wall every release confirms

The agent never leaves the cloud

Step back from the three releases and one shape repeats. The Slack reach is over Slack's Web API. The mobile home is a client view onto the same cloud agents. The credits and admin controls govern cloud runs. None of the May 2026 work touches the operating system the user is running. The agent has new hands inside SaaS surfaces, no hands inside macOS itself.

For workflows that live entirely inside Notion plus a small ring of supported SaaS, that is fine and probably preferable. The agent runs on Notion's machines, the credits are predictable, the admin controls cover the business risks. For workflows that touch native Mac apps without a usable web API (Xcode, Final Cut, Logic Pro, QuickBooks, FileMaker, native Mail, native Messages, Terminal, an in-house Cocoa app, an app that takes credentials only inside its own UI), the wall is in the way. A cloud agent cannot click those.

The boundary, in code

Why an OS layer agent looks different on disk

The cleanest way to see the difference is not in marketing copy but in the kind of code each side has to write. A cloud agent worries about API tokens, rate limits, OAuth scopes, and webhook signatures. An OS layer agent on macOS worries about the live trust state of the macOS Accessibility API, because everything it does goes through that one permission.

Fazm is open source. The relevant file is Desktop/Sources/AppState.swift in github.com/m13v/fazm. The permission probe is three checks in sequence, and the fact that it has to be three is the whole point.

1. 1. Real AX call against the frontmost app

   testAccessibilityPermission() at line 482 calls AXUIElementCopyAttributeValue for kAXFocusedWindowAttribute on the frontmost app and inspects every AXError code. Success, noValue, notImplemented, attributeUnsupported all count as fine. apiDisabled is unambiguously stuck. cannotComplete is ambiguous, so the code does not stop there.

2. 2. Finder cross-check on cannotComplete

   confirmAccessibilityBrokenViaFinder() at line 517 retries the same query against Finder. The reason that disambiguates anything is that several real app frameworks (Qt, OpenGL surfaces, Python based apps like PyMOL) return cannotComplete because they do not implement AX, not because Fazm has lost permission. Finder is a known AX compliant app. If Finder also cannotComplete, permission is genuinely broken. If Finder responds, the original failure was app specific, ignore it.

3. 3. CGEvent tap probe to bypass a stale TCC cache

   probeAccessibilityViaEventTap() at line 539 calls CGEvent.tapCreate(.cgSessionEventTap, .tailAppendEventTap, .listenOnly, ...) with a one event mask and immediately invalidates the port. Unlike AXIsProcessTrusted(), tap creation queries the live TCC database instead of the per-process cache, which on macOS 26 Tahoe can return false negatives long after the user has actually granted permission. The probe is the tie breaker.

Three checks. None of them make sense for a screenshot bot, because a screenshot bot's permission story is the screen recording entitlement, not AX. They make sense for Fazm because AX is the primary mechanism, the way the agent both reads window contents and dispatches events. The Notion side of the comparison has nothing equivalent because nothing in Notion's stack ever asks the operating system for permission to act on the user's behalf, the operating system is not in the loop.

Where this leaves a Notion shop on May 6

The honest split, planner above, hands below

Most teams already use Notion for plans and docs. The May releases make Notion AI a more responsible planner inside that surface, the credit caps and access controls are exactly the kind of governance any LLM that takes real action in third party services needs. Use the planner. Custom Agents that draft, summarise, autofill databases, reach into Slack, and hit Calendar and Mail are now genuinely strong, and the admin layer makes them safe enough to deploy.

For everything below the planner, the part that actually touches the user's Mac, an OS layer tool is the right shape. The split is honest, neither side is trying to be the other. A Notion Custom Agent says do this in Slack. An OS layer agent says do this in Xcode, on the focused window, with keystrokes and AX events. They do not overlap, they compose.

If the workflows you care about are mostly cloud SaaS, the May 2026 Notion releases probably moved the line in your favour and you do not need anything else. If the workflows you care about reach into apps that live on your dock, the May releases told you, in three dated posts, exactly where the cloud agent stops.