The useful lesson from Notion's AI agent is not "Notion has good prompts." It is that a serious agent product is mostly harness: tool access, context design, evals, permission boundaries, and workflow ownership. The model matters, but the system around the model decides whether the agent becomes a product or another impressive demo.
That matters because the search for notion ai agent is really a search for a working pattern. People are not only asking what Notion shipped. They are asking why Notion's agent can operate inside a messy workspace with pages, databases, permissions, files, connected tools, and user-specific context.
The answer is uncomfortable for teams hoping to buy one generic AI layer and call it done. Notion's public story points to a deeper truth: production agents work when the surrounding workflow becomes bounded, checkable, structured, and verifiable.
What Notion Actually Shipped
Notion Custom Agents are designed to run inside a workspace, use connected tools, follow instructions, and operate from triggers or schedules. That sounds like a product feature, but under the hood it implies a lot of architecture:
- A system for giving the agent access to the right pages and databases.
- A tool layer that can search, read, edit, and act without dumping every capability into one giant prompt.
- A permission model that decides what the agent can see and change.
- A trigger model so agents can run in the background, not only when a user opens chat.
- A way for users and teams to own agent behavior without every change going through one central AI team.
The Latent Space episode with Notion's Simon Last and Sarah Sachs is useful because it describes the road to that architecture. The early versions tried approaches that were technically clever but not model-friendly. Over time, the agent moved closer to primitives the model could already handle: Markdown, pages, databases, tool definitions, and explicit tasks.
That is the first lesson for any enterprise team: do not ask the model to learn your weird internal representation if you can translate the task into a representation it already understands.
The Five-Rebuild Lesson: Stop Fighting the Model
Notion's agent work reportedly went through multiple rebuilds. The pattern is familiar if you have built agents in production:
| Version of the idea | Why teams try it | Why it breaks |
|---|---|---|
| Give the model a pile of APIs | Fast prototype, impressive demo | Tool confusion, weak error recovery, massive prompt overhead |
| Create a custom representation | Feels precise and domain-specific | The model does not naturally understand it |
| Fine-tune around missing behavior | Looks like the "serious" path | Often fights model progress instead of riding it |
| Put every edge case in the prompt | Avoids writing infrastructure | Turns the system prompt into a junk drawer |
| Build a harness around simple primitives | Less glamorous | This is the version that tends to work |
This matches Anthropic's guidance in Building Effective Agents: use the simplest solution that works, and add complexity only when the task demands it. Most working enterprise agents are not autonomous masterminds. They are deterministic workflows with one or two model calls at the points where judgment is genuinely useful.
That framing also explains why AI has worked faster for software engineers than for most business functions. Code is bounded. It is checkable. It lives in files. Tests run quickly. A pull request is a reviewable artifact.
Finance close, sales ops, customer support escalation, procurement, and compliance workflows are different. They span systems, undocumented exceptions, Slack decisions, spreadsheet patches, and human judgment. If you point an LLM at that mess without first making the workflow legible, you usually create more work than you remove.
Progressive Tool Disclosure Solves the 100-Tool Problem
The standout architecture idea from the Notion story is progressive tool disclosure.
The naive way to build an agent with 100 tools is to show all 100 tools to the model upfront. That creates three problems:
- Cost: every request carries thousands of unnecessary tokens.
- Reliability: the model has to choose from tools that are irrelevant to the current task.
- Ownership: every team adding a tool risks breaking everyone else's behavior.
Progressive disclosure flips the pattern. The agent starts with the minimum context needed to understand the task. As the job becomes clearer, the harness exposes the smaller tool set that fits the goal.
Think of it as routing before reasoning. The system narrows the task before asking the model to act.
| Bad pattern | Better pattern |
|---|---|
| One universal prompt with every tool | Task router plus scoped tool set |
| Tool examples buried in few-shot text | Tool definitions with clear goals and constraints |
| One AI team owns all tool behavior | Product teams own their tool definitions inside a shared framework |
| No clear test for tool selection | Evals for routing, tool choice, and final task success |
| Every agent has its own logging | Shared tracing, audit logs, and review queue |
This is also the antidote to agent sprawl. Without a shared harness, every employee eventually builds a private agent: one for invoices, one for CRM notes, one for recruiting, one for content, one for support tickets. At first this feels productive. Six months later the company has 50 brittle workflows, 50 model configs, 50 credential surfaces, and no one knows which ones are still safe.
The fix is architectural. New use cases should land as configuration on top of shared infrastructure: ingestion, permissions, model routing, approvals, evals, audit logs, and deployment ownership.
Memory Is Not Always a Fancy Memory System
One of Notion's smartest choices is that "memory" can simply be pages and databases.
That sounds obvious until you watch teams overbuild agent memory. They create vector stores, episodic stores, reflection loops, profile memories, and cross-agent shared state before they have answered the basic question: what does the agent need to remember, who owns that memory, and how will a human correct it?
For many business workflows, memory should be boring:
- A customer support agent remembers account preferences in a CRM field.
- A finance agent remembers vendor exceptions in a governed database.
- A sales agent remembers territory rules in the same system managers already maintain.
- A project agent remembers status in the project database, not in an invisible vector blob.
We made a similar argument in Agent Memory Beyond RAG: memory is not one thing. Some state belongs in the conversation, some in the system of record, some in a retrieval layer, and some should not be stored at all.
The useful principle is this: if a human needs to inspect, edit, approve, or audit the memory, put it somewhere humans already know how to govern.
Why Enterprise AI Fails Even When the Model Is Good Enough
The operator lesson from recent enterprise AI failures is blunt: models are no longer the main bottleneck. The hard part is turning messy business work into something an agent can safely help with.
Four failure modes show up again and again.
First, teams skip the audit. They automate the documented process, then discover the real workflow lives in exceptions, Slack messages, personal spreadsheets, and unwritten rules. The gap between the SOP and reality is where pilots die.
Second, they use the LLM for everything. Extraction, comparison, routing, math, status checks, permissions, and deterministic branches all get shoved through model calls. The result is slower, more expensive, and less reliable than plain code.
Third, they allow agent sprawl. Individual teams build isolated agents with separate prompts, keys, logs, and ownership. It works until a model changes, an API breaks, or an employee leaves.
Fourth, they treat AI like a project instead of infrastructure. Models change. pricing changes. rate limits change. workflows change. A production agent needs ongoing evaluation and tuning, not a launch party.
The 5 percent of AI deployments that keep working tend to do the opposite. They audit first. They decompose work into deterministic steps. They put agents on a shared orchestration layer. They stay model-agnostic. They assign someone to keep improving the system after go-live.
Notion's agent architecture is interesting because it points in that direction. It is not one prompt. It is a product surface over a governed workspace, with tools, permissions, triggers, model choices, and a lot of hidden harness work.
Lessons for Teams Building Custom Agents
If you are building a custom agent inside a real company, steal the useful parts of the Notion pattern.
Start with the real workflow, not the app list. Watch the work happen. Map the exceptions. Identify which parts are judgment and which parts are deterministic.
Then turn the workflow into a harness:
- Inputs: where the work enters the system.
- State: what the agent needs to read, remember, and update.
- Tools: the smallest tool set needed for each task stage.
- Deterministic steps: validation, routing, comparisons, calculations, and policy checks.
- Model calls: only the steps where judgment, language, ambiguity, or classification justify the cost.
- Approvals: where a human stays in the loop.
- Evals: what proves the agent is getting better or worse.
- Audit logs: what compliance, security, and operators need to inspect later.
The question is not "Can the model do this?" The better question is: "Can we make this work bounded, checkable, structured, and verifiable enough that the model has a fair shot?"
How OpenNash Can Help
OpenNash builds custom AI agents for business workflows where the default platform path breaks down: too many systems, too many exceptions, too much compliance risk, or too much cost uncertainty.
For a Notion-style agent project, the work usually looks like this:
- Audit the real workflow. We map what operators actually do, including the exception paths that never made it into the SOP.
- Separate code from judgment. Plain code handles validation, branching, calculations, permissions, and system updates. The model handles classification, extraction, summarization, drafting, and ambiguous decisions.
- Design the shared harness. Tool disclosure, model routing, approvals, evals, logging, and ownership live in one spine instead of scattered personal agents.
- Deploy with humans in the loop. The agent starts by drafting and routing. Autonomy expands only where evals and operator review support it.
- Tune after launch. New workflows, model changes, and vendor changes are expected. The system is built to absorb them.
That is the difference between an agent demo and agent infrastructure. If your team is trying to build agents across support, finance, sales, operations, or internal engineering, book a call and we will map the first workflow into an implementation plan.