Notion-on-top was the starting line: building Notis as an agentic workspace

This week I had one of those customer sessions that forces you to say the quiet part out loud: what we built first is not what we’re building next. Notis started as “AI on top of Notion” because that was the fastest way to give founders a real leverage tool, without asking them to migrate their brain to yet another system. But the more we sit with teams in the wild, the clearer it becomes that the layer is becoming the product. We’re evolving Notis into a standalone agentic workspace—while keeping a progressive path for people who already run their life in Notion.

Notion-on-top was the starting line, not the finish line

If you’ve used Notis, you’ve felt the appeal: you keep your existing databases, docs, and conventions, and you just describe what you want. Notis finds the right place, writes the right thing, and nudges the workflow forward.

But a layer has a ceiling. A layer can automate and assist. A layer can’t always shape the interface you need next.

The new direction is simple to explain and hard to execute: Notis should let you describe an outcome and get the UI that matches it. A task manager that fits your brain. A dashboard that matches your business. A scenario model you can tweak in real time. Not by assembling blocks for hours, but by telling Notis what you want and iterating in plain language.

A progressive path: keep what works, evolve what doesn’t

There’s a trap a lot of “new workspace” products fall into: they ask you to restart. New structure, new rules, new templates, new rituals. That’s fine for greenfield teams. It’s brutal for founders who already built a system that mostly works. So we’re staying stubborn about a progressive path. If Notion is your source of truth today, Notis should respect that. If you want to stay there forever, you should be able to. If you want to move pieces of your workflow into Notis-native experiences over time, you should be able to do that too—without a big-bang migration.

Three moments from a customer call that clarified everything

I met with a multi-company founder who runs a very real, very messy operator’s stack: multiple teams, multiple tools, lots of context switching, and zero patience for “please rebuild your process.” In a single session, we hit three topics that basically map the next chapter of Notis.

Meeting knowledge should not die inside one app

The first thread was deceptively simple: how do you pull useful knowledge out of meetings and actually make it usable later?

Most teams already have a note-taking tool they like. The problem isn’t “capture.” The problem is “flow.” Notes get trapped in one place, action items get retyped somewhere else, and the context that makes decisions legible evaporates.

We explored an MCP-based workflow to pull meeting knowledge directly from tools like Granola and make it available as living context for everything else Notis does. That’s the shift I care about: the meeting isn’t an artifact, it’s an input. The output should show up where work continues—tasks, docs, CRM, follow-ups—without you doing the glue work manually.

If MCP becomes the boring standard it promises to be, it means Notis can speak “tool” fluently: fetch the right meeting, extract the right memory, and route it to the right place with guardrails. The end goal is not a better transcript. The end goal is less loss of momentum.